building SQLAlchemy apps graphically, that's extremely challenging good luck !
On May 1, 2012, at 5:19 AM, lars van gemerden wrote:
> Well thats the thing, my users will determine the data structure
> (graphically) and it is hard to predict what they will come up with.
> On the other hand, I am only building a prototype at the moment, so
> speed issues (if not easily solved) will have to wait.
>
> I'll stick with joined inheritance for now (though I'll probalby take
> out the unique base class for all classes).
>
> Thank you again for all the help,
>
> Lars
>
> On Apr 27, 3:59 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
>> concrete inheritance is very challenging overall, if you expect there to be
>> any kind of polymorphic interaction between the classes. if you want to
>> query polymorphically then speed will be probably worse. If you can do
>> without polymorphic and stick to each subclass directly it wont have an
>> issue.
>>
>> Usually though if I'm inheriting more than two levels, I'll use joined
>> inheritance for level one->two then single table for all levels beyond that.
>> Depends on what you're trying to do.
>>
>> On Apr 27, 2012, at 3:05 AM, lars van gemerden wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Ok, so speed might become an issue for me as well;
>>
>>> Do you think a similar metaclass approach would work for concrete
>>> inheritance would work without major drawbacks (before i do a major
>>> overhaul)?
>>> Is there any indication about how much faster concrete inheritance is,
>>> compared to joined inheritance?
>>
>>> Cheers, Lars
>>
>>> On Friday, April 20, 2012 9:32:49 PM UTC+2, Michael Bayer wrote:
>>
>>> On Apr 20, 2012, at 8:51 AM, lars van gemerden wrote:
>>>> Ok, thank you, that helps, but now i cannot inherit from Engineer, as in:
>>
>>>> class BaseMixin(object):
>>
>>>> discriminator = Column(String(50))
>>
>>>> @declared_attr
>>>> def __tablename__(cls):
>>>> return cls.__name__
>>>> @declared_attr
>>>> def id(cls):
>>>> return Column(Integer, primary_key = True)
>>>> @declared_attr
>>>> def __mapper_args__(cls):
>>>> if not has_inherited_table(cls):
>>>> return {'polymorphic_on': 'discriminator'}
>>>> else:
>>>> return {'polymorphic_identity': cls.__name__}
>>
>>>> class InheritMixin(BaseMixin):
>>>> @declared_attr
>>>> def id(cls):
>>>> super_id = super(InheritMixin, cls).id
>>>> return Column(Integer, ForeignKey(super_id), primary_key = True)
>>
>>>> class Person(BaseMixin, Base):
>>>> name = Column(String(50))
>>
>>>> class Engineer(InheritMixin, Person):
>>>> job = Column(String(50))
>>
>>>> class MasterEngineer(InheritMixin, Engineer):
>>>> specialty = Column(String(50))
>>
>>>> Gives an MRO() error and if i would reverse the baseclasses (like class
>>>> Engineer(Person, InheritMixin): ... ), the inheriting classes pick up the
>>>> wrong id.
>>
>>>> Do you see any solution for this?
>>
>>> yeah I suppose if you're building out joined inheritance more than one
>>> level then this becomes awkward. I never use joined inh more than one
>>> level because it has too much of an impact on queries.
>>
>>> the metaclass as you mention is always the last resort when the various
>>> declarative trickery reaches its limit. I'm not thrilled about the
>>> metaclass approach because it quickly gets confusing and shouldn't be
>>> necessary. though in this case without some extra mechanism on
>>> declarative, such as a __pre_declare__() method of some kind, it might be
>>> the only approach.
>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "sqlalchemy" group.
>>> To view this discussion on the web
>>> visithttps://groups.google.com/d/msg/sqlalchemy/-/MH4tZazKT0EJ.
>>> 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
>>> athttp://groups.google.com/group/sqlalchemy?hl=en.
>
> --
> 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.
>
--
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.
