*Viability: currently developed. seems like a fairly good site with some documentation. The bigest drawback is that the project is only a year old. a pro is that it may be easier to use than sqlalchemy.
Recomendations === Let me preface this by restating that I've never actually used any of these abstraction layers and I'm not yet familiar with the gramps code and developers strengths. Other people with more knowledge should be the ones making the decision. Also any decisions need to be revistable after we actually start coding in case they just don't work. I've spent the last few days trying to look at the current options for db abstraction. From what I currently know I think I'm going to recommend we use sqlalchemy with sqlite. sqlite. no server to manage and single file db's will make them easy to share and manage multiple dbs at the same time. also make merging simpler. will allow websites to be developed that will work directly from the db. As long as gramps doesn't switch focus to be some kind of mass user website for editing large trees I think sqlite will fit the bill. sqlalchemy. this seems to have a large following and good documentation. It should allow us to support different db back ends easier in the future. at least some people think it's the best python orm available. it seems to provide good tools for when the ORM starts to get in the way. Reasons I don't recommend the other options include:
MySQL. probably not as user friendly and since gramps isn't a client / server sort of program I don't think it's necessary.
DB-API. with [http://www.python.org/doc/2.5.2/lib/module-sqlite3.html sqlite3] It sounds as if the DB-API in practice doesn't support the changing of dbs as much as might be thought. If we commit to sqlite though this might be an option.
SQLObject. this seems like a viable alternative to sqlalchemy but slqlalchemy seems to have more documentation and user acceptance. Also the ORM layer might not step out of the way very nicely. the website says it will but I wasn't quite buying it from the examples.
Storm. while this project looks promising and may be easier to use than sqlalchemy it's only a year old and as I was recently burned by picking a fringe tech for my tech stack I'm a bit skittish of anything that doesn't have wide acceptance and use.
Additional notes: I was originally advocating for database abstraction not an orm layer. I've never used a true orm and can't fully say how they work in practice. While I'm not solidly on the orm badwagon I do think an orm layer might do gramps some good. There will be situations where simply writing queries will be far easier. Our implementation model should take that into account. from the website sqlalchemy sounds like it will provide both abstraction and an orm and we'll be able to use both as the needs determine. While I don't fully agree with the severity of this [http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx article] he does make some valid points. There is a reason that true object databases [http://en.wikipedia.org/wiki/Object_oriented_database haven't caught on]. I guess I'm advocating for something like "Developers simply accept that there is no way to efficiently and easily close the loop on the O/R mismatch, and use an O/R-M to solve 80% (or 50% or 95%, or whatever percentage seems appropriate) of the problem and make use of SQL and relational-based access ... to carry them past those areas where an O/R-M would create problems." [http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx article]
--[[User:AaronS|AaronS]] 00:52, 26 March 2009 (UTC)
=== Discusion ===
I suspect that we would have something like SQLite as a default, but allow experts to move to more sophisticated backends.
== Discussions of BSDDB in Python ==
= What now? =