On Mon, Mar 26, 2012 at 11:29 PM, Michael Bayer <mike...@zzzcomputing.com> wrote: > > On Mar 26, 2012, at 1:53 PM, Daniel Nouri wrote: > >> I'm trying to do a few (maybe too) clever things to make SQLA >> declarative relations less verbose for the most common cases, >> especially for when two relations to the same type exist, and >> therefore a 'primaryjoin' on the relationship is normally required. > > this will be simplified in 0.8, you'll be able to pass just foreign_keys in > this scenario, no primaryjoin will be needed
Sounds great. >> What I'm looking for is a more robust way of getting the table name. >> When the class itself is passed to relationship(Address), that's not >> an issue, but what if I only have the name of the class and that class >> is not inside the class registry yet? > > You should use the "mapper_configured" event - see the example at > http://techspot.zzzeek.org/2011/05/17/magic-a-new-orm/ . This example > should also start to reveal why I'm -1 on using custom metaclasses - the > events should provide a cleaner way to do these things. Thanks for the pointer. Wasn't aware of that magic.py. Quite a funny blog post, too! :-) I guess I'll think a bit more to see if I want to use this at all. It seems useful to only "fill in the blanks", and allow people to override using standard SQLA constructs (e.g. by specifying the foreign key themselves). I'm thinking maybe that's friendlier than requiring users to learn about a different relationship function. (Of course it'll break expectations elsewhere and it's more limited.) The primaryjoin is the reason I started this. The system I'm working with requires the primaryjoin basically everywhere where I make a new relation (most classes derive from a Node), and it's a bit of a stumbling block, so I'm happy to hear about the patch in 0.8. Daniel -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
