Re: best practice for handling database schema changes

From: Aristedes Maniatis (ar..sh.com.au)
Date: Sun Dec 03 2006 - 17:30:03 EST

  • Next message: Malcolm Edgar: "Re: best practice for handling database schema changes"

    Interesting article. We implemented something similar, but without
    hard coding the SQL to update the schema into Java. Instead we have a
    folder full of files named 1.sql, 2.sql, etc. Each one contains the
    SQL required to update the database schema. Every time the server
    application runs it reads a special table in the database with one
    column and one record. That value is the 'schema version' from the
    last launch of the application. If this number is lower that the
    largest xx.sql file in the folder, then that sql file is executed and
    the version updated.

    We do all this before Cayenne is intialised in any way in our
    application.

    The only thing we haven't yet done is to write a junit test that
    validates the sum total of all our incremental updates is the same as
    a single SQL export from the current Cayenne model.

    Ari Maniatis

    On 02/12/2006, at 12:56 AM, Michael Gentry wrote:

    > I found this yesterday (although I haven't read it all yet):
    >
    > http://www.stepwise.com/Articles/2005/DBChanges/index.html
    >
    > Not sure if it'll be helpful, but it looks similar to some ideas I had
    > been pondering in the past.
    >
    > /dev/mrg
    >
    >
    > On 11/30/06, Michael Gentry <blacknex..mail.com> wrote:
    >> Currently you have to manually merge the changes just as you states.
    >> I should probably make an FAQ for this ...
    >>
    >> Thanks,
    >>
    >> /dev/mrg
    >>
    >>
    >> On 11/30/06, Tobias SCHOESSLER <Tobias.Schoessle..nvienna.org>
    >> wrote:
    >> >
    >> > hi,
    >> > What is the best practice for handling changes to the database
    >> schema once a
    >> > cayenne mapping was created?
    >> > We use the 'reverse engineer from database' feature to create an
    >> initial
    >> > mapping. But then we usually have to do manual changes like map
    >> some pks,
    >> > add flattened relationships, etc.
    >> > If then the database schema needs to be changed we usually have
    >> a problem as
    >> > 'reverse engineer from database' overwrites everything. There
    >> seems to be
    >> > the possibility to replace only selected tables but if you do
    >> this the
    >> > relationships are messed up. Is there a way to merge the
    >> changes with the
    >> > current model/mapping?
    >> >
    >> > thanks
    >> >
    >> > Tobias
    >>

    -------------------------->
    ish
    http://www.ish.com.au
    Level 1, 30 Wilson Street Newtown 2042 Australia
    phone +61 2 9550 5001 fax +61 2 9550 4001
    GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A





    This archive was generated by hypermail 2.0.0 : Sun Dec 03 2006 - 17:31:12 EST