You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Marcin Skladaniec <ma...@ish.com.au> on 2008/03/27 15:33:55 UTC
GSoC2008, a project proposal
Hello
I've been using open source software, and Cayenne in particular, for
quite some time now. Now finally comes a great opportunity for me to
contribute something back to the open source world.
It is sad that I could not do much until the incentive from Google
came along, but let me just blame the fact that I'm a busy student...
I have already talked to Andrus about the possible projects I could
undertake, and to my great contentment he liked the idea of
implementing inheritance in Cayenne and agreed to be my mentor for
SoC2008.
I put together a proposal, and at the end of this email you can find
the most important fragment of it (I skipped all the 'why me' bits ).
Any feedback is most welcomed !
Best regards
Marcin
"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.
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.
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.
There are few ways of designing inheritance, mentioned before flat
inheritance, vertical inheritance and horizontal inheritance. I would
like to explain differences between them to explain what I would like
to do. I'll use an example to illustrate each type, in the examples
I'll use notation Table[field1, field2,..] to describe the database
structure and Entity<field1, field2,...> to describe entities.
Without inheritance a database table is simply mapped to a java class
(which is often called an entity).
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.
Flat inheritance does use a single table, but allows mapping this
table into several entities. There are some benefits of this type of
inheritance like it does not require any joins, likewise inserting
data does affect only one table. Using flat inheritance has only
limited usage, and if used to extensively leads to tables with too
many columns to be readable and understandable.
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.
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. "
Re: GSoC2008, a project proposal
Posted by Andrus Adamchik <an...@objectstyle.org>.
There's something with the Confluence user search - it hangs
indefinitely, so I can't modify any groups. Let me ping infra on that.
Andrus
On Mar 28, 2008, at 10:20 AM, Aristedes Maniatis wrote:
>
> On 28/03/2008, at 7:15 PM, Andrus Adamchik wrote:
>>
>> On Mar 28, 2008, at 1:21 AM, Marcin Skladaniec wrote:
>>>>
>>>> http://cayenne.apache.org/doc/inheritance-overview.html
>>>
>>> I don't know how it happened that I have not found this page. It
>>> is everything I was trying to explain...
>>
>> It was not linked from anywhere (I guess because those things are
>> not yet implemented), so even though I knew it was there, it took
>> me a while to find.
>
>
> I wrote it and I'd forgotten it existed. I was about to start
> writing it all over again...
>
> If you are able, perhaps you could give me access to the Confluence
> setup pages and I'd like to look over the export plugin template to
> see if there is a way to add a search feature on the Cayenne site.
>
>
> Cheers
> Ari
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
Re: GSoC2008, a project proposal
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 28/03/2008, at 7:15 PM, Andrus Adamchik wrote:
>
> On Mar 28, 2008, at 1:21 AM, Marcin Skladaniec wrote:
>>>
>>> http://cayenne.apache.org/doc/inheritance-overview.html
>>
>> I don't know how it happened that I have not found this page. It is
>> everything I was trying to explain...
>
> It was not linked from anywhere (I guess because those things are
> not yet implemented), so even though I knew it was there, it took me
> a while to find.
I wrote it and I'd forgotten it existed. I was about to start writing
it all over again...
If you are able, perhaps you could give me access to the Confluence
setup pages and I'd like to look over the export plugin template to
see if there is a way to add a search feature on the Cayenne site.
Cheers
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: GSoC2008, a project proposal
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Mar 28, 2008, at 1:21 AM, Marcin Skladaniec wrote:
>>
>> http://cayenne.apache.org/doc/inheritance-overview.html
>
> I don't know how it happened that I have not found this page. It is
> everything I was trying to explain...
It was not linked from anywhere (I guess because those things are not
yet implemented), so even though I knew it was there, it took me a
while to find.
Andrus
Re: GSoC2008, a project proposal
Posted by Marcin Skladaniec <ma...@ish.com.au>.
> http://cayenne.apache.org/doc/inheritance-overview.html
I don't know how it happened that I have not found this page. It is
everything I was trying to explain...
>
> 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.
All your feedback is very important, I'll fix the proposal and
hopefully commit it to google on weekend.
Thank you
Marcin
Re: GSoC2008, a project proposal
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 28/03/2008, at 4:25 AM, Andrus Adamchik wrote:
> BTW, here is a page that Ari created that outlines the 3 varieties:
>
> http://cayenne.apache.org/doc/inheritance-overview.html
I have a set of other notes as well from when I started working on
inheritance, some on paper, some in a long thread on this list and
some in my brain. If you get this GSoC project we'll definitely sit
down and I'll work with you to document everything that has been
discussed and already decided. Some, but all of it, is in that page.
I'm very happy that even if I never got the time to spend on it as I
planned, that you are able to work on it.
Ari Maniatis
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: GSoC2008, a project proposal
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
Re: GSoC2008, a project proposal
Posted by Robert Zeigler <ro...@puregumption.com>.
It's worth noting that "derived entities" and "inheritence" aren't
the same concept in cayenne.
Dervied entitities are essentially database "views", modified by a
query.
Also, cayenne has supported what you can "flat" inheritence (single-
table inheritence) for some time now.
(For as long as I've been using it, which is over 4 years now).
Robert
On Mar 27, 2008, at 3/279:33 AM , Marcin Skladaniec wrote:
> Hello
>
> I've been using open source software, and Cayenne in particular, for
> quite some time now. Now finally comes a great opportunity for me
> to contribute something back to the open source world.
> It is sad that I could not do much until the incentive from Google
> came along, but let me just blame the fact that I'm a busy student...
>
> I have already talked to Andrus about the possible projects I could
> undertake, and to my great contentment he liked the idea of
> implementing inheritance in Cayenne and agreed to be my mentor for
> SoC2008.
> I put together a proposal, and at the end of this email you can find
> the most important fragment of it (I skipped all the 'why me' bits ).
>
> Any feedback is most welcomed !
>
> Best regards
> Marcin
>
>
>
> "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.
>
> 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.
> 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.
>
> There are few ways of designing inheritance, mentioned before flat
> inheritance, vertical inheritance and horizontal inheritance. I
> would like to explain differences between them to explain what I
> would like to do. I'll use an example to illustrate each type, in
> the examples I'll use notation Table[field1, field2,..] to describe
> the database structure and Entity<field1, field2,...> to describe
> entities.
>
> Without inheritance a database table is simply mapped to a java
> class (which is often called an entity).
> 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.
>
> Flat inheritance does use a single table, but allows mapping this
> table into several entities. There are some benefits of this type of
> inheritance like it does not require any joins, likewise inserting
> data does affect only one table. Using flat inheritance has only
> limited usage, and if used to extensively leads to tables with too
> many columns to be readable and understandable.
> 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.
>
> 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. "
>
>
>
>
>
Re: GSoC2008, a project proposal
Posted by Mike Kienenberger <mk...@gmail.com>.
Sounds great!
I have simulated vertical inheritance using complex entity templates.
I look forward to seeing the real thing as the simulated design did
not handle complex queries.
On 3/27/08, Marcin Skladaniec <ma...@ish.com.au> wrote:
> Hello
>
> I've been using open source software, and Cayenne in particular, for
> quite some time now. Now finally comes a great opportunity for me to
> contribute something back to the open source world.
> It is sad that I could not do much until the incentive from Google
> came along, but let me just blame the fact that I'm a busy student...
>
> I have already talked to Andrus about the possible projects I could
> undertake, and to my great contentment he liked the idea of
> implementing inheritance in Cayenne and agreed to be my mentor for
> SoC2008.
> I put together a proposal, and at the end of this email you can find
> the most important fragment of it (I skipped all the 'why me' bits ).
>
> Any feedback is most welcomed !
>
> Best regards
> Marcin
>
>
>
> "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.
>
> 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.
> 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.
>
> There are few ways of designing inheritance, mentioned before flat
> inheritance, vertical inheritance and horizontal inheritance. I would
> like to explain differences between them to explain what I would like
> to do. I'll use an example to illustrate each type, in the examples
> I'll use notation Table[field1, field2,..] to describe the database
> structure and Entity<field1, field2,...> to describe entities.
>
> Without inheritance a database table is simply mapped to a java class
> (which is often called an entity).
> 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.
>
> Flat inheritance does use a single table, but allows mapping this
> table into several entities. There are some benefits of this type of
> inheritance like it does not require any joins, likewise inserting
> data does affect only one table. Using flat inheritance has only
> limited usage, and if used to extensively leads to tables with too
> many columns to be readable and understandable.
> 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.
>
> 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. "
>
>
>
>
>
>
>