[odb-users] db scheme and data migration scheme

Lidia Kalinovsky lidia at lemur-soft.com
Sat Jan 4 10:19:56 EST 2014


Thanks a lot for informative and quick response.


On Fri, Jan 3, 2014 at 10:26 AM, Boris Kolpackov <boris at codesynthesis.com>wrote:

> Hi Lidia,
>
> Lidia Kalinovsky <lidia at lemur-soft.com> writes:
>
> > Is it possible to have automatic db scheme and data migration to both
> > directions - from old to new and new to old versions?
>
> No, ODB does not support this. Also, generally speaking, database
> schema evolution is fairly complex already so if you can, I would
> suggest that you try to keep it as simple as possible. Trying to
> support migrations in both directions is sure to complicate your
> life significantly.
>
>
> > We have one server that sends database with newest version. We have
> clients
> > with different software ( and therefore db ) versions. Server should be
> > able to convert newest version to some old one. As well, client would be
> > able to migrate db to newest one in case new software has been installed.
>
> One mechanism that may help you implement this is the soft model changes.
> The general idea is outlined in this paragraph from the manual:
>
> "The most complex approach is working with multiple versions of the
> database
>  without performing any migrations, schema or data. ODB does provide
> support
>  for implementing this approach (Section 13.4, "Soft Object Model
> Changes"),
>  however we will not cover it any further in this chapter. Generally, this
>  will require embedding knowledge about each version into the core
> application
>  logic which makes it hard to maintain for any non-trivial object model."
>
> In your case, both your server and client will not perform any migrations
> but rather be capable of working with any version of the database (or
> some range of versions). You won't be able to send a new database to
> an old client, though.
>
>
> > ( to implement this I thought use info from .xml generated by odb
> compiler
> > and make reverse changes myself. But if there is another better option, I
> > would appreciate any advice ).
>
> Yes, theoretically, you could read the changelog and try to produce
> a set of SQL files that do the reverse. Unless you only use a limited
> number of changes (e.g., only adding/removing columns), then this will
> involve some work. Also keep in mind that SQLite (which is what I believe
> you are using) has a very limited support for DDL. In particular it is
> not possible to drop columns in SQLite.
>
> Boris
>



-- 
Software integration and outsourcing services,
Lemur-Soft, Giv'at Nili
Israel, 37825
Phone : (+972) 545748325
Fax : (+972) 775345383
Email : lidia at lemur-soft.com
Web: www.lemur-soft.com


More information about the odb-users mailing list