Inheritance - database blowup?
sledorze
holding all derived classes values.
This clearly does not scale very well.
I wonder if the next backend will have the same behavior?
Stephane
David Martinho
I was once told that Fenix-Framework uses by default what Martin Fowler calls Single Table Inheritance. Such fact leads to that single table you've mentioned with all the derived class fields. Nonetheless, i think there is an option to change that behavior and use other approaches like Concrete Table Inheritance, where one table is used for each concrete class, or a Class Table Inheritance approach, which uses one table for each existing class.
I don't know if Fenix-Framework uses strict implementations of these approaches that i've just described, but i think it has something to do about the deep of inheritance.
For instance, the FénixProject uses Fénix-Framework where i believe all its domain classes inherit from a DomainObject class. You can imagine that storing all that information in a single table would not be very well manageable in a webapplication which uses hundreds of classes.
However, i cannot confirm this information. Therefore, i think you should wait for a developer's reply =) correcting or confirming this information.
Hope i didn't mislead anyone to error,
David
David Martinho
Email: david (dot) martinho (at) inov (dot) pt
Tel: (+351) 92 756 16 97
Web: http://web.ist.utl.pt/davidmartinho/
Joao Cachopo
> When using inheritance; the actual SQL backend generates one Table
> holding all derived classes values.
That happens because all of your domain entities extend a single entity
type, right?
As David said, for historical reasons and as a legacy of how FenixEDU
used the OJB, it uses the "Single Table Inheritance" pattern, meaning
that each class hierarchy is stored in one table.
So, you have as many tables in the database as entities in the DML that
do not extend any other entity.
In the case of the FenixEDU webapp, even though all entities extend a
given one, the code of the fenix-framework deals with this specially and
applies the same "Single Table Inheritance" starting with the second
level of the class hierarchy.
> This clearly does not scale very well.
> I wonder if the next backend will have the same behavior?
This is one of the things that we would like to change, yes.
But only after we get rid of the OJB.
In the meantime, if this proves to be a problem for you, we may find an
interim workaround that generalizes what we are doing for the FenixEDU
webapp.
Best regards,
--
João Cachopo
Stephane Le Dorze
Thanks!
Joao Cachopo
> I don't think it is a problem in the short term; however something I
> do not understand is that I thought we were using the same
> implementation than the FenixEDU.. (I was relying on the fact that it
> would really proves that the current Fenix implementation works) It
> appears this is not the case; when do you upgrade the FenixEDU code?
It is the same implementation used in the FenixEDU webapp.
As you say, that is a development decision that we made and that I
intend to follow as much as possible: that the head of the trunk of the
fenix-framework is always the production-ready version that is used by
the FenixEDU webapp.
What makes the fenix-framework code work differently for the FenixEDU
webapp is a test in the code of the fenix-framework that specifically
checks for a class in the domain model called
net.sourceforge.fenixedu.domain.DomainObject (which is the root of the
FenixEDU domain model), and that ignores it in what concerns the
generation of the database tables and mappings.
> I wonder, for the sake of modeling choices, what would be the specs of
> the generalization (parametrable depth?) in case it becomes a problem.
I haven't thought much about it yet, so I don't know for sure how it
would be, but probably it would be something that you specify as a
parameter to the DML compiler, or a parameter in the Config, yes.