I just thought it was how we do this sort of thing, I could certainly be wrong though. Using a new field does remove the need for any manual database modifications. To be honest though I don't really care because this seems pretty minor.
Regards Scott On 31/03/2010, at 9:22 AM, Jacques Le Roux wrote: > Do we really need to do that. It's transparent for users, they had a field > and possible values without decimals, now they have the > same field renamed with values with decimals (.000000 for legacy) > > Of course they need to udpate the UI. It's provided in the commit. But maybe > there is your concern? Anyway they will have to do it, > no? Do I miss something? Should rename not be used? > > Jacques > > From: "Scott Gray" <scott.g...@hotwaxmedia.com> > Shouldn't the existing field be renamed to oldSquareFootage and a new field > added for facilitySize? > > That's why I suggested (not demanded) a migration service to move the data > from the old field to the new. > > Regards > Scott > > On 31/03/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 >>>>> >>>> >>> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
