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 bo
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 associ
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 the
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
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
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 sho
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
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 t
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 h
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 Entiti
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
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"
Ha, I thought it would work in any DBMS, though th
From: "Wickersheimer Jeremy"
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
From: "Wickersheimer Jeremy"
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
From: "Jacques Le Roux"
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: "Wicke
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: "D
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"
Think about what happens to users who don't know about the simple migration
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
The only drawback I see with this manner I used, is that there is no easy history because no old_entity. But do we really need that?
Moreover, as you said, in this peculiar very simple case.
As ever, I tried KISS
Jacques
From: "Scott Gray"
I just thought it was how we do this sort of thing, I
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 faci
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 Ro
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 (.00 for legacy)
Of course they need to udpate the UI. It's provided in the commit. But maybe
there is your concern
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 y
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"
Hi Jacques,
On Mar 31, 2010, at 2:39 PM, Jacques Le Roux wrote:
Done at r929503, see also
http://cwiki.apa
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) i
Done at r929503, see also
http://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
Jacques
From: "Jacques Le Roux"
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 ch
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
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'
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 serv
Thanks David, I didn't look at the entity in question before commenting, if
there is a uom already then Jacques proposal sounds fine to me (aside from the
unfortunate name of the existing value field).
Regards
Scott
On 30/03/2010, at 9:37 AM, David E Jones wrote:
>
> A storage tank might be b
From: "David E Jones"
A storage tank might be better modeled as an asset that is located in a
facility rather than being a facility itself.
BTW, we already have a UOM field to go along with the "squareFootage" field (which is unfortunate that it was done that way, but
it's been there for a wh
From: "David E Jones"
A storage tank might be better modeled as an asset that is located in a
facility rather than being a facility itself.
BTW, we already have a UOM field to go along with the "squareFootage" field (which is unfortunate that it was done that way, but
it's been there for a wh
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 nee
According to the Data Model Resource Book, a FACILITY entity stores the
attributes or relationships associated with a physical structure.
Facility types include warehouse, plant, building, room, office.
The type of storage tank I was referring to is one you would see in a
tank farm - it could
A storage tank might be better modeled as an asset that is located in a
facility rather than being a facility itself.
BTW, we already have a UOM field to go along with the "squareFootage" field
(which is unfortunate that it was done that way, but it's been there for a
while now). This isn't a
Good idea Scott! Taking it one step further, how about supporting volume
too? A facility might be a storage tank.
-Adrian
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
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/20
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
38 matches
Mail list logo
