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.
aspxarticle] 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. aspxarticle]
--[[User:AaronS|AaronS]] 00:52, 26 March 2009 (UTC)
=== Discusion ===