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" <scott.g...@hotwaxmedia.com>
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
