Hi all,
I'm new using Hibernate and, after some days playing with it, i have some questions i couldn't find an answer in the docs:
1)
Is there some strong argument against having a common superclass for all objects in my model (like Java's Object) using "Table per subclass with discriminator" approach? If my application will have about 50 - 100 classes, could it create a kinf of bottleneck? I can imagine something like this:
superclass
individual
customer
supplier
employee
material
finalproduct
textile
yarn
invoices
... and so on ...
2)
In my tests, i saw that using "from superclass" produces a query left joining all subclasses tables. Can i avoid this using a different fetching strategy (select fetching, for example)? Altought "from superclass" will be rarely used, i'd like to know if it's possible.
3)
I liked a lot "Table per subclass with discriminator" approach, but i'd like to have cascaded deletes in the fk's created in the database, so if i manually delete a record in the superclass table, the subclasses records will be deleted too.
Looking at "5.1.15. subclass" and "5.1.18. join", that are the basic declarations used in table per subclass, i don't see a way to achieve this.
4)
I read this about Table per subclass in 9.1.3 topic:
The approach taken by Hibernate is much more difficult to implement but arguably more correct from a relational point of view. If you would like to use a discriminator column with the table per subclass strategy, you may combine the use of <subclass> and <join>, as follow:
I don't understand why Table per subclass is more correct than Table per subclass with discriminator. I think that having a discriminator in the superclass is very usefull to know exactly subclass type of that record, this way you can look directly to the right subclass table. Am i missing something?
5)
Will annotations be part of core Hibernate in the future. If yes, how far is this future? For begginers, do you recomend the standard mapping or annotations is better?
I think it's enought for now.
Regards,
Fabiano.
|