On 1/27/07, Allen Bierbaum <[EMAIL PROTECTED]> wrote: > I agree that a complete separation is probably either a) impossible or > b) going to lead to code that is so complex and difficult to maintain > that it removes any advantage gained.
I modify the schema and code in step during development, once the project is "finished" and enters into maintanence, the object model stays pretty much fixed. From your initial message, I'm sure whether you wanted to use raw SQL or SA's interface. The latter isolates changes much better than the former, so the rest assumes that's what you're using. Table name changes are pretty simple, change the first argument to Table and all the ForeignKeys that reference it. Field name changes are less obvious. I make use of the key= argument of the Column class because that means my queries don't need to be rewritten. Flexibility beyond that is dependent on how many queries you have scattered around your code. For code that's just using the final mapped objects, you can map pretty much anything you can query onto a particular attribute. I've done a few mapping changes where a field is normalized or de-normalized and the object stays the "same". The code using the objects doesn't have to change, but the queries that touch that field generally do. Certain changes are simpler than others, your mileage may vary. > I am starting to think that it still has all the power and flexibility > of the other methods of using SA but simple encapsulates the Table and > Mapper creation in a single unit. Can anyone tell me if this is a > correct assessment? ActiveMapper implements the active record pattern while the standard SA ORM interface implements the data mapper pattern (see Fowler's Patterns of Enterprise Architecture for explanations). For basic usage, ActiveMapper is more convenient and is basically a thin wrapper over the standard. The problem is that it's relations are less powerful -- there's no primaryjoin or secondaryjoin, this is an implementation limit and can be fixed -- and quite a few of the features listed in the Advanced Datamapping section of the docs are unavailable to you. You cannot, for example, map multiple tables onto a single object, this is a design limit. You can mix and match ActiveMapper and normal SA mapped objects and definitions, but I prefer to just use active_mapper exclusively. The biggest disadvantage is that the code is spread into three locations. I work around this using code folds in Vim, but it's still a bit clunky. There is another active record mapper called TurboEntity (no ties to TurboGears despite the name), which a number of people on the TG mailing list like. The authors of ActiveMapper and TurboEntity are collaborating on a joint project to replace both with a mapper that implements a DSL which, to me, looks like a mix between Rails' ActiveRecord and Smalltalk. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
