Jacopo,
Actually yes, it takes some time to follow the deprecated pattern. But it's not
so huge if you have well understood what to do. It's
well documented but you have to get through one time to understand it well. So
I'm not sure we should give up. Notably on
deprecating fields or/and Entities. The only piece we could possibly neglict is
IMO the service part (it's the longer part). If we
provide a simple SQL script I think it's enough for people to at least infer
what to do on their own DB(s).
Jacques
From: "Jacopo Cappellato" <jacopo.cappell...@hotwaxmedia.com>
In rev. 930182 I have created also the upgrade script to migrate data from old
to new fields.
By the way, are we sure it is a good idea for the project to enforce these
rules about backward compatibility?
It seems to me that the development in OFBiz is becoming more difficult every
day and this is self evident from this small
improvement that has caused a rather long thread.
We are worried about causing harm to an hypothetical group of end users that,
we suppose, don't follow the dev lists, don't have
any internal IT team that can help them in the migration, don't have a budget
for the upgrade, don't understand about the risks of
upgrading a production ERP instance and just want to do this by blindly
pressing a button.
We are sacrificing the very limited time of our brave committers against this
"myth". In my opinion we just went too far, the risk
is that we go into the mud and slow down because this plan is not compatible
with the resources of our community. There is also
the risk that we are trying to fix a problem that is not there: chances are
that the silent end users have very good budgets, very
skilled IT teams that have greatly customized their OFBiz and simple just want
to take care of the critical system upgrade on
their own.
So I would like to propose a change in our 'policies' to switch from "backward
compatibility" to "backward awareness" based on the
following principles:
1) committers are encouraged to improve existing code, clean it up, improve
data model etc... even if the changes could cause some
problems during upgrade; OFBiz has to grow efficiently in the best way possible
considering the limited group of contributors
2) however, since we know that there are companies that are willing to stay up
to date with the OFBiz growth but don't want to
invest resources in the upgrade process or staying in synch with the community,
then we will do our best to simplify the upgrade
path; this means that, if time permits, committers are encouraged to apply the
deprecation patterns (for bigger and more critical
changes), or at least write some notes to warn people about the change occurred
that could impact an upgrade etc...
3) we should also send the message out (from our site, mailing lists etc) to
the silent end users that, if they are in the process
of upgrading from an older release they should at least mention this in the
user list: in this way the community will have a
chance to provide suggestions, warn about potential issues, etc and most of all
this will help the community of end users to test
together and cooperate on upgrade scripts
What do you think?
Jacopo
On Apr 1, 2010, at 1:08 PM, Jacques Le Roux wrote:
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" <jacques.le.r...@les7arts.com>
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" <d...@me.com>
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" <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
