Re: squareFootage with decimals

[Jacques Le Roux <ja...@les7arts.com>]

From: "Wickersheimer Jeremy" <jw...@opensourcestrategies.com>
> Think about what happens to users who don't know about the simple migration SQL script.
> They end up with two fields in the DB facilitySize and squareFootage, this is done
> automatically by the framework.
> Then your script won't work and you cannot do anything as some users will end up with data
> in both fields.
> The only way to handle this properly is to do like Scott suggests, deprecate the old field,
> and have a simple migration service copying data no?

Yes, if someone has used the squareFootage field outside of its use OOTB, this problem may arise (The squareFootage field does not 
exist any longer in the code OOTB).
I will do it tomorrow.

Jacques

>
> -- 
> Wickersheimer Jeremy
> On Wednesday 31 March 2010 23:38:34 Scott Gray wrote:
>> 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" <sc...@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" <ja...@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" <ja...@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
>