Please use the google group to ask questions - thanks.

Ok, wrt "Ebean does not support DDL generation "... a number of people eventually convinced me to change and since v2 Ebean does generate DDL from the annotated entity beans.

That said, it seems to me you are wanting a tool to generate the alter table statements required when the model changes? Say, add a property... and you want the alter table add column DDL. Is that the case?

If so, Ebean is not currently capable of generating that DDL (identifying the added column and generating the alter table add column DDL).

I'd guess it depends on how big your model is, how drastically your model changes, and how frequently those changes are.

"since v2 Ebean does generate DDL from the annotated entity beans."

Ah, yes, in fact, I've used the DDL generation already (though, because I was not able to change the foreign key delete/update rule, I had to change a bit on the resulting SQL file).

"Say, add a property... and you want the alter table add column DDL. Is that the case?"

Yes, that would be perfect. ActiveObjects reaches the goal similarly.

"I'd guess it depends on how big your model is, how drastically your model changes, and how frequently those changes are."

It's quite large, with more than 40 tables, and I expect it to change quite a lot, as the application will evolve much after the first release, but these changes primarily mean adding tables, fields and constraints, and perhaps changing field types.

Thinking about a way to do this... I suggest generating an XML document from the model (aka like DDL generation but generate as XML representing the tables/entitis columns/properties).

Then when the model changes you generate the XML again and now have 2 XML documents representing the model. Then use some XML processing to find changes in the model and generate appropriate DDL (alter table statements etc).

In the best world there would be a modelling tool that would the same XML document.

That is probably what I'd suggest we could do with Ebean to support this requirement.

How does that sound?

Sorry for the late answer.

At first glance, it seems easier to manage the differences between two object hierarchies than those between two XML files, but if it's easier to produce the XML files (rather than an object hierarchy) then this solution is also fine. :)

Hmmm, I don't really understand how to 'manage the differences between the two object hierarchies'... in that the 2 object hierarchies don't exist at the same time (same JVM execution) ... so my thinking was you need to persist the object hierarchy information between JVM executions... hence saving that information in the form of XML.

Perhaps I am missing your point altogether?

Sorry, I should have been clearer.
We have now 3 different solutions:

1) To generate an object hierarchy from the database schema and compare that to a similar object hierarchy generated from the current entity bean classes. This was my original idea as this is how ActiveObjects solves the problem. An advantage of this approach that it can work even with a broken database, so in this regard this seems the stablest solution of the 3.
2) An EbeanServer.createSchemaXml(filename) function that generates an XML file from the current entity schema. After two calls, a built-in or a manually written function can compare them. This was your solution as far as I see.
3) An EbeanServer.generateSchema() function generates an object hierarchy from the entity bean classes similar to that of solution 1. Then it can be saved into an XML file, with the help of a built-in function or an outer library. Next time, the result of the generateSchema() call can be compared to the result of the parsed version of the previously saved XML file. It's almost the same as solution 2, but there is no need to build an object hierarchy manually from an XML, as the comparison can be made at a middle level representation.

What I was trying to say that from solution 2) and 3) the latter would be preferable (at least for me), as the comparison is easier to implement on that level. But if, for some reason, it is much easier to produce an XML file in a "serial" matter without representing the whole as an object hierarchy of database, tables and fields, then the 2nd solution is also fine. :)

>> 1) To generate an object hierarchy from the database schema ...

So "object hierarchy" means some sort of in memory representation of the meta data.

Assuming everything in the DB is represented in the application... you want to compare the java side to the DB dictionary effectively. Hmmm.

Maybe getting ahead too far ... but basically I think of the "object hierarchy" as a dictionary. In ORM terms this is meta data about the DB schema and the Java Object mapping.

Via 1) or 2) Ebean builds this 'meta data dictionary' and can optionally store/load it as an XML file.

You can then have Forward and Reverse generation tools to generate java from DB and DB from Java (as incremental diffs between versions of the meta data dictionary).

You can also build a modelling tool to represent and edit the tables/java entities.

Anyways... that may not help but those are the thoughts in the back of my head.

... and you can use the dictionary to generate other things like DB trigger code for auditing etc... and extend the DDL generation to support tablespaces and the like.