Hello, Alejandro.
Thanks for your fast response.
Your approach makes sense to me. Just to make sure, I got it right,
I'll sum it up using my own words. You recommend to
* use the full Trails stack, including hibernate, to create a first version.
* exclude hibernate from Trails' stack and configure it properly
* manually keep the hibernate xml and the migration sql in sync
with the remaining Trails app
Did I get that right?
Regards,
Daniel
2008/4/16, Alejandro Scandroli <
alejandroscandroli@...>:
> 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.es>
>
>
>
>
>
> On 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>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email