ORM Evaluation and Implementation
Bug #353546 reported by
Michael Clay
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Obsolete Junk | ||||||
0.0.0.0 |
In Progress
|
High
|
glot developers | |||
glot |
In Progress
|
High
|
Michael Clay |
Bug Description
glot currently is doing everything in raw SQL, which is fine for now but it should consider moving to an ORM to facilitate faster development and database agnosticism. A couple of ORMs already discussed are SQLAlchemy (http://
Changed in glot: | |
importance: | Undecided → High |
status: | New → Confirmed |
To post a comment you must log in.
We reviewed the options (and Storm (http:// launchpad. net/storm)) and decided to go with SQLAlchemy since it seems to be the most powerful and is rather DB agnostic. Storm also seems like a worthy contender (it was a hard choice) as it seems to have better performance. If performance becomes an issue, we may revisit Storm. SQLObject also seemed nice, but its feature set seemed to be subsumed by Storm's.
Regarding the implementation with SQLAlchemy, here's the game plan:
1. convert schema
2. create objects
3. map functions in glotDB to objects
claym will take over for 1 (and maybe 2, depending on what is involved). Then reassign to goodmami for (maybe 2 and) 3.