Hi Daniel
The problem reduces to how hibernate handles the entity model evolution.
I tell you what I do.
To be able to control evolution I like to get more control over the
hibernate configuration
So:
I remove the apt-plugin from the pom, so now I'm responsible for
(manually) maintaining hibernate.cfg.xml up to date.
I remove the custom "resources" declaration from the pom to go back to
standard maven.
I change hibernate.hbm2ddl.auto=update to
hibernate.hbm2ddl.auto=validate, this way hibernate won't screw up my
DB without me noticing it, so now I'm responsible for manually
upgrading my DB.
I generate the first schema ddl using the maven hibernate plugin.
I load the schema to my DB.
I use a dump utility to extract a dump of my empty DB.
And this is my starting point, let's called version 1
DEPLOY
After this, every change in the entity model is accompanied with the
corresponding sql script to handle the DB upgrade, migrate_v1_v2.sql
When the version 2 deployment time comes, I upgrade my DB using
migrate_v1_v2.sql, I create a new dump (version2.dump.sql) and I
start a new upgrade script: migrate_v2_v3.sql
I know this is not as "agile" as when you start with Trails, but is
the best way I know to handle this kind of situations. If anyone know
a different ways please let me know.
Trails will accommodate to the entities changes, of course that if you
rename an entity that has custom pages you will need to rename the
custom pages too, but in general it will work.
I hope it helps.
Saludos.
Alejandro.
--
Alejandro Scandroli -
http://weblog.amneris.es/Amneris: We build process-driven web applications.
http://www.amneris.esOn Wed, Apr 16, 2008 at 9:51 AM, Daniel Lauk <
daniel.lauk@...> wrote:
> Hello, list.
>
> I am doing evaluations of (web) app frameworks at work.
> I played around with trails and found it very interesting. But one
> certain point at issue is not answered in the docs.
>
> How does Trails cope with the natural evolution process every software
> goes through (e.g. an enum is refactored into an own class)?
> Is there a recommended strategy for coping with that?
>
> Of course, when there is no data yet (before the first release), it's
> trivial. Just wipe out the database and start from scratch. But what
> if there is data to be migrated?
>
> Kind regards,
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>
http://xircles.codehaus.org/manage_email>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email