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
> So with kemi's DeclarativeMeta, you can write this and it'll add the
> foreign keys and primaryjoins for you:
>
> class Customer(Base):
> name = Column(String)
> billing_address = relationship("Address")
> shipping_address = relationship("Address")
>
> My implementation for this works OK _until_ some class defines its own
> table name, e.g.:
>
> class Address(Base):
> __tablename__ = 'myaddresses'
>
> By default, I convert the class name to lower case and use that for a
> table name.
so just in case you weren't aware, you should be using here:
Address.__table__.name
or
class_mapper(Address).local_table.name
If there's no Address or Table yet, then it's not yet time to make decisions
about it.
> For this default case, I'm able to derive the column for
> the ForeignKey that I need to create, so with a
> relationship("Address") I would assume a ForeignKey("address.id").
>
> 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.
> Is there maybe an event that I
> can use to finalize my ForeignKey target fullnames?
>
> kemi's code has a test that illustrates the problem:
> https://github.com/dnouri/kemi/blob/master/kemi/test.py#L101
>
> (Also, any thoughts that you might have on kemi's approach as a whole
> -- maybe someone already did this, please let me know.)
>
--
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.
