On Sep 12, 2014, at 8:46 PM, Brian the Lion <[email protected]> wrote:
> Hi all, > > I am having trouble deferring a many-to-many mapping. I just had a couple of > questions related there-to: > > (1) The most visible implementations of vanilla many-to-many mappings seem to > use sqlalchemy.Table(...). Is that, indeed, the accepted practice? One > alternative would be to use a mapped class, but that seems less than > parsimonious. all parsimony aside, you can map to that table and call it the association pattern: http://docs.sqlalchemy.org/en/rel_0_9/orm/relationships.html#association-object , and you can combine the two approaches too, as long as you take care to make the appropriate relationships "viewonly" (see the green note at the end of that section). > > (2) There don't appear to be any particularly visible examples of deferred > many-to-many mappings. The best I was able to come up with was along the > lines of > > class DeferredManyToMany(object): > @declared_attr > def __table__(cls): > return Table(cls.__tablename__, cls.metadata, ....) > > Is this also accepted practice? what is the nature of the "deferment" here? Are you using reflection, or just wanting to organize your code in some way where classes are declared before tables (in which case .... straight up classical mappings http://docs.sqlalchemy.org/en/rel_0_9/orm/mapper_config.html?highlight=classical#classical-mappings do that) ? The code example in your paste doesn't make apparent why __table__() needs to be a function. It sort of looks a bit like you're trying to emulate what a mixin is used for, e.g. a fixed series of columns: http://docs.sqlalchemy.org/en/rel_0_9/orm/extensions/declarative.html?highlight=declarative%20mixin#mixin-and-custom-base-classes. > > (3) Upon execution, the __table__(...) method gets called twice and throws an > InvalidRequestError saying the table is already defined. Giving > extend_existing=True in the Table constructor fixes things. Can somebody > provide some background on that? as mentioned on IRC, add the "keep_existing" flag http://docs.sqlalchemy.org/en/rel_0_9/core/metadata.html?highlight=table#sqlalchemy.schema.Table.params.keep_existing which will allow the same table to be safely reused and ignore the given arguments (also I've made sure all those arguments are cross-referenced, so click around the "see also" boxes" to get a full picture). > > (4) Now I'm trying to add a PrimaryKeyConstraint and things are going to crap > again. See http://pastebin.com/1tQEWh71 . Is there some additional magic that > I'm missing? keep_existing would work better here. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
