ofbiz upgrade doc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

ofbiz upgrade doc

hans_bakker
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


Reply | Threaded
Open this post in threaded view
|

Re: ofbiz upgrade doc

Bilgin Ibryam
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
Reply | Threaded
Open this post in threaded view
|

Re: ofbiz upgrade doc

hans_bakker
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

Reply | Threaded
Open this post in threaded view
|

Re: ofbiz upgrade doc

Jacques Le Roux
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
>
Reply | Threaded
Open this post in threaded view
|

Re: ofbiz upgrade doc

Bilgin Ibryam
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
> >

Reply | Threaded
Open this post in threaded view
|

Re: ofbiz upgrade doc

David E Jones
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
>>
Reply | Threaded
Open this post in threaded view
|

Re: ofbiz upgrade doc

David E Jones
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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ofbiz upgrade doc

Jacques Le Roux
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
>>
>>
>