Open Coffee Database


#21

I was going to say I did not know about joining across two databases, but it turns out you can “attach” a second database to the same connection which will let you join across them, so yeah super simple.


#22

I might have a look at this today and see if I can get Decaf working with SQLite.


#23

I didn’t really get anywhere with this. If someone who knows Python what’s to help, that would be great. I expect it’s only an hour’s job, if you know the database driver functions already.


#24

I will take a look after work today, I should be able to get it done quite quickly, on a side note are there any others that people might find useful? I know getting sqlite working would be most if not all of the work to get postgresql working as well.


#25

It looks like that will be slightly more difficult than I was hoping, but not too bad. Need a better way to determine which database calls to use and a better way to create the database, which I might work on a bit this weekend and submit something for that.


#26

I think the idea was to use SQLite specifically because it will all be running on a single machine, and will presumably need super low concurrency. ie not multiple clients connecting to it at once.


#27

@thexder1 have you used Sqlalchemy? That’s the Python database abstraction layer and ORM, as far as I’m aware. I don’t know if that would be overkill for our requirements.


#28

Yes that is the reason for SQLite, but at the same time if we can make it easy to swap in different storage layers then we should go for that.

I have looked at sqlalchemy before, but not used it. I will take a look at it and see what I can come up with.


#29

Looking into it a bit more I wonder if Sqlalchemy is a bit too heavy weight for what we need. I am looking at lighter options. The biggest thing I worry about with other options is that they may not be as well known which can make it more difficult for people to contribute. One that peaked my interest for this project is PonyORM that is supposed to be light weight, has tools to help with designing, creating and changing the schema and it supports the main databases that people would use. This would take a bit more research to nail down the best option and I would welcome input from Matt on what he thinks about this.


#30

SQLAlchemy is the most popular and is well maintained, that definitely is a benefit in Open Source.


#31

Yeah that is definitely a bonus of SQLAlchemy, I just want to consider other options since that is really quite large and really designed for larger more complex projects than Mugsy. Not that it can’t be used and it may not be any worse than other options, just prefer something lighter weight when the heavy solution is not needed.


#32

Oh, I never replied to you : /

I generally prefer to go ORM-less for my projects. It’s entirely possible that adding one would be more cost than benefit (having to learn the library, work in the way it requires us to, spend time upgrading to the latest version…).
I reckon just hand-crank that SQL for now, then see what improvements can be made.

“Do the simplest possible thing that will work.” - someone more cleverer than what I am


#33

Right, that is understandable, but as soon as you start talking about supporting more than one database backend you want to separate that which would generally be easier to use an ORM that already supports the backend databases you want to support.


#34

Yep, exactly. I don’t think we need to support more than one database.