Hi Marcin,
A few points adding to what Robert has already mentioned...
On Mar 27, 2008, at 4:33 PM, Marcin Skladaniec wrote:
> "There are several object-relational mapping (ORM) java frameworks
> in existence, and in my opinion Cayenne (http://cayenne.apache.org/)
> is one of the best. Cayenne has clear and consistent API, and great,
> most vibrant community I met in the open source world.
> Cayenne has many features you one would expect ORM to have, but it
> is lacking one important feature which is present in competing
> projects like Hibernate: inheritance. I would like to propose a
> Summer of Code project bringing inheritance to Cayenne.
Cayenne has single table inheritance fully working. So it is not
missing inheritance, just vertical and horizontal varieties of
inheritance mapping.
> At the moment Cayenne does support only some sort of flat
> inheritance (called 'derived entities' ), but it is already marked
> as deprecated and will be excluded from future versions.
It is already dropped from 3.0
> I believe (re)adding this feature is going to highly improve Cayenne
> as ORM, I have already found myself missing it few times when
> working on various database designs.
This may require some discussion. IIRC there was a thread on that in
the past, but I wouldn't call that inheritance, and for SoC I would
recommend to concentrate on *object* inheritance, which requirements
are well defined and well understood. BTW, here is a page that Ari
created that outlines the 3 varieties:
http://cayenne.apache.org/doc/inheritance-overview.html
> Example: If an application has an entity representing different
> payments each type of payment needs to be stored in separate table
> and will be mapped to a separate entity, ie.
> - CreditCardPayment[amount, bankedDate, ccNumber, ccExpiry, ...] <=>
> CreditCardPayment<amount, bankedDate, ccNumber, ccExpiry, ...>
> - ChequePayment[amount, dateBanked, chequeBank, ...] <=>
> ChequePayment<amount, dateBanked, chequeBank, ...>
> - CashPayment[amount, dateBanked, ...] <=> CashPayment<amount,
> dateBanked, ...>
> As can be seen some fields gets duplicated, and as there is no
> inheritance between the java classes the application ends up with
> plenty duplicate code. Also the relationships between the entities
> might get complicated, for example an Invoice would need to have
> separate relationship to each payment table.
Absolutely correct.
> Flat inheritance
Let's call it "single table" to be consistent with the established
terminology.
> Using flat inheritance has only limited usage, and if used to
> extensively leads to tables with too many columns to be readable and
> understandable.
The explanation is correct, but "limited usage" is an overstatement.
It is very useful and performs better than any other kind. So I guess
we shouldn't try to make a case that vertical/horizontal is better
than single table... It's just different, not better. All three have
their uses.
> Example: In the same situation as before there would be only one
> table defining all the fields :
> - Payment[amount, bankedDate, ccNumber, ccExpiry,...,
> chequeBank, ...] <=> CreditCardPayment<amount, bankedDate, ccNumber,
> ccExpiry, ...>, ChequePayment<amount, dateBanked, chequeBank, ...>,
> CashPayment<amount, dateBanked, ...>
> Modelling the relationships becomes much easier, but as each entity
> still is separate there is a high possibility of duplicate code.
Not true. There is a common superclass. Single table inheritance is a
real inheritance in a Java sense... Consider it a mapping technique
used to map a tree hierarchy of classes to a single table.
> Horizontal inheritance can be considered a small improvement over
> the no inheritance model, keeping the duplication of the fields on
> the database and entity level, but allowing to gather some code
> together. I'm finding this approach a little confusing and counter-
> intuitive, but it certainly has a reason behind: it does avoid the
> slowness related with vertical inheritance.
> Example:
> - (no database table) <=> Payment<amount, bankedDate, ...>
> implements/extends CreditCardPayment, ChequePayment, CashPayment
> - CreditCardPayment[ccNumber, ccExpiry, ...] <=>
> CreditCardPayment<ccNumber, ccExpiry, ...>
> - ChequePayment[chequeBank, ...] <=> ChequePayment<chequeBank, ...>
> - CashPayment[...] <=> CashPayment<...>
>
>
> Vertical inheritance escapes the problems of flat inheritance by
> storing data relevant to an entity in a dedicated table. Resulting
> database schema is cleaner and easier to maintain when adding new
> entities and tables. There is a cost linked with this type of
> inheritance: the database transaction speeds are lower, since each
> fetching query must use a join and storing data has to be executed
> against each table.
> Example: Again the same situation as in previous cases. In vertical
> inheritance there is a common table and common entity class finally
> creating a room for the code common to all Payments:
> - Payment[amount, bankedDate, ...] <=> Payment<amount,
> bankedDate, ...>
> - CreditCardPayment[ccNumber, ccExpiry, ...] <=>
> CreditCardPayment<ccNumber, ccExpiry, ...> extends Payment
> - ChequePayment[chequeBank, ...] <=> ChequePayment<chequeBank, ...>
> extends Payment
> - CashPayment[...] <=> CashPayment<...> extends Payment
>
>
> My Google Summer of Code is going to bring the inheritance to
> Cayenne. Certainly I would like to implement the vertical
> inheritance, albeit it might have performance impact, it also seems
> to be the most advanced model. If the time will allow I'll put my
> effort to also implement either flat or horizontal inheritance,
> consulting the Cayenne community to find which one is more
> anticipated. "
Again, I disagree that single table is inferior... There are three
classic ways to map OO inheritance hierarchy to the relational model.
We have one, we need one or two more to give users more flexibility.
Finally, please don't take my comments as a negative reaction. I am
very happy that we have this proposal and looking forward to working
with you on implementing them.
Cheers,
Andrus
This archive was generated by hypermail 2.0.0 : Thu Mar 27 2008 - 14:18:39 EDT