On Tuesday, June 10, 2014 3:47:00 PM UTC-4, Noah Davis wrote: > > I suspect there's some way to tell the ORM to Do The Right Thing here, but > I have no idea what it might be. I'd like the particular applications to be > as unaware of the underlying table information as possible. I guess in > essence I'm trying to separate business logic from the DB logic as much as > possible. Maybe I'm heading down a dead-end... I'm open to better > suggestions. >
I've done this before. It's messy, not fun, and "unpythonic" I've been told. But it can be done and I was happy with the results ( not the process ). I can't share the code anymore, but I remember doing a few things: 1. Using an initialization routine. The classdef of 'MyAlice' would register as a provider of 'Alice'; the initialization hook would setup relations of 'Alice' to use 'MyAlice'. I would just inspect the inherited 'models' package, and then declare the necessary relations. An early version used a registry, later versions I realized I could just use the inheritance for the "registry" information. 2. All functions in the 'base' code referenced `self.__class__` -- as in `getattr(self.class, column)` While it does require you to set up the package in a certain way and call an init routine, I think it's the right thing to do -- since you need things to be setup correctly, your init routine can have a handful of statements to ensure the package and database are properly setup in the 'child' project. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
