Gunnlaugur Briem wrote:
> Hi,
>
> I created a mapper inheriting from another mapper and overriding a
> relation definition, and got this warning:
>
> Warning: relation 'dimensions' on mapper 'Mapper|DataSetSlice|
> dataset_slice' supercedes the same relation on inherited mapper
> 'Mapper|DataSet|dataset'; this can cause dependency issues during
> flush
>
> I'd like to understand those dependency issues better (read: at all),
> to know whether they apply in my case.
>
> The new class I am mapping is class DataSetSlice(DataSet), which
> defines a slice out of another DataSet (identified by parent_id, a
> self-join on the dataset table), but is also a DataSet in its own
> right (fitting into our inventory/categorization system). So there is
> an inheritance relationship and also (separately) a parent/child
> relationship.
>
> A DataSet has dimensions (many-to-many), and a DataSetSlice logically
> has the same dimensions as its parent. So the DataSet mapper has this
> relation:
>
> dataset_mapper = mapper(DataSet, dataset_table
> ...,
> properties={
> 'dimensions': relation(Dimension,
> secondary=dataset_dimension_association,
> order_by=dataset_dimension_association.c.dimension_id,
> backref='referencing_datasets'
> ),
> })
>
> And the DataSetSlice (subclass) mapper has this instead:
>
> datasetslice_mapper = mapper(DataSetSlice, datasetslice_table,
> ...,
> properties={
> 'dimensions': relation(Dimension,
> secondary=dataset_dimension_association,
> primaryjoin=dataset_dimension_association.c.dataset_id
> == datasetslice_table.c.parent_id,
> foreign_keys=[dataset_dimension_association.c.dataset_id,
> dataset_dimension_association.c.dimension_id
> ],
> order_by=dataset_dimension_association.c.dimension_id,
> backref='referencing_dataset_slices'
> ),
> })
>
> The salient difference is that the primary join references parent_id
> in the subclass table instead of id in the superclass table --- but
> these are the same by a foreign key relationship. Thus I'm making a
> slice have the same dimensions as its parent.
Just to establish what I've understood here:
- there's two tables, dataset_table and datasetslice_table.
- these two tables have *two* foreign key references to each other - an
inheritance relationship (on unknown columns since they aren't displayed
here) and another on "parent_id" to "id", which is a one-to-many
association.
- for each row in dataset_table, a row in dataset_dimension_association
may exist.
- *however*, if a row in dataset_table also references datasetslice_table
via the inheritance relation, then there may *not* be a row in
dataset_dimension_association with that dataset_table's id - because the
mapping says that "dimensions" now needs to reference
dataset_dimension_association via *another* row in dataset_table which it
references via parent_id. This is a "constraint" that isn't expressed in
the schema but is implied by the mapping I see.
It's that last constraint that is very awkward here and is not in the
spirit of relational databases. It means that its impossible to create a
reasonable join from dataset_table to dataset_dimension_association, since
for some rows in dataset_table, the join is invalid.
The hypothetical issue as far as flush() is that both dimension relations
would have some interaction when working out dependencies and association
row values, even for a DataSetSlice object, and would incur conflicting
data. I'm not sure if that is the current behavior and would have to
verify, though the warning stays in place since with inheritance, you need
to look at relations from table hierarchy A to table B in terms of the
bottommost table in the A hierarchy - relational inheritance is not really
"polymorphic" in that way, for the "join" reasons I mention above.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
