Sorry I didn't look closely. Yes when you subclass FKC overriding _set_parent() to perform additional steps is one way to establish on-connect details. Another is to use event.listen(ImplicitForeignKeyConstraint, "after_parent_attach"), it would be a little more of the public API.
On Aug 6, 2011, at 2:01 AM, Fayaz Yusuf Khan wrote: > So IFKC(ImplicitForeignKeyConstraint) should not have inherited FKC? I did it > so that it could seamlessly be passed into Table() and __table_args__. > > PS: Everyone, the repo is at https://bitbucket.org/fayaz/implicit > > On Friday, August 05, 2011 07:31:44 PM Michael Bayer wrote: >> yeah wow I just saw that. Can you use table.add_constraint(fk) instead >> of _set_parent() ? >> >> On Aug 5, 2011, at 1:34 AM, Fayaz Yusuf Khan wrote: >>> So I had been working on this tiny project now and then. And here's the >>> poc. http://paste.pound-python.org/show/10578/ >>> I think I'm somewhat misusing the _set_parent() here though. >>> >>> On Sunday, July 24, 2011 06:52:45 PM Michael Bayer wrote: >>>> On Jul 24, 2011, at 8:39 AM, Fayaz Yusuf Khan wrote: >>>>> The problem with using different mixins is that you lose out on a lot >>>>> of code reusability. In my case, I have a 'user' column that appears >>>>> in almost all table declarations. To have a separate mixin class for >>>>> each joint-table inheritance would destroy the purpose of having a >>>>> mixin altogether. >>>> >>>> In your example you can simply use CMixin and TMixin separately instead >>>> of inheriting them from one another, then apply CMixin and TMixin >>>> directly to C individually. That makes more sense here since for >>>> every class X which you want to have "user", you'd apply CMixin >>>> explicitly. The more I look at this the more it seems completely >>>> correct to me. Mixins and declarative do a lot , and sticking to >>>> Python's regular rules for inheritance is what makes them great. >>>> >>>>> Perhaps, there should be a shorthand for implicitly creating columns >>>>> along with foreign key constraints? >>>>> >>>>> So something like >>>>> >>>>> ImplicitForeignKeyConstraint( >>>>> >>>>> ['user', 'timestamp'], >>>>> ['Timeline.user', 'Timeline.timestamp'], primary_key=True) >>>>> >>>>> should lead to the creation of >>>>> >>>>> Column('user', String, primary_key=True), >>>>> Column('timestamp',Integer, autoincrement=False, primary_key=True), >>>>> ForeignKeyConstraint( >>>>> >>>>> ['user', 'timestamp'], >>>>> ['Timeline.user', 'Timeline.timestamp']) >>>> >>>> Not something for core but certainly something you could provide >>>> yourself (use append_column()). SQLA's APIs try to remain explicit >>>> about things leaving "implicit helper" layers as an external task >>>> (hence relationship + ForeignKey, as opposed to the "all in one" demo I >>>> did at http://techspot.zzzeek.org/2011/05/17/magic-a-new-orm/ , etc) > > -- > Fayaz Yusuf Khan > Cloud developer and designer > Dexetra SS, Kochi, India > fayaz.yusuf.khan_AT_gmail_DOT_com > fayaz_AT_dexetra_DOT_com > +91-9746-830-823 -- 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.
