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
