Posted by
cjhowe on
Aug 27, 2006; 10:02pm
URL: http://ofbiz.116.s1.nabble.com/Backup-and-Upgrade-automation-tp170647p170650.html
Just to clarify on my (4) on the list old entities
mean the entities that are being changed and then
droped from the database, not the entire database.
Usually these will have the name that will be desired
in the continuing database which is why we would want
to copy them to a tempTable.
Obviously there could be an exception to this, but I
would think that almost all data model improvements
would be adding something new and therefore dummy
values would take care of FK issues or the upgrade
would be making the data model more generic, which
would be refactoring of the FK and not cause an issue
there.
But your points do bring up that what I'm doing is a
bit of a hack instead of a true upgrade approach. I
will need to think about this a bit more.
--- BJ Freeman <
[hidden email]> wrote:
> sorry for the late response. Dealing with a
> electrical fire, in
> MotorCoarch, that happen on the 13th. Still not
> real-time, but can
> upload/download messages once daily, now. Should be
> back real-time in a
> week or so.
>
> I am approaching this more from the Entity level.
> 1) export all entities to xml.
>
> 2) toDo-- entity comparator that creates a new xml
> that is used to
> convert the entities data. NOte: for big changes
> like from 2.0 to
> current, it would take some hand coding. but once
> done, it could be in
> the Jira for other to use.
>
> 3- todo-- build a entity tree of what has to be
> imported first, from the
> entity defs in the upgrade.
> 4) todo-- import data by reading the Xml as a
> reader, in stead of Dom.
> this would read the old entity data, re-arrange the
> data to the new
> entity model using the xml generated in #2. This
> allows large xml files
> without using up and/or running out of memory.
>
> the reader would read a element at a time and submit
> it for import.
>
> Chris Howe sent the following on 8/14/2006 1:24 AM:
> > I was brainstorming what would be necessary to
> create
> > an Upgrade service in OFBiz for improvements in
> OFBiz
> > that break backwards compatibility.
> >
> > the requirements that I've come up with are the
> > following
> > 1) Backup the database (an upgrade script may
> break or
> > corrupt the database)
> > 2)Check the upgrades that are necessary to run the
> > version (svn) that is trying to run
> > 3)compare to list of upgrades that have already
> been
> > done
> > 4)Copy the old entities to tempTables
> > 5)Create the new tables necessary for the upgrade
> > 6)Run a script to process the data into it's new
> > structure
> > 7)Drop the tempTables
> > 8)enter the upgrade script name into the list of
> > upgrades that have been done
> >
> > Am I missing anything? Anyone else interested in
> > something like this?
> >
>
>