In rev. 930182 I have created also the upgrade script to migrate data from old to new fields.
By the way, are we sure it is a good idea for the project to enforce these rules about backward compatibility? It seems to me that the development in OFBiz is becoming more difficult every day and this is self evident from this small improvement that has caused a rather long thread. We are worried about causing harm to an hypothetical group of end users that, we suppose, don't follow the dev lists, don't have any internal IT team that can help them in the migration, don't have a budget for the upgrade, don't understand about the risks of upgrading a production ERP instance and just want to do this by blindly pressing a button. We are sacrificing the very limited time of our brave committers against this "myth". In my opinion we just went too far, the risk is that we go into the mud and slow down because this plan is not compatible with the resources of our community. There is also the risk that we are trying to fix a problem that is not there: chances are that the silent end users have very good budgets, very skilled IT teams that have greatly customized their OFBiz and simple just want to take care of the critical system upgrade on their own. So I would like to propose a change in our 'policies' to switch from "backward compatibility" to "backward awareness" based on the following principles: 1) committers are encouraged to improve existing code, clean it up, improve data model etc... even if the changes could cause some problems during upgrade; OFBiz has to grow efficiently in the best way possible considering the limited group of contributors 2) however, since we know that there are companies that are willing to stay up to date with the OFBiz growth but don't want to invest resources in the upgrade process or staying in synch with the community, then we will do our best to simplify the upgrade path; this means that, if time permits, committers are encouraged to apply the deprecation patterns (for bigger and more critical changes), or at least write some notes to warn people about the change occurred that could impact an upgrade etc... 3) we should also send the message out (from our site, mailing lists etc) to the silent end users that, if they are in the process of upgrading from an older release they should at least mention this in the user list: in this way the community will have a chance to provide suggestions, warn about potential issues, etc and most of all this will help the community of end users to test together and cooperate on upgrade scripts What do you think? Jacopo On Apr 1, 2010, at 1:08 PM, Jacques Le Roux wrote: > Actually I did not read enough at > http://cwiki.apache.org/confluence/display/OFBTECH/General+Entity+Overview#GeneralEntityOverview-DeprecatedEntities > > It's now done the right way (at least I hope so) at r929912 > > Jacques > > From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> >> Ha, I thought it would work in any DBMS, though the syntax may vary. >> I did not find a clear answer about that through Google. And as I saw a >> rename used in the migration tip for R767278, I thought it >> was OK to use without dropping. >> >> So I will re-re-do it the traditionnal way :/ >> >> Jacques >> >> From: "David E Jones" <d...@me.com> >>> If you rename the column you would have to do an alter to change the data >>> type on that existing column with data in it, which may >>> not work in all databases. >>> >>> -David >>> >>> >>> On Mar 31, 2010, at 9:05 AM, Jacques Le Roux wrote: >>> >>>> Hi Jacopo, >>>> >>>> Did you try the migration tip? >>>> I found >>>> ALTER TABLE facility RENAME COLUMN square_footage TO facility_size; >>>> to work on my postgres intances >>>> >>>> Jacques >>>> >>>> From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com> >>>>> Hi Jacques, >>>>> >>>>> On Mar 31, 2010, at 2:39 PM, Jacques Le Roux wrote: >>>>> >>>>>> Done at r929503, see also >>>>>> http://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration >>>>>> >>>>> >>>>> after the upgrade OFBiz will automatically add the two new fields and >>>>> will leave the old one (containing data) in place. >>>>> For this reason the data migration instructions should not suggest to >>>>> manually alter that field but instead they should suggest >>>>> to: >>>>> 1) copy data ("update...") from square_footage to facility_size, setting >>>>> the default value of "square feet" in the >>>>> facilitySizeUomId field >>>>> 2) drop the square_footage field >>>>> >>>>> Jacopo >>>>> >>>>>> Jacques >>>>>> >>>>>> From: "Jacques Le Roux" <jacques.le.r...@les7arts.com> >>>>>>> OK, I will revert now and introduces the 2 fields as suggested tomorrow >>>>>>> (in case somebody has another idea) >>>>>>> Jacques >>>>>>> David E Jones wrote: >>>>>>>> I just checked and I messed up... there isn't a UOM field that goes >>>>>>>> with the squareFootage field. >>>>>>>> That being the case, I propose we add a couple of generic fields >>>>>>>> (facilitySize as a float, facilitySizeUomId) and deprecate >>>>>>>> the >>>>>>>> squareFootage field. BTW, however it's done with an explicit UOM it's >>>>>>>> possible to specify a volume as well as an area should >>>>>>>> one desire (though I >>>>>>>> wouldn't recommend it). -David >>>>>>>> On Mar 30, 2010, at 10:01 AM, Scott Gray wrote: >>>>>>>>> As per David's email the uom field is already there, the migration >>>>>>>>> service was just a suggestion and because the uom is >>>>>>>>> already >>>>>>>>> there it isn't useful anyway. Regards >>>>>>>>> Scott >>>>>>>>> On 30/03/2010, at 9:49 AM, Jacques Le Roux wrote: >>>>>>>>>> Why not simply add a new field for the UomId ? Do we really need a >>>>>>>>>> service to migrate data? >>>>>>>>>> It seems to me that previous integers will be simply represented >>>>>>>>>> with 0 decimals. At least I tested on Postgres without any >>>>>>>>>> issues at all. I tried to keep things simple, to me and to persons >>>>>>>>>> who will need to update: no deprecation, just a change. >>>>>>>>>> Though I only tested on Postgres and there are maybe syntactic SQL >>>>>>>>>> variations... >>>>>>>>>> Jacques >>>>>>>>>> Scott Gray wrote: >>>>>>>>>>> If we want it to be a bit more generic we should probably add two >>>>>>>>>>> new fields: floorArea and floorAreaUomId and then >>>>>>>>>>> deprecate >>>>>>>>>>> squareFootage, perhaps with a migration service to populate the new >>>>>>>>>>> fields with the data from the old. >>>>>>>>>>> Regards >>>>>>>>>>> Scott >>>>>>>>>>> HotWax Media >>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>> On 30/03/2010, at 7:22 AM, Jacques Le Roux wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> I'd like to allow Facility.squareFootage to support decimals. In >>>>>>>>>>>> order to do that, I need to change the type of the >>>>>>>>>>>> squareFootage field from numeric to fixed-point. I can't see any >>>>>>>>>>>> issues doing that OOTB. But in case this would be a >>>>>>>>>>>> problem >>>>>>>>>>>> for someone I prefer to warn. >>>>>>>>>>>> Jacques >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > >
