Done at r929503, see also
http://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
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
