squareFootage with decimals

[Jacques Le Roux]

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

[Scott Gray-2]

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
>

[Adrian Crum]

Good idea Scott! Taking it one step further, how about supporting volume
too? A facility might be a storage tank.

-Adrian

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
>>
>

[David E. Jones-2]

A storage tank might be better modeled as an asset that is located in a facility rather than being a facility itself.

BTW, we already have a UOM field to go along with the "squareFootage" field (which is unfortunate that it was done that way, but it's been there for a while now). This isn't a change in primary key or anything that requires significant migration, and in fact is just expanding the field size (specifically the decimal size of the numeric field). Most existing databases won't have to do any migration at all unless they want to start storing decimal values instead of just integer values in this field.

-David


On Mar 30, 2010, at 9:28 AM, Adrian Crum wrote:

> Good idea Scott! Taking it one step further, how about supporting volume too? A facility might be a storage tank.
>
> -Adrian
>
> 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

[Adrian Crum]

According to the Data Model Resource Book, a FACILITY entity stores the
attributes or relationships associated with a physical structure.
Facility types include warehouse, plant, building, room, office.

The type of storage tank I was referring to is one you would see in a
tank farm - it could be as large as a multi-story building. From my
perspective, it is a facility, but it could also be a fixed asset (just
like any other facility).

-Adrian

David E Jones wrote:

> A storage tank might be better modeled as an asset that is located in a facility rather than being a facility itself.
>
> BTW, we already have a UOM field to go along with the "squareFootage" field (which is unfortunate that it was done that way, but it's been there for a while now). This isn't a change in primary key or anything that requires significant migration, and in fact is just expanding the field size (specifically the decimal size of the numeric field). Most existing databases won't have to do any migration at all unless they want to start storing decimal values instead of just integer values in this field.
>
> -David
>
>
> On Mar 30, 2010, at 9:28 AM, Adrian Crum wrote:
>
>> Good idea Scott! Taking it one step further, how about supporting volume too? A facility might be a storage tank.
>>
>> -Adrian
>>
>> 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
>
>

[Jacques Le Roux]

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

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> A storage tank might be better modeled as an asset that is located in a facility rather than being a facility itself.
>
> BTW, we already have a UOM field to go along with the "squareFootage" field (which is unfortunate that it was done that way, but
> it's been there for a while now). This isn't a change in primary key or anything that requires significant migration, and in fact
> is just expanding the field size (specifically the decimal size of the numeric field). Most existing databases won't have to do
> any migration at all unless they want to start storing decimal values instead of just integer values in this field.

You think about defaultDimensionUomId?

Jacques

> -David
>
>
> On Mar 30, 2010, at 9:28 AM, Adrian Crum wrote:
>
>> Good idea Scott! Taking it one step further, how about supporting volume too? A facility might be a storage tank.
>>
>> -Adrian
>>
>> 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
>

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
> A storage tank might be better modeled as an asset that is located in a facility rather than being a facility itself.
>
> BTW, we already have a UOM field to go along with the "squareFootage" field (which is unfortunate that it was done that way, but
> it's been there for a while now).

You think about defaultDimensionUomId?

Jacques

>This isn't a change in primary key or anything that requires significant migration, and in fact is just expanding the field size
>(specifically the decimal size of the numeric field). Most existing databases won't have to do any migration at all unless they
>want to start storing decimal values instead of just integer values in this field.
>
> -David
>
>
> On Mar 30, 2010, at 9:28 AM, Adrian Crum wrote:
>
>> Good idea Scott! Taking it one step further, how about supporting volume too? A facility might be a storage tank.
>>
>> -Adrian
>>
>> 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
>

[Scott Gray-2]

Thanks David, I didn't look at the entity in question before commenting, if there is a uom already then Jacques proposal sounds fine to me (aside from the unfortunate name of the existing value field).

Regards
Scott

On 30/03/2010, at 9:37 AM, David E Jones wrote:

>
> A storage tank might be better modeled as an asset that is located in a facility rather than being a facility itself.
>
> BTW, we already have a UOM field to go along with the "squareFootage" field (which is unfortunate that it was done that way, but it's been there for a while now). This isn't a change in primary key or anything that requires significant migration, and in fact is just expanding the field size (specifically the decimal size of the numeric field). Most existing databases won't have to do any migration at all unless they want to start storing decimal values instead of just integer values in this field.
>
> -David
>
>
> On Mar 30, 2010, at 9:28 AM, Adrian Crum wrote:
>
>> Good idea Scott! Taking it one step further, how about supporting volume too? A facility might be a storage tank.
>>
>> -Adrian
>>
>> 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
>

[Scott Gray-2]

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
>
>

[David E. Jones-2]

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
>>
>>
>

[Jacques Le Roux]

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

[Jacques Le Roux]

Done at r929503, see also
http://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration

Jacques

From: "Jacques Le Roux" <[hidden email]>

> 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
>

[Jacopo Cappellato-4]

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" <[hidden email]>
>> 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
>>
>

[Jacques Le Roux]

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" <[hidden email]>

> 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" <[hidden email]>
>>> 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
>>>
>>
>
>

[Scott Gray-2]

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" <[hidden email]>
>> 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" <[hidden email]>
>>>> 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
>>>>
>>>
>>
>
>

[Jacques Le Roux]

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" <[hidden email]>
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" <[hidden email]>
>> 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" <[hidden email]>
>>>> 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
>>>>
>>>
>>
>
>

[Scott Gray-2]

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" <[hidden email]>
> 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" <[hidden email]>
>>> 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" <[hidden email]>
>>>>> 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
>>>>>
>>>>
>>>
>>
>>
>
>
>

[David E. Jones-2]

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" <[hidden email]>
>> 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" <[hidden email]>
>>>> 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
>>>>
>>>
>>
>
>

[Jacques Le Roux]

The only drawback I see with this manner I used, is that there is no easy history because no old_entity. But do we really need that?
Moreover, as you said, in this peculiar very simple case.

As ever, I tried KISS

Jacques

From: "Scott Gray" <[hidden email]>
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" <[hidden email]>
> 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" <[hidden email]>
>>> 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" <[hidden email]>
>>>>> 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
>>>>>
>>>>
>>>
>>
>>
>
>
>