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