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