-
Notifications
You must be signed in to change notification settings - Fork 308
convert User object to SQLAlchemy ORM #446
Comments
So since the User class doesn't exist on it's own, but rather subclasses Participant, I think the right thing to do here would be to start with the Participant class. I feel like the reasonable thing to do here would be to build on the work that @mjallday started in #418 and start moving the ORM-based classes under gittip.models namespace. |
Sounds good, @joonas. Follow your heart. :-) |
@joonas Check out this branch, I had largely done the conversion for the User/Participant class before I went home for the holidays. Feel free to borrow anything in there. |
So I've pushed the work I have done so far up to Github, see my migrate-to-orm branch. I'll keep working my branch until all of the work is done, any comments/feedback is more than welcome, I'll be periodically also merging in the latest master so that it tracks the current version as closely as possible. Should I keep referencing this issue in all my commits (I meant to do that, but I forgot..) to keep this issue going as I work on it? Still missing from that is the rest of the test suite and some templates. Also, I should note that this is still very much work in progress. |
Yes, please reference this issue in commits to collect them here. Thanks for doing this, sorry I missed this earlier, will review tomorrow or Monday. |
…ipay#446 Basically, I went ahead and reconstructed each table in the database as a mapping class. In addition, I recreated the User class that subclassed Participant class previously. There is still clean up that needs to be done here. Signed-off-by: Joonas Bergius <[email protected]>
…ipay#446 Basically, I went ahead and reconstructed each table in the database as a mapping class. In addition, I recreated the User class that subclassed Participant class previously. There is still clean up that needs to be done here. Signed-off-by: Joonas Bergius <[email protected]>
Migrate to using an ORM, addresses #446
Great work, @joonas! !m |
There are a few models around the Gittip codebase: User, Participant, AccountElsewhere, Payday. We're going to try porting this to SQLAlchemy ORM one at a time (#129). @joonas is going to take this on. The deliverable for this ticket is:
Hopefully we can do this easily enough without getting sucked into the Participant and AccountElsewhere objects. We may need to port those to core as part of this, though if not that's preferable I think.
The text was updated successfully, but these errors were encountered: