Hi, thanks for quick reply Mike. Let's say the user has three models as
defined in the SA joined table inheritance
docs<http://docs.sqlalchemy.org/en/rel_0_9/orm/inheritance.html#joined-table-inheritance>.
Now the user applies versioning to these models. One way I could model
these relationships is only apply the versions relationships to all 'leaf
classes' in other words classes that are the leaf nodes in the join table
inheritance tree.
So in this example I could apply those relationships to Manager and
Engineer classes. This means the Employee class wouldn't have versions
relationship. I think this is not a problem IF the user has set
with_polymorphic=True on the Employee class since then instances of
Employee class are never returned by SA queries.
However what should happen if user doesn't have with_polymorphic as True
and he tries to access versions relation of Employee model? If the versions
relationships are only defined in leaf classes then the Employee model
wouldn't have this relationship. I don't know if this is a huge problem
though.
The other way of modeling the versions relationship would be apply it to
Employee model and set with_polymorphic=True on the EmployeeVersion class.
This would work on all cases but lead to somewhat inefficient queries in
some cases (if there are lots of classes in the inheritance tree, these
classes are always joined in the queries).
What do you think would be the best way of modeling the versions
relationship on this kind of setting?
- Konsta
On Friday, April 11, 2014 12:02:15 AM UTC+3, Michael Bayer wrote:
>
>
> Not sure what the appropriate answer is, obviously the warning is there
> because people were mis-configuring their relationships and getting the
> wrong results. What exactly is the use case for restating the same
> relationship several times under the same name? If these relationships
> extend from a joined- or single-table inheritance relationship,
> relationally it doesn’t make much sense for the relationship to be stated
> differently from the base. If using concrete inheritance, the warning is
> not emitted, since relationships aren’t propagated to child objects.
>
> Also I don’t have test coverage for relationships operating in this way,
> so I can’t guarantee without full support of this feature if whatever
> you’re doing will continue to work with new releases.
>
> The easiest approach may be to add a relationship() flag that says
> “propagate=False” to force subclass propagation off but as always better
> understanding of the use case is needed to determine the best approach.
>
> On Apr 10, 2014, at 4:50 PM, Konsta Vesterinen
> <konsta.v...@gmail.com<javascript:>>
> wrote:
>
> Well the problem is this functionality will be part of
> SQLAlchemy-Continuum (versions relationships for entities using join table
> inheritance). It would be ugly if an extension for SQLAlchemy would throw
> warnings for certain mapper scenarios.
>
> Also I'm using warnings.simplefilter('error', sa.exc.SAWarning) on every
> project, since in general I want my tests and code to fail if some part of
> SQLAlchemy throws a warning.
>
> - Konsta
>
>
> On Thursday, April 10, 2014 11:41:55 PM UTC+3, Michael Bayer wrote:
>>
>> what happens if you just ignore the warning? i think it might work
>> anyway:
>>
>> from sqlalchemy import *
>> from sqlalchemy.orm import *
>> from sqlalchemy.ext.declarative import declarative_base
>>
>> Base = declarative_base()
>>
>> class A(Base):
>> __tablename__ = 'a'
>>
>> id = Column(Integer, primary_key=True)
>>
>> d = relationship("D")
>>
>> class B(A):
>> __tablename__ = 'b'
>>
>> id = Column(ForeignKey('a.id'), primary_key=True)
>>
>> d = relationship("D", collection_class=set)
>>
>> class C(A):
>> __tablename__ = 'C'
>>
>> id = Column(ForeignKey('a.id'), primary_key=True)
>>
>> d = relationship("D", collection_class=set)
>>
>> class D(Base):
>> __tablename__ = 'd'
>>
>> id = Column(Integer, primary_key=True)
>> aid = Column(ForeignKey('a.id'))
>>
>> e = create_engine("sqlite://", echo=True)
>> Base.metadata.create_all(e)
>>
>> sess = Session(e)
>>
>> b1 = B()
>> a1 = A()
>> a1.d.append(D())
>> b1.d.add(D())
>> sess.add_all([a1, b1])
>> sess.commit()
>>
>> print a1.d
>> print b1.d
>>
>>
>>
>> On Apr 10, 2014, at 8:41 AM, Konsta Vesterinen <konsta.v...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I have a situation where I have three classes A, B and C with B and C
>> inheriting class A.
>>
>> Now each of these classes also has a version class, lets call them
>> AVersion, BVersion and CVersion. The inheritance tree is the same: BVersion
>> and CVersion inherit AVersion. What I want to achieve is A having
>> relationship to AVersion, B having a relationship to BVersion and C having
>> a relationship to CVersion. I ran into problems when trying to name these
>> relationships with same name 'versions'.
>>
>> The problem is this causes a naming collision:
>>
>> SAWarning: Property A.versions on Mapper|B|b being replaced with new
>> property B.versions; the old property will be discarded
>>
>> How can I achieve this with keeping the relationship names on all classes
>> as 'versions'? The relationship on all classes can be viewonly, hence this
>> shouldn't have any effect on session dependency processing.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sqlalchemy+...@googlegroups.com.
>> To post to this group, send email to sqlal...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sqlalchemy.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy+...@googlegroups.com <javascript:>.
> To post to this group, send email to sqlal...@googlegroups.com<javascript:>
> .
> Visit this group at http://groups.google.com/group/sqlalchemy.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
