Actually I did not read enough at
http://cwiki.apache.org/confluence/display/OFBTECH/General+Entity+Overview#GeneralEntityOverview-DeprecatedEntities
It's now done the right way (at least I hope so) at r929912
Jacques
From: "Jacques Le Roux" <[email protected]>
Ha, I thought it would work in any DBMS, though the syntax may vary.
I did not find a clear answer about that through Google. And as I saw a rename
used in the migration tip for R767278, I thought it
was OK to use without dropping.
So I will re-re-do it the traditionnal way :/
Jacques
From: "David E Jones" <[email protected]>
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" <[email protected]>
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" <[email protected]>
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
