Mike, Thanks for the feedback!
> > (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). > Noted. > > (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 ... > 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 Yes, apologies, I realize now that I've abused your term "deferred." Indeed, all I'm trying to do is emulate the mixin pattern of model design for sqlalchemy.Table()s. I just want to be able to declare the Table()s before mixing them with the Base. The Paste (http://pastebin.com/1tQEWh71) shows one possible approach for a trivially small model, but I am open to other approaches. > > (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). I will try keep_existing and report back. > (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. Thanks! Kudos for the support and for all your hard work on the software. Best, ~br On Sat, Sep 13, 2014 at 11:01 AM, Michael Bayer <[email protected]> wrote: > > 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 a topic in the > Google Groups "sqlalchemy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sqlalchemy/VPleXpb5zLQ/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- 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.
