squareFootage with decimals
Locked
12
12
Re: squareFootage with decimals
 
|
Think about what happens to users who don't know about the simple migration SQL script.
They end up with two fields in the DB facilitySize and squareFootage, this is done automatically by the framework. Then your script won't work and you cannot do anything as some users will end up with data in both fields. The only way to handle this properly is to do like Scott suggests, deprecate the old field, and have a simple migration service copying data no? -- Wickersheimer Jeremy On Wednesday 31 March 2010 23:38:34 Scott Gray wrote: > 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" <[hidden email]> > > 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" <[hidden email]> > >> > >>> 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" <[hidden email]> > >>>> > >>>>> 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 |
Re: squareFootage with decimals
Administrator
|
If rename does not work on every DBMS looks like it's the only way to go indeed.
It's a pity though, it was so simple :/ Someone knows a DBMS that does not handle rename nowadays? Jacques From: "Wickersheimer Jeremy" <[hidden email]> > Think about what happens to users who don't know about the simple migration SQL script. > They end up with two fields in the DB facilitySize and squareFootage, this is done > automatically by the framework. > Then your script won't work and you cannot do anything as some users will end up with data > in both fields. > > The only way to handle this properly is to do like Scott suggests, deprecate the old field, > and have a simple migration service copying data no? > > -- > Wickersheimer Jeremy > On Wednesday 31 March 2010 23:38:34 Scott Gray wrote: >> 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" <[hidden email]> >> > 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" <[hidden email]> >> >> >> >>> 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" <[hidden email]> >> >>>> >> >>>>> 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 > |
Re: squareFootage with decimals
|
Administrator
|
In reply to this post by David E. Jones-2
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" <[hidden email]> > 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" <[hidden email]> >>> 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" <[hidden email]> >>>>> 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 >>>>> >>>> >>> >> >> > |
Re: squareFootage with decimals
|
Administrator
|
In reply to this post by Jacques Le Roux
From: "Jacques Le Roux" <[hidden email]>
> If rename does not work on every DBMS looks like it's the only way to go indeed. > It's a pity though, it was so simple :/ > > Someone knows a DBMS that does not handle rename nowadays? Oops, the problem is with the field type change actually Jacques > Jacques > > From: "Wickersheimer Jeremy" <[hidden email]> >> Think about what happens to users who don't know about the simple migration SQL script. >> They end up with two fields in the DB facilitySize and squareFootage, this is done >> automatically by the framework. >> Then your script won't work and you cannot do anything as some users will end up with data >> in both fields. >> >> The only way to handle this properly is to do like Scott suggests, deprecate the old field, >> and have a simple migration service copying data no? >> >> -- >> Wickersheimer Jeremy >> On Wednesday 31 March 2010 23:38:34 Scott Gray wrote: >>> 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" <[hidden email]> >>> > 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" <[hidden email]> >>> >> >>> >>> 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" <[hidden email]> >>> >>>> >>> >>>>> 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 >> > |
Re: squareFootage with decimals
|
Administrator
|
In reply to this post by Wickersheimer Jeremy
From: "Wickersheimer Jeremy" <[hidden email]>
> Think about what happens to users who don't know about the simple migration SQL script. > They end up with two fields in the DB facilitySize and squareFootage, this is done > automatically by the framework. > Then your script won't work and you cannot do anything as some users will end up with data > in both fields. > > The only way to handle this properly is to do like Scott suggests, deprecate the old field, > and have a simple migration service copying data no? Yes, looks like it's still the better solution if we don't want to automate the process (could be for modern DBMS, but maybe even harder than a migration service) I will do that tomorrow... Jacques > -- > Wickersheimer Jeremy > On Wednesday 31 March 2010 23:38:34 Scott Gray wrote: >> 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" <[hidden email]> >> > 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" <[hidden email]> >> >> >> >>> 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" <[hidden email]> >> >>>> >> >>>>> 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 > |
Re: squareFootage with decimals
|
Administrator
|
In reply to this post by Wickersheimer Jeremy
From: "Wickersheimer Jeremy" <[hidden email]>
> Think about what happens to users who don't know about the simple migration SQL script. > They end up with two fields in the DB facilitySize and squareFootage, this is done > automatically by the framework. > Then your script won't work and you cannot do anything as some users will end up with data > in both fields. > The only way to handle this properly is to do like Scott suggests, deprecate the old field, > and have a simple migration service copying data no? Yes, if someone has used the squareFootage field outside of its use OOTB, this problem may arise (The squareFootage field does not exist any longer in the code OOTB). I will do it tomorrow. Jacques > > -- > Wickersheimer Jeremy > On Wednesday 31 March 2010 23:38:34 Scott Gray wrote: >> 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" <[hidden email]> >> > 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" <[hidden email]> >> >> >> >>> 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" <[hidden email]> >> >>>> >> >>>>> 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 > |
Re: squareFootage with decimals
|
Administrator
|
In reply to this post by Jacques Le Roux
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" <[hidden email]> > 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" <[hidden email]> >> 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" <[hidden email]> >>>> 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" <[hidden email]> >>>>>> 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 >>>>>> >>>>> >>>> >>> >>> >> > > |
Re: squareFootage with decimals
|
|
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" <[hidden email]> >> 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" <[hidden email]> >>> 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" <[hidden email]> >>>>> 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" <[hidden email]> >>>>>>> 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 >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > > |
Re: squareFootage with decimals
|
Administrator
|
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" <[hidden email]> > 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" <[hidden email]> >>> 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" <[hidden email]> >>>> 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" <[hidden email]> >>>>>> 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" <[hidden email]> >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > > |
Backward compatibility and software versus developers (was Re: squareFootage with decimals)
|
|
In reply to this post by Jacopo Cappellato-4
I've felt this same frustration Jacopo. OFBiz is a large project with a long history and the community has been mostly focused on making it easy for developers to get involved (ie inviting all sorts of contributions and the people with them in order to hopefully get more contributions). This has worked pretty well to attract developers who are willing to contribute certain things, mostly new features. What hasn't worked well is attracting contributions for documentation, testing/fixes/stability, backward compatibility, etc. IMO the key is that for a given change, like this data model change, there is no reason the same person has to take care of all of this stuff. The way a volunteer community like this is structured is that people need a motivation to contribute things, and that means that those who care about something should contribute to that. In other words, if you care about OFBiz supporting backward compatibility then you should contribute to backward compatibility efforts. If you care about stability, you should contribute to stability efforts. The problem is... not enough people care enough about these things, or at least not enough to do anything about it except complain and attack those who are contributing other things or other aspects of specific things. This is a break down in collaboration. On top of that we have a severe issue with collaboration on design. Part of this is that people have a hard time distinguishing between requirements and designs, so discussions about design go nowhere in a hurry. Maybe more important is that we just don't try to collaborate on requirements gathering and design very much, and if we did then we could get better at the problem above and after a while it wouldn't be an issue. The result is that the different parts of the project have very different design approaches and sometimes unresolved conflicted requirements. Sometimes this shows up as many ways of doing the same thing. Sometimes this shows up as hidden features that are not apparent when looking at the XML schemas or data model or the API (ie the external interface isn't designed well making the feature inaccessible to customizers and/or end-users). Most ASF project benefit from having a standardized spec to implement (ie the design has already been done outside the project), but OFBiz doesn't have that benefit and so whether we like it or not we are doing design, and unfortunately the design seems to be mostly by default (or accident, or implicit design) and arbitrary external requirements as opposed to explicit coordinated efforts and design before implementation. In short it seems like there are various people in the community who would like to see the focus of the project shift away from making things easy for developers and toward making things easy for end-users. I think that's a great approach, but the problem is how do we do it... what motivation can we leverage and how can we mobilize people with that motivation to make these happen? People can complain about how things "should be" all day long, but that's not going to change anything. If no one is motivated to do these things then the only result of complaints will be alienation and less complaints. The irony is that the community focus on attracting developers instead of attracting end-users has resulted in a social environment that discourages contributions and alienates developers. Is is just the people involved, or is there something fundamentally wrong with the whole approach? -David P.S. A good example of this dynamic (IMO) is the NUMMI car plant and the differences in corporate culture between Toyota and GM. GM focused on making workers happy and resulted in poor quality and unhappy workers. Toyota focused on making good cars and resulted in high quality and happier workers. This American Life did a great piece on this that is available here: http://www.thisamericanlife.org/radio-archives/episode/403/nummi I recommend this to everyone as there are some valuable lessons there that I believe are directly applicable to OFBiz and community-driven software, and even software development in general. On Apr 2, 2010, at 2:48 AM, Jacopo Cappellato wrote: > 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" <[hidden email]> >>> 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" <[hidden email]> >>>> 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" <[hidden email]> >>>>>> 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" <[hidden email]> >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> > |
Re: squareFootage with decimals
|
|
In reply to this post by Jacopo Cappellato-4
I have a friend who's favorite business saying is "start out where you want to end up". It is sort of a nonsense phrase but it says something similar to "a stitch in time saves none". If we are clear about what we are trying to build it will be much easier to put those fixes in now than to try to change course down the road.
In my mind, we are trying to do something revolutionary which is to bring the power of ERP down to the small to medium size business player. Its revolutionary because, if successful, it has the potential to change the dynamics of business and the structure of the world economy. If we are going to succeed in that task we are really forced to confront the reality of what those business owners need. That means providing business continuity even in the face of small budgets and a minimal IT staff. If we can make the "myth" of easy upgrades a reality then our software it going to be much more widely adopted. I'm not trying to brush the complexity of this under the rug. I agree with you whole-heartedly that seamless upgrade-in-place is probably a real pain for us to achieve. At the same time, it also has the possibility to reduce our overall workload. Adam and I personally have to oversee upgrading customer installations on a regular basis and those upgrades are typically time consuming and a little bit scary. If this problem was reduced to literally pushing a button it would free up time that could be spent on more productive tasks that actually improve the customer's business. My $0.02. ----- "Jacopo Cappellato" wrote: > 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 Ean Schuessler, CTO Brainfood.com [hidden email] - http://www.brainfood.com - 214-720-0700 x 315 |
|
|
In reply to this post by Jacques Le Roux
a quote i grew up with is
"if you are a genius you can take the most esoteric thought and have everbody understand it". That was in my teens know everything years. The other is there are three type of people when if comes to bringing something to market there are the dreamers that come up with the concept. there are the does that build the concept. the problem is that Dreamers are not pratical and can not tell the doers how to accomplish building it. the third person is the one that understands the dreamer and can make instructions the Does can use. What we need is more of the third kind. ========================= BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro> Ean Schuessler sent the following on 4/3/2010 9:59 AM: > I have a friend who's favorite business saying is "start out where you want to end up". It is sort of a nonsense phrase but it says something similar to "a stitch in time saves none". If we are clear about what we are trying to build it will be much easier to put those fixes in now than to try to change course down the road. > > In my mind, we are trying to do something revolutionary which is to bring the power of ERP down to the small to medium size business player. Its revolutionary because, if successful, it has the potential to change the dynamics of business and the structure of the world economy. If we are going to succeed in that task we are really forced to confront the reality of what those business owners need. That means providing business continuity even in the face of small budgets and a minimal IT staff. If we can make the "myth" of easy upgrades a reality then our software it going to be much more widely adopted. > > I'm not trying to brush the complexity of this under the rug. I agree with you whole-heartedly that seamless upgrade-in-place is probably a real pain for us to achieve. At the same time, it also has the possibility to reduce our overall workload. Adam and I personally have to oversee upgrading customer installations on a regular basis and those upgrades are typically time consuming and a little bit scary. If this problem was reduced to literally pushing a button it would free up time that could be spent on more productive tasks that actually improve the customer's business. > > My $0.02. > > ----- "Jacopo Cappellato" wrote: >> 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 |
Re: squareFootage with decimals
|
|
In reply to this post by Jacques Le Roux
Jacques Le Roux wrote:
> 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 Jacques, I agree with you on this proposal - the process should be easier for developers but also available for users willing to do the data migration. Bilgin |
Re: squareFootage with decimals
|
|
In reply to this post by Ean Schuessler
On Apr 3, 2010, at 6:59 PM, Ean Schuessler wrote: > I have a friend who's favorite business saying is "start out where you want to end up". It is sort of a nonsense phrase but it says something similar to "a stitch in time saves none". If we are clear about what we are trying to build it will be much easier to put those fixes in now than to try to change course down the road. > > In my mind, we are trying to do something revolutionary which is to bring the power of ERP down to the small to medium size business player. Its revolutionary because, if successful, it has the potential to change the dynamics of business and the structure of the world economy. If we are going to succeed in that task we are really forced to confront the reality of what those business owners need. That means providing business continuity even in the face of small budgets and a minimal IT staff. Agreed. But the main point that is often ignored is that we are doing this revolution with *minimal* resources: a limited group of active committers and a small group of service providers. The only way we can win is to understand our limits and be clever and study new (unconventional) ways of achieving our goals. This was done in the past of OFBiz, mostly thanks to David's vision (developer friendly community, push to use the trunk to maximize feedback and contributions etc...). > If we can make the "myth" of easy upgrades a reality then our software it going to be much more widely adopted. > > I'm not trying to brush the complexity of this under the rug. I agree with you whole-heartedly that seamless upgrade-in-place is probably a real pain for us to achieve. At the same time, it also has the possibility to reduce our overall workload. > Adam and I personally have to oversee upgrading customer installations on a regular basis and those upgrades are typically time consuming and a little bit scary. If this problem was reduced to literally pushing a button it would free up time that could be spent on more productive tasks that actually improve the customer's business. I understand your pain, but this is not a good enough motivation for moving the burden of backward compatibility on the community shoulders; I know that this is not what you meant but the true reality is that the issues you have faced with upgrades were not even strong enough to induce you or Adam (that are in the restricted group of the most generous contributors) to contribute back upgrade scripts etc... so I don't expect they will be a strong motivation for others. Enforcing a rule is not enough. We have to find better ways of inducing the community to help with backward compatibility. And one way is the one I have suggested: invite companies or service providers that are in the process of upgrading an OFBiz instance to discuss the process in the list and to cotribute back their experiences, scripts etc... others will benefit from this and may also help. This is very different from expecting the "upgrade button" to ba made available by committers. This is more in line with the effort of building a community of people interested in upgrades and willing to help, contribute and participate. Jacopo > > My $0.02. > > ----- "Jacopo Cappellato" wrote: >> 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 > -- > Ean Schuessler, CTO Brainfood.com > [hidden email] - http://www.brainfood.com - 214-720-0700 x 315 |
Re: squareFootage with decimals
|
|
This may or may not help this conversation, but to be clear I no longer believe in the vision of a developer friendly community. Some good things certainly come from the model of community over code and developers being the most important part of a community, but my opinion these days is that e problems trump the benefits. In an effort where there is a clear design with a written and accepted specification this model seems to work fine. However when the project is not simply implementing an established design what ensues is nothing short of chaos and fighting over design with no clear targets or requirements to help people make decisions. In short that is why I don't believe in this model for OFBiz. We have problems with designs and not so much with implementation. Most of the problems in the project are due to bad design (or no design other than whatever the code happens to do) and no amount of good implementation can fix that. With testing efforts this will only become more pronounced. Testing efforts will reveal the lack of designs more and more,and while writing tests some functionality gaps will certainly be filled in, but the mind set of testing that includes trying all possibilities will result in enormous scope creep to add to the already staggering amount of unused code. Actually I'm wrong in using the term scope creep because that would imply that some sort of scope had been established before. I mentioned some stuff about a better approach, or better priorities, in another email where I wrote a little about the NUMMI car plant as an interesting example of a possibly better way to go. Maybe it was silly to think it would ever work well this way and you can't get around prioritizing users over developers and code quality and good design over developers. -David On Apr 6, 2010, at 3:29 AM, Jacopo Cappellato <[hidden email]> wrote: > > On Apr 3, 2010, at 6:59 PM, Ean Schuessler wrote: > >> I have a friend who's favorite business saying is "start out where you want to end up". It is sort of a nonsense phrase but it says something similar to "a stitch in time saves none". If we are clear about what we are trying to build it will be much easier to put those fixes in now than to try to change course down the road. >> >> In my mind, we are trying to do something revolutionary which is to bring the power of ERP down to the small to medium size business player. Its revolutionary because, if successful, it has the potential to change the dynamics of business and the structure of the world economy. If we are going to succeed in that task we are really forced to confront the reality of what those business owners need. That means providing business continuity even in the face of small budgets and a minimal IT staff. > > Agreed. But the main point that is often ignored is that we are doing this revolution with *minimal* resources: a limited group of active committers and a small group of service providers. > The only way we can win is to understand our limits and be clever and study new (unconventional) ways of achieving our goals. > This was done in the past of OFBiz, mostly thanks to David's vision (developer friendly community, push to use the trunk to maximize feedback and contributions etc...). > >> If we can make the "myth" of easy upgrades a reality then our software it going to be much more widely adopted. >> >> I'm not trying to brush the complexity of this under the rug. I agree with you whole-heartedly that seamless upgrade-in-place is probably a real pain for us to achieve. At the same time, it also has the possibility to reduce our overall workload. >> Adam and I personally have to oversee upgrading customer installations on a regular basis and those upgrades are typically time consuming and a little bit scary. If this problem was reduced to literally pushing a button it would free up time that could be spent on more productive tasks that actually improve the customer's business. > > I understand your pain, but this is not a good enough motivation for moving the burden of backward compatibility on the community shoulders; I know that this is not what you meant but the true reality is that the issues you have faced with upgrades were not even strong enough to induce you or Adam (that are in the restricted group of the most generous contributors) to contribute back upgrade scripts etc... so I don't expect they will be a strong motivation for others. Enforcing a rule is not enough. We have to find better ways of inducing the community to help with backward compatibility. > And one way is the one I have suggested: invite companies or service providers that are in the process of upgrading an OFBiz instance to discuss the process in the list and to cotribute back their experiences, scripts etc... others will benefit from this and may also help. This is very different from expecting the "upgrade button" to ba made available by committers. This is more in line with the effort of building a community of people interested in upgrades and willing to help, contribute and participate. > > Jacopo > >> >> My $0.02. >> >> ----- "Jacopo Cappellato" wrote: >>> 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 >> -- >> Ean Schuessler, CTO Brainfood.com >> [hidden email] - http://www.brainfood.com - 214-720-0700 x 315 > |
Re: squareFootage with decimals
|
|
This is an interesting comment. What we can d to improve this?
Here is a suggestion: from now on each and every commit to trunk will have to contain the reference to a (short) story that describes the context (i.e. generic business process) that the commit is enhancing. This doesn't mean that there will be a story for each commit since several commits will share the same story; over time we will create a good set of stories and it will be easier, when a new story is added, to verify if it represents an alternative/redundant feature etc... At the beginning there will be some overhead on the shoulders of committers, but if we are good at keeping the stories consistent this would also help the participation to non-tech guys. The stories could stay in Confluence or (maybe better) in Jira (easier to associate commits to Jira tasks). Jacopo On Apr 8, 2010, at 12:50 AM, David E Jones wrote: > > This may or may not help this conversation, but to be clear I no longer believe in the vision of a developer friendly community. Some good things certainly come from the model of community over code and developers being the most important part of a community, but my opinion these days is that e problems trump the benefits. > > In an effort where there is a clear design with a written and accepted specification this model seems to work fine. However when the project is not simply implementing an established design what ensues is nothing short of chaos and fighting over design with no clear targets or requirements to help people make decisions. > > In short that is why I don't believe in this model for OFBiz. We have problems with designs and not so much with implementation. Most of the problems in the project are due to bad design (or no design other than whatever the code happens to do) and no amount of good implementation can fix that. With testing efforts this will only become more pronounced. Testing efforts will reveal the lack of designs more and more,and while writing tests some functionality gaps will certainly be filled in, but the mind set of testing that includes trying all possibilities will result in enormous scope creep to add to the already staggering amount of unused code. Actually I'm wrong in using the term scope creep because that would imply that some sort of scope had been established before. > > I mentioned some stuff about a better approach, or better priorities, in another email where I wrote a little about the NUMMI car plant as an interesting example of a possibly better way to go. Maybe it was silly to think it would ever work well this way and you can't get around prioritizing users over developers and code quality and good design over developers. > > -David > > > On Apr 6, 2010, at 3:29 AM, Jacopo Cappellato <[hidden email]> wrote: > >> >> On Apr 3, 2010, at 6:59 PM, Ean Schuessler wrote: >> >>> I have a friend who's favorite business saying is "start out where you want to end up". It is sort of a nonsense phrase but it says something similar to "a stitch in time saves none". If we are clear about what we are trying to build it will be much easier to put those fixes in now than to try to change course down the road. >>> >>> In my mind, we are trying to do something revolutionary which is to bring the power of ERP down to the small to medium size business player. Its revolutionary because, if successful, it has the potential to change the dynamics of business and the structure of the world economy. If we are going to succeed in that task we are really forced to confront the reality of what those business owners need. That means providing business continuity even in the face of small budgets and a minimal IT staff. >> >> Agreed. But the main point that is often ignored is that we are doing this revolution with *minimal* resources: a limited group of active committers and a small group of service providers. >> The only way we can win is to understand our limits and be clever and study new (unconventional) ways of achieving our goals. >> This was done in the past of OFBiz, mostly thanks to David's vision (developer friendly community, push to use the trunk to maximize feedback and contributions etc...). >> >>> If we can make the "myth" of easy upgrades a reality then our software it going to be much more widely adopted. >>> >>> I'm not trying to brush the complexity of this under the rug. I agree with you whole-heartedly that seamless upgrade-in-place is probably a real pain for us to achieve. At the same time, it also has the possibility to reduce our overall workload. >>> Adam and I personally have to oversee upgrading customer installations on a regular basis and those upgrades are typically time consuming and a little bit scary. If this problem was reduced to literally pushing a button it would free up time that could be spent on more productive tasks that actually improve the customer's business. >> >> I understand your pain, but this is not a good enough motivation for moving the burden of backward compatibility on the community shoulders; I know that this is not what you meant but the true reality is that the issues you have faced with upgrades were not even strong enough to induce you or Adam (that are in the restricted group of the most generous contributors) to contribute back upgrade scripts etc... so I don't expect they will be a strong motivation for others. Enforcing a rule is not enough. We have to find better ways of inducing the community to help with backward compatibility. >> And one way is the one I have suggested: invite companies or service providers that are in the process of upgrading an OFBiz instance to discuss the process in the list and to cotribute back their experiences, scripts etc... others will benefit from this and may also help. This is very different from expecting the "upgrade button" to ba made available by committers. This is more in line with the effort of building a community of people interested in upgrades and willing to help, contribute and participate. >> >> Jacopo >> >>> >>> My $0.02. >>> >>> ----- "Jacopo Cappellato" wrote: >>>> 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 >>> -- >>> Ean Schuessler, CTO Brainfood.com >>> [hidden email] - http://www.brainfood.com - 214-720-0700 x 315 >> |
OFBiz development and high level stories/requirements WAS: Re: squareFootage with decimals
|
|
I would like to keep this conversation alive because I think it is an important one.
What do you think about the idea of creating and maintaining stories (*) that have to be referenced in commit logs (ideally each and every commit log should be associated to a story; the same story can be associated to several commit logs) as a way to focus the attention of the community around requirements behind commits? I think it would be a valuable approach to enable the community interaction around requirements (instead of implementation as it is happening now) with the final goal of: 1) documenting the high level requirements (stories) available implemented by screens and artifacts in OFBiz 2) facilitate the participation in the growth of OFBiz of less technical contributors (e.g. analysts) Jacopo (*) An example of story could be the following one: "Sales Orders are approved automatically when paid by credit card and CC authorization is successful. Sales Orders are placed in Pending status approval after checkout then auto-approve once third-party payment processor (PayPal, GoogleCheckout, etc) sends notification. Sales Orders are placed in Rejected status when authorization fails. Once order is approved inventory is automatically reserved, reducing Available To Promise (ATP) quantity. If inventory is not available negative inventory reservations are created and the order is placed on back-order." Company sends confirmation email to the Placing Customer." On Apr 8, 2010, at 2:34 PM, Jacopo Cappellato wrote: > This is an interesting comment. What we can d to improve this? > Here is a suggestion: from now on each and every commit to trunk will have to contain the reference to a (short) story that describes the context (i.e. generic business process) that the commit is enhancing. > This doesn't mean that there will be a story for each commit since several commits will share the same story; over time we will create a good set of stories and it will be easier, when a new story is added, to verify if it represents an alternative/redundant feature etc... > At the beginning there will be some overhead on the shoulders of committers, but if we are good at keeping the stories consistent this would also help the participation to non-tech guys. > The stories could stay in Confluence or (maybe better) in Jira (easier to associate commits to Jira tasks). > > Jacopo > > > On Apr 8, 2010, at 12:50 AM, David E Jones wrote: > >> >> This may or may not help this conversation, but to be clear I no longer believe in the vision of a developer friendly community. Some good things certainly come from the model of community over code and developers being the most important part of a community, but my opinion these days is that e problems trump the benefits. >> >> In an effort where there is a clear design with a written and accepted specification this model seems to work fine. However when the project is not simply implementing an established design what ensues is nothing short of chaos and fighting over design with no clear targets or requirements to help people make decisions. >> >> In short that is why I don't believe in this model for OFBiz. We have problems with designs and not so much with implementation. Most of the problems in the project are due to bad design (or no design other than whatever the code happens to do) and no amount of good implementation can fix that. With testing efforts this will only become more pronounced. Testing efforts will reveal the lack of designs more and more,and while writing tests some functionality gaps will certainly be filled in, but the mind set of testing that includes trying all possibilities will result in enormous scope creep to add to the already staggering amount of unused code. Actually I'm wrong in using the term scope creep because that would imply that some sort of scope had been established before. >> >> I mentioned some stuff about a better approach, or better priorities, in another email where I wrote a little about the NUMMI car plant as an interesting example of a possibly better way to go. Maybe it was silly to think it would ever work well this way and you can't get around prioritizing users over developers and code quality and good design over developers. >> >> -David >> |
Re: OFBiz development and high level stories/requirements WAS: Re: squareFootage with decimals
|
|
In reply to this post by Jacopo Cappellato-4
here here.
This is my approach every time with a client. I find it helps them understand their own business as well as how ofbiz can help. I get their story of how they do business before implementing ofbiz. We sometimes discuss how they do business now, before ofbiz could be changed to help the bottom line. I then link the functionality of ofbiz to their story, as a migration to they can say we do this now and ofbiz will help this way in doing this. When ofbiz does not do part of their story I show what can be done to make ofbiz help in that part of the story. and I keep the detailed steps to accomplish that in a separate project manager software,linked to their story, for implementation should they want that. i can then hand the project task and story to a programmer to implement. I have found it very successful. A typical slice of a story is like I open the door and go to my desk the first thing I usually do is check emails for any major issues. As I go get coffee I let the orders print out to review. and so on. Though this story is probably not quite what we want, it has the basic to pull a story like you suggest. ========================= BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93> Specialtymarket.com <http://www.specialtymarket.com/> Systems Integrator-- Glad to Assist Chat Y! messenger: bjfr33man <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro> Jacopo Cappellato sent the following on 4/13/2010 12:34 AM: > I would like to keep this conversation alive because I think it is an important one. > What do you think about the idea of creating and maintaining stories (*) that have to be referenced in commit logs (ideally each and every commit log should be associated to a story; the same story can be associated to several commit logs) as a way to focus the attention of the community around requirements behind commits? > I think it would be a valuable approach to enable the community interaction around requirements (instead of implementation as it is happening now) with the final goal of: > 1) documenting the high level requirements (stories) available implemented by screens and artifacts in OFBiz > 2) facilitate the participation in the growth of OFBiz of less technical contributors (e.g. analysts) > > Jacopo > > (*) An example of story could be the following one: > "Sales Orders are approved automatically when paid by credit card and CC authorization is successful. > Sales Orders are placed in Pending status approval after checkout then auto-approve once third-party payment processor (PayPal, GoogleCheckout, etc) sends notification. > Sales Orders are placed in Rejected status when authorization fails. > Once order is approved inventory is automatically reserved, reducing Available To Promise (ATP) quantity. If inventory is not available negative inventory reservations are created and the order is placed on back-order." > > Company sends confirmation email to the Placing Customer." > On Apr 8, 2010, at 2:34 PM, Jacopo Cappellato wrote: > >> This is an interesting comment. What we can d to improve this? >> Here is a suggestion: from now on each and every commit to trunk will have to contain the reference to a (short) story that describes the context (i.e. generic business process) that the commit is enhancing. >> This doesn't mean that there will be a story for each commit since several commits will share the same story; over time we will create a good set of stories and it will be easier, when a new story is added, to verify if it represents an alternative/redundant feature etc... >> At the beginning there will be some overhead on the shoulders of committers, but if we are good at keeping the stories consistent this would also help the participation to non-tech guys. >> The stories could stay in Confluence or (maybe better) in Jira (easier to associate commits to Jira tasks). >> >> Jacopo >> >> >> On Apr 8, 2010, at 12:50 AM, David E Jones wrote: >> >>> This may or may not help this conversation, but to be clear I no longer believe in the vision of a developer friendly community. Some good things certainly come from the model of community over code and developers being the most important part of a community, but my opinion these days is that e problems trump the benefits. >>> >>> In an effort where there is a clear design with a written and accepted specification this model seems to work fine. However when the project is not simply implementing an established design what ensues is nothing short of chaos and fighting over design with no clear targets or requirements to help people make decisions. >>> >>> In short that is why I don't believe in this model for OFBiz. We have problems with designs and not so much with implementation. Most of the problems in the project are due to bad design (or no design other than whatever the code happens to do) and no amount of good implementation can fix that. With testing efforts this will only become more pronounced. Testing efforts will reveal the lack of designs more and more,and while writing tests some functionality gaps will certainly be filled in, but the mind set of testing that includes trying all possibilities will result in enormous scope creep to add to the already staggering amount of unused code. Actually I'm wrong in using the term scope creep because that would imply that some sort of scope had been established before. >>> >>> I mentioned some stuff about a better approach, or better priorities, in another email where I wrote a little about the NUMMI car plant as an interesting example of a possibly better way to go. Maybe it was silly to think it would ever work well this way and you can't get around prioritizing users over developers and code quality and good design over developers. >>> >>> -David >>> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |