Automated table creation issues
buzden opened this issue · comments
Why doesn't JirmDao create table for an inserted object's class automatically or, at least, why JirmDao doesn't have any method to create that new table for the given class? It's not really convenient to create all tables manually after I've annotated all classes -- why should I repeat the same information about the fields twice?
Have I missed something? Probably automatic tables creation is done not by the JirmDao? Or, probably, the task of automatic tables creation is not solvable but I don't feel why?
DDL generation was out of scope for now. And automatic schema evolution like Hibernate is very out of scope and will probably never be done.
There are many that feel DDL generation is dangerous and misleading. I think a stand alone tool that uses JPA annotations to generate DDL is an interesting idea. The evolution (ALTER statements) you would have to manage on your own but you could do that by diffing with your source control with the generated output and then updating the evolution scripts and use an evolution manager like Flyway.
The other thing to note is that JIRM is not really aiming to be an ORM but more of a mapper like MyBatis and then maybe EBean being a distant counterpart. Both tools do not recommend auto DDL creation. Hibernate Schema evolution is definitely not recommend for production systems.
That being said if you really want automatic schema evolution letting Hibernate do your schema evoution and then just not using Hibernate is an option.
Do you think Hibernate would agree to generate DDLs by my classes which do not conform Hibernate entities requirements?
And, if Hibernate finally would do this somehow, how would JIRM correctly use Hibernate's tables? Am I right that JIRM supposes that ORM inheritance type is "single table" (that probably means that JIRM can nicely deal with Hibernate's tables created as "single tables")? Can other inheritance types be pretty easily used by JIRM?
The JIRM Dao portion assumes single table with references to other tables.
Immutable objects and databases prefer composition over inheritance. I'll give you an example. Lets say you have a whole bunch of meta data fields that many entities share. In JIRM you would make a property to a meta data object and not inherit from a super class that has the meta data fields. That is JIRM maps exactly how it would be in your database (a not null fkey to the meta data table).
Hibernate allows you to use inheritance independent of your schema which is nice in some regards as it flattens the class but is misleading if its not single table inheritance.
There is also another problem with inheritance though for immutable objects is that you can end up with constructors with hundreds of parameters. Also for most databases having tables with hundreds of columns is generally considered bad idea and is exactly what you get with single table inheritance. So again composition is preferred. This is one of the reasons why #28 was not solved.
However Jirm should support single table inheritance so that you don't have to write the "ID" field on every class but you will still have to have a constructor with all the parent fields. Thus when Jirm supports inheritance it will most likely be single table inheritance