[OFBiz] Users - OFBiz Demo Site

Adrian Crum adrianc at hlmksw.com
Tue Sep 21 11:10:37 EDT 2004


It would be cool if the upgrades are services that can "chain" to each 
other.

For instance, going from 3.0.0 to 3.2.0: the 3.2.0 code would call the 
Upgrade_From_3.1.0 service, the Upgrade_From_3.1.0 service would call 
the Upgrade_From_3.0.0 service, etc.

That way each upgrade service only needs to deal with upgrading the 
nearest previous version, and the upgrade will work no matter what 
version you upgrade from.

Maybe make Upgrade a component with standard interfaces and such.


Daniel L. Kunkel wrote:
> Dirk,
> 
> Would it also work to develop the upgrade system in parallel with 
> the code that requires an upgrade?  Then, the upgrade code could 
> get "frozen" at each release.
> 
> This way, if someone like Si wanted to upgrade to the latest, he 
> could just run the current upgrade code module or modules.  Later, 
> when others wanted to go from 3.0.0 to 3.2.0 for example, they'd 
> first run Upgrade_From_3.0.0, and then run Upgrade_From_3.1.0 
> etc.
> 
> The hardest part would seem to be making sure all the code 
> changes that required special processing were handled. Perhaps 
> that could be essentially taken care if when a programmer first 
> makes a change that would require an upgrade script, they also at 
> least put a note in the upgrade_from code stub.
> 
> Thanks
> 
> 
> 
> To:             	OFBiz Users / Usage <users at lists.ofbiz.org>
> Subject:        	Re: [OFBiz] Users - OFBiz Demo Site
> From:           	dirk.osterkamp at agrenon.com
> Date sent:      	Tue, 21 Sep 2004 09:54:27 +0200
> Send reply to:  	OFBiz Users / Usage <users at lists.ofbiz.org>
> 	<mailto:users-request at lists.ofbiz.org?subject=unsubscribe>
> 	<mailto:users-request at lists.ofbiz.org?subject=subscribe>
> 
>>david, others,
>>one additional point: From our experience with upgrade procedure and tools 
>>it is nessesary to have well defines release points from where you upgrade 
>>and to where you upgrade. Only with this one tool have a real chance to 
>>make a mostly automated upgrade. 
>>In the ofbiz case you have in addition the project specific changes of the 
>>"official" ofbiz source base.
>>So from my point of view, if someone try's to develop tools for upgrades 
>>we have define the release points to get the right deltas in this tools 
>>and to extend this "common" tools to the project specific use cases.
>>
>>Viele Gruesse
>>Best Regards
>>
>>Dirk Osterkamp
>>
>>Agrenon GmbH ,  a Subsidiary of Lynx Consulting AG
>>Johanniskirchplatz 6, D-33615 Bielefeld, Germany
>>Tel. +49 (521) 5247-0, Fax.+49 (521) 5247-250, Mobile +49(171)7437992
>>E-Mail: dirk.osterkamp at agrenon.com
>>
>>
>>
>>
>>
>>"David E. Jones" <jonesde at ofbiz.org>
>>Sent by: users-bounces at lists.ofbiz.org
>>20.09.2004 19:43
>>Please respond to OFBiz Users / Usage
>> 
>>        To:     OFBiz Users / Usage <users at lists.ofbiz.org>
>>        cc: 
>>        Subject:        Re: [OFBiz] Users - OFBiz Demo Site
>>
>>
>>
>>I stated that "it is ready for primetime"? Wow, where? I guess I should 
>>be more careful about what I write. OFBiz is 100% community driven and 
>>there is no organization that can say that OFBiz is "ready for 
>>primetime". At this point that is totally up to users or their service 
>>providers, and it will probably always be that way because OFBiz is an 
>>open source project, and not a services organization and any sort of 
>>guarantee implies a service.
>>
>>I guess that's the real problem too... Andy was right when he said that 
>>he and I really can't afford to maintain this sort of thing, ie upgrade 
>>code to go from version to version. We've talked about it a lot and we 
>>have developed various things to make upgrading easier, but there is 
>>not consistent set of tested processes and instructions to update from 
>>version to version.
>>
>>You are correct though, in a good enterprise suite there should ideally 
>>always be a "complete" upgrade procedure. Of course, ideally we would 
>>be charging $100,000 per CPU for nothing but a license to run OFBiz, so 
>>I guess there are some trade-offs...
>>
>>On that topic, Andy and I have talked about providing this a service 
>>for tested upgrade tools through our company (Undersun Consulting LLC), 
>>and a yearly subscription would probably cost around $5000. That is, of 
>>course, a rough number. If only a few people signed up we would still 
>>have to eat a lot of the cost to maintain this service, but at least 
>>that would help fund it...
>>
>>We have also talked about hosting code repositories for people and 
>>helping them to stay up-to-date with OFBiz releases. This would include 
>>upgrade and code merging assistance. The cost would probably be around 
>>$10k per year, plus a surcharge for larger development teams.
>>
>>Of course, these are still in the planning phase right now. We will be 
>>putting up a web site in the near future with more information on these 
>>offering, but if anyone is interested please do contact us...
>>
>>-David
>>
>>
>>On Sep 19, 2004, at 12:50 PM, bjfree at free-man.net wrote:
>>
>>
>>>in another email about the size of ofbiz you state that it is ready for
>>>primetime.
>>>Not saying it isn't, however we that have online system face the same 
>>>data
>>>upgrade problems you had with yours.
>>>it seems you missed a prime condition to find out if the upgrade 
>>>procedures
>>>you that have been noted on this list work and an estimate of what it 
>>>takes
>>>to do that.
>>>
>>>there should always be a "complete" upgrade procedure, beside blow 
>>>down and
>>>start over, in place that anyone can use.
>>>
>>>
>>>-----Original Message-----
>>>From:
>>>Sent: None
>>>Subject:
>>>
>>>
>>>
>>>To all who care:
>>>
>>>I re-built the OFBiz Demo server yesterday, and there is good news and
>>>bad news about this...
>>>
>>>Good news:
>>>- it is now running the latest OFBiz code from SVN (as of yesterday)
>>>- it is running on the new Apache Derby database, which used to be
>>>Cloudscape; this shouldn't be considered stable yet, but we are now
>>>testing it since it is a great option for very easy small deployments;
>>>it is a Java database, but unlike HSQLDB (which is an in-memory
>>>database) it uses a real file structure and therefore can handle large
>>>databases, but it is still easy to deploy and can be run in an embedded
>>>mode in the same JVM, or as a separate database if you grow to multiple
>>>servers
>>>
>>>Bad news:
>>>- all of the old data is gone, I didn't consider it to be worth the
>>>time to migrate it for the changes from the last 3 months
>>>
>>>Feel free to check it out if you want to play. It's on a pretty decent
>>>server, well pretty decent for a sub-$1000 server with mirrored disks
>>>and such, but only a 1Mbit connection, but still feel free to slam it
>>>with a load test client or something if you want to see how the thing
>>>is scaling. Speaking of which, evidently there is an issue with the
>>>cache stuff right now that is slowing down certain things because the
>>>cache is effectively not being used, so don't be discouraged if it
>>>isn't performing as you would hope right now...
>>>
>>>-David
>>>
>>>_______________________________________________
>>>Users mailing list
>>>Users at lists.ofbiz.org
>>>http://lists.ofbiz.org/mailman/listinfo/users
>>
>> 
>>_______________________________________________
>>Users mailing list
>>Users at lists.ofbiz.org
>>http://lists.ofbiz.org/mailman/listinfo/users
>>
> 
> 
> 
> Daniel
> 
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-
> Have a GREAT Day!
> 
> Daniel Kunkel		DanielKunkel at BioWaves.com
> BioWaves, LLC
> 14150 NE 20th Street, Suite 121
> Bellevue, WA  98007
> 800-734-3588    425-895-0050
> http://www.BioWaves.com    http://www.IonToothbrush.com
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-
> 
> 
>  
> _______________________________________________
> Users mailing list
> Users at lists.ofbiz.org
> http://lists.ofbiz.org/mailman/listinfo/users
> 


More information about the Users mailing list