I created a first version of a OFBiz system upgrade document.
any comments welcome..... http://docs.ofbiz.org/display/OFBTECH/Upgrading+OFBiz+from+earlier +revisions |
What should go to this page?
Any data model change or only changes which need additional activities? In r688993 I added facilityId field to OrderItemShipGroup, but this change doesn't require any additions tasks. Should I add this change to the upgrade doc? Bilgin |
If the upgrade does not need any other extra activities then a simple
'svn up', then it is not required to add it too the list..... to make this document useful the following activities would be nice to list: 1. A re-load of seed data. 2. A file change which need additional unload/reload/convert activities 3. Any tables which can be deleted(dropped) because they are not used anymore. 4. Any other required activity to keep your production site operational On Wed, 2008-08-27 at 02:12 -0700, Bilgin Ibryam wrote: > What should go to this page? > Any data model change or only changes which need additional activities? > > In r688993 I added facilityId field to OrderItemShipGroup, but this change > doesn't require any additions tasks. Should I add this change to the upgrade > doc? > > Bilgin |
Administrator
|
It was a misinterpretation on my side, I thought any change should go there. Then I asked Bilgin to update.
My domineering tendency was back on this ;o) Sorry for that Jacques PS : though maybe having a trace of all changes could be easier than sometimes poking around :p From: "Hans Bakker" <[hidden email]> > If the upgrade does not need any other extra activities then a simple > 'svn up', then it is not required to add it too the list..... > > to make this document useful the following activities would be nice to > list: > > 1. A re-load of seed data. > 2. A file change which need additional unload/reload/convert activities > 3. Any tables which can be deleted(dropped) because they are not used > anymore. > 4. Any other required activity to keep your production site operational > > > On Wed, 2008-08-27 at 02:12 -0700, Bilgin Ibryam wrote: >> What should go to this page? >> Any data model change or only changes which need additional activities? >> >> In r688993 I added facilityId field to OrderItemShipGroup, but this change >> doesn't require any additions tasks. Should I add this change to the upgrade >> doc? >> >> Bilgin > |
On Wed, 2008-08-27 at 13:41 +0200, Jacques Le Roux wrote:
> It was a misinterpretation on my side, I thought any change should go there. Then I asked Bilgin to update. > My domineering tendency was back on this ;o) Sorry for that > No problem Jacques. Now I know that some changes should go there, but not from this commit :) > Jacques > PS : though maybe having a trace of all changes could be easier than sometimes poking around :p > > From: "Hans Bakker" <[hidden email]> > > If the upgrade does not need any other extra activities then a simple > > 'svn up', then it is not required to add it too the list..... > > Hans, thanks for the clarification. > > to make this document useful the following activities would be nice to > > list: > > > > 1. A re-load of seed data. > > 2. A file change which need additional unload/reload/convert activities > > 3. Any tables which can be deleted(dropped) because they are not used > > anymore. > > 4. Any other required activity to keep your production site operational > > > > > > On Wed, 2008-08-27 at 02:12 -0700, Bilgin Ibryam wrote: > >> What should go to this page? > >> Any data model change or only changes which need additional activities? > >> > >> In r688993 I added facilityId field to OrderItemShipGroup, but this change > >> doesn't require any additions tasks. Should I add this change to the upgrade > >> doc? > >> > >> Bilgin > > |
In reply to this post by Jacques Le Roux
This document is a great thing to maintain. To make it useful we don't want to include all changes, just the ones (as Hans wrote) that will require some data updates, and most especially the ones that involve non-backward-compataible data updates between two revisions. A PK change is definitely something that needs an upgrade path, and having documentation about how to run the upgrade service is a great idea. -David Jacques Le Roux wrote: > It was a misinterpretation on my side, I thought any change should go > there. Then I asked Bilgin to update. > My domineering tendency was back on this ;o) Sorry for that > > Jacques > PS : though maybe having a trace of all changes could be easier than > sometimes poking around :p > > From: "Hans Bakker" <[hidden email]> >> If the upgrade does not need any other extra activities then a simple >> 'svn up', then it is not required to add it too the list..... >> >> to make this document useful the following activities would be nice to >> list: >> >> 1. A re-load of seed data. >> 2. A file change which need additional unload/reload/convert activities >> 3. Any tables which can be deleted(dropped) because they are not used >> anymore. >> 4. Any other required activity to keep your production site operational >> >> >> On Wed, 2008-08-27 at 02:12 -0700, Bilgin Ibryam wrote: >>> What should go to this page? >>> Any data model change or only changes which need additional activities? >>> >>> In r688993 I added facilityId field to OrderItemShipGroup, but this >>> change >>> doesn't require any additions tasks. Should I add this change to the >>> upgrade >>> doc? >>> >>> Bilgin >> |
In reply to this post by hans_bakker
We definitely need to discuss this more... The main thing to consider when updating is entities with primary key changes, which should ALWAYS be done by deprecating the current entity and creating a new one, and creating a service to move the data from the old entity to the new one. There is really no excuse for not doing so, and while I've reminded people about it a few times I'm tempted to start reverting commits if people don't do this. Yes, it's that important. Saying that someone should do this manually through an export and import is a bad idea and a real PITA, even with separate old and new entities. As for seed data: the way "seed data" is defined and used means that it should ALWAYS be reloaded when updating an existing system. The pattern and how and such is pretty well explained in the ofbiz/build.xml file. Also, there are lots of things that people can do when updating, but don't really have to. Removing unused tables is a good example of this. Usually server capacity is way cheaper than human time. -David Hans Bakker wrote: > I created a first version of a OFBiz system upgrade document. > any comments welcome..... > > http://docs.ofbiz.org/display/OFBTECH/Upgrading+OFBiz+from+earlier > +revisions > > |
Administrator
|
From: "David E. Jones" <[hidden email]>
> > We definitely need to discuss this more... > > The main thing to consider when updating is entities with primary key changes, which should ALWAYS be done by > deprecating the current entity and creating a new one, and creating a service to move the data from the old entity to > the new one. There is really no excuse for not doing so, and while I've reminded people about it a few times I'm tempted > to start reverting commits if people don't do this. Yes, it's that important. Saying that someone should do this > manually through an export and import is a bad idea and a real PITA, even with separate old and new entities. +1 > As for seed data: the way "seed data" is defined and used means that it should ALWAYS be reloaded when updating an > existing system. The pattern and how and such is pretty well explained in the ofbiz/build.xml file. +1 > Also, there are lots of things that people can do when updating, but don't really have to. Removing unused tables is a > good example of this. Usually server capacity is way cheaper than human time. +1 Ready for discussion :o) Jacques > -David > > > > Hans Bakker wrote: >> I created a first version of a OFBiz system upgrade document. >> any comments welcome..... >> >> http://docs.ofbiz.org/display/OFBTECH/Upgrading+OFBiz+from+earlier >> +revisions >> >> > |
Free forum by Nabble | Edit this page |