Please use the google group to ask questions - thanks.

by vannevar 16 Dec 08:00
DDL generation

You say about DDL generation that "Ebean does not support DDL generation from annotations and I personally have no interest in this idea. There are good tools to design and document a database and generate the DDL."

I chose Ebean instead of Hibernate for my application because it uses separated, detached client databases, and I wanted to ease my database access with an ORM tool but didn't need the complexity of Hibernate. I hesitated between ActiveObjects and Ebean but at the end I chose Ebean because it avoids using separate (duplicated) Entity beans, so it seemed more comfortable to use.

But then, a requirement for my application would be to have transparent updates as bugs are constantly fixed and slight changes are made. At updates, the client database structure may slightly change. Of course, the client who updates its application should not lose his own data so I need a solution that automatically updates the underlying database structure reflecting the applications needs without modifying existing data. It would be very nice if that would be possible to make with minimal extra effort needed.

I don't know how this task could be done with the tools you mention, and it seems a commonly needed task. Is there an external tool that is able to do it in a JPA compatible mode?

At the moment, it seems to me that I have two choices: Either I make this DDL generation tool myself, or I rewrite the application using ActiveObjects which - if I understood it correctly - supports this very task. I'm not quite sure yet which is the quicker approach (unfortunately I have no choice but using the quickest solution). But it would be a pity if I had to choose the latter as Ebean is great otherwise.

And then, if the first approach is the quicker, would you be interested in the result?

16 Dec 09:30
by Rob

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.

17 Dec 17:21
by vannevar

"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.

20 Dec 09:42
by Rob

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?

04 Jan 13:26
by vannevar

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. :)

06 Jan 21:49
by Rob

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?

12 Jan 22:51
by vannevar

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. :)

13 Jan 10:39
by Rob

>> 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.

13 Jan 10:49
by Rob

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.

13 Jan 10:57
by Rob

... 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.

Create a New Topic

Introduction User Guide (pdf) Install/Configure Public JavaDoc Whitepapers
General Database Specific Byte Code Deployment Annotations Features
Top Bugs Top Enhancements