I need some input on how to create a pattern for how I am going to use Hibernate.

The project is a simple project with a fat client using hibernate directly.

I was thinking of doing it like this:
a) Reverse engineer the database
b) Refine the classes generated (for instance let the classes extend java.util.Observeable for use in the MVC pattern)
c) Update the database with the new fields I want
d) Reverse engineer the database again

The reason is that its actually faster to add a columns and new tables to a database and then reverse engineer than to create the classes, xml files, tables and columns, etc...

This does offcourse give me some problems as I loose the changes I just made to the classes.

Does anybody have any thoughts on how to solve this problem?

right now this would work, except for one small detail ;)

Reverse engineering must be extended to (optionally) put in a <meta attribute="generated-class">Base[yourclassnameHere]</meta> thus making it explicit which classes for which we generate a base class for instead of the concrete class (then when you generate we override the base class and not the concrete one)

OR

We'll have to implement an option for doing this transparently (without the meta tag) for all classes (I hate this, but apperently users understand it better when they have 200 classes instead of 100+the classes that actually need this behavior)

/max

As you said, doing this for all the classes (which you hate), is probably the most intutive way, especially if you are trying to do something throuh prototypeing.

The best would be if you could add code to the classes generated by hibernate and if you try to reverse engineer again it would leave the code you have added to the class alone.

The tools would then have to check if there already is a class with the same name in existence as it is about to generate, and if so only add methods/variables that doesn't already exist.

This is especially important if you are going to implement interfaces, then you probably would want access to the methods generated by Hibernate, which you won't be able to if Hibernate is just extending a base class.

I don't know how easy this is to implement but it would make the whole business completely intuitive and you wouldn't end up haveing 100+ or 200 classes for 100 tables, you would have 100 classes and thats it.

Any thoughts about this idea?

That should be possible (to a certain degree) by using something like JMerge, but JMerge is dependent on a full eclipse runtime which is pretty bad.

implementing the same functionallity would be a tremendous effort with alot of work for something that is most likely to not work in all scenarios.