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)
--
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.
