Michael Bayer wrote:
as far as implementation this feature isn't on
my personal radar, so if you really want anytime soon you should provide a
patch, which I can of course help with.
Cool, it is on my radar, but sadly pretty far away :-(
you know, doing the metaclass approach is probably the
Chris Withers wrote:
Michael Bayer wrote:
as far as implementation this feature isn't on
my personal radar, so if you really want anytime soon you should
provide a
patch, which I can of course help with.
Cool, it is on my radar, but sadly pretty far away :-(
you know, doing the metaclass
Michael Bayer wrote:
well mapper_args is args that go to the mapper. Its a little unclean
IMHO to reuse that same dict for declarative purposes. Id rather have
another attribute like __declarative_abstract__ = True or something like
that (ideas welcome).
__declaratice_abstract__ = True
On Jan 1, 2010, at 5:09 PM, Chris Withers wrote:
Michael Bayer wrote:
well mapper_args is args that go to the mapper. Its a little unclean
IMHO to reuse that same dict for declarative purposes. Id rather have
another attribute like __declarative_abstract__ = True or something like
that
Michael Bayer wrote:
Michael Bayer wrote:
The Column objects you declare within declarative become members of
the underlying Table object, so its not as simple as just having
those members present on a mixin - what would really be needed would
be some sort of copying of each column object
Chris Withers wrote:
Michael Bayer wrote:
Michael Bayer wrote:
The Column objects you declare within declarative become members of
the underlying Table object, so its not as simple as just having
those members present on a mixin - what would really be needed would
be some sort of copying of
Michael Bayer wrote:
Uh oh:
sqlalchemy.exc.ArgumentError: Mapper Mapper|Employee|employee could not
assemble any primary key columns for mapped table 'employee'
...which makes me wonder if the class decorator would actually work at
all. Surely it'll only kick in after the DeclarativeMeta
Chris Withers wrote:
But agreed, make your mixin implement a marker class from the
declarative
module (MixinsDeclarative, i dunno),
How about just a marker attribute? How about something in
__mapper__args__, which already exists?
class MyMixin:
__mapper_args__ = {'abstract':True}
(sorry, missed this earlier)
Michael Bayer wrote:
The Column objects you declare within declarative become members of
the underlying Table object, so its not as simple as just having
those members present on a mixin - what would really be needed would
be some sort of copying of each column
On Dec 17, 2009, at 1:59 PM, Chris Withers wrote:
(sorry, missed this earlier)
Michael Bayer wrote:
The Column objects you declare within declarative become members of
the underlying Table object, so its not as simple as just having
those members present on a mixin - what would really be
Hi together,
I'm sorry if this is a rather stupid question, but i havent found a
solution yet :/
I have a few models build with the DeclarativeBase-Class. Now each of
these models has a few columns that they have in common (created_by,
created_at, updated_by, updated_at). Rather than putting the
On Dec 13, 2009, at 12:09 PM, Daishy wrote:
Hi together,
I'm sorry if this is a rather stupid question, but i havent found a
solution yet :/
I have a few models build with the DeclarativeBase-Class. Now each of
these models has a few columns that they have in common (created_by,
12 matches
Mail list logo
