You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2009/01/22 09:24:29 UTC
Re: svn commit: r735404 - in /ofbiz/trunk: applications/accounting/entitydef/ applications/ecommerce/data/ applications/party/ applications/party/data/ applications/party/entitydef/ applications/party/src/org/ofbiz/party/party/ applications/party/webapp/pa
Yes, actually to be frank I did it in a hurry and forgot about using rel-field-name and also I guess I copied from PeriodType (just
above in file) which has the same issue.
Done in r736586
Should we change PeriodType also (inconvenient for legacy reasons I guess) ?
Actually
FixedAsset,
InvoiceItem, InvoiceTerm (no relation with Uom),
SettlementTerm (no relation with Uom),
BillingAccountTerm,
OrderTerm,
QuoteItem, QuoteTerm (no relation with Uom),
ProductFeature (no relation with Uom),
InventoryItem
are in the same case...
Jacques
From: "David E Jones" <de...@me.com>
>
> This looks good Jacques. One thing I'd recommend changing is the field name "uomId". As-is it is ambiguous. You mentioned the
> field it describes in the comment for it, and that's great, but I've been trying to push for more descriptive names that include
> the name of the field it modifies, like "elevationUomId" since it only describes the elevation field.
>
> -David
>
>
> On Jan 18, 2009, at 2:09 AM, jleroux@apache.org wrote:
>
>>
>> Modified: ofbiz/trunk/framework/common/entitydef/entitymodel.xml
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/entitydef/entitymodel.xml?rev=735404&r1=735403&r2=735404&view=diff
>> = = = = = = = = ======================================================================
>> --- ofbiz/trunk/framework/common/entitydef/entitymodel.xml (original)
>> +++ ofbiz/trunk/framework/common/entitydef/entitymodel.xml Sun Jan 18 01:09:32 2009
>> @@ -156,6 +156,7 @@
>> <field name="geoCode" type="short-varchar"></field>
>> <field name="geoSecCode" type="short-varchar"></field>
>> <field name="abbreviation" type="short-varchar"></field>
>> + <field name="wellKnownText" type="very-long"></field>
>> <prim-key field="geoId"/>
>> <relation type="one" fk-name="GEO_TO_TYPE" rel-entity- name="GeoType">
>> <key-map field-name="geoTypeId"/>
>> @@ -205,7 +206,24 @@
>> <key-map field-name="parentTypeId" rel-field- name="geoTypeId"/>
>> </relation>
>> </entity>
>> -
>> + <entity entity-name="GeoPoint" package- name="org.ofbiz.common.geo" default-resource-name="CommonEntityLabels"
>> + title="Geographic Location">
>> + <field name="geoPointId" type="id-ne"></field>
>> + <field name="dataSourceId" type="id"></field>
>> + <field name="latitude" type="floating-point" not-null="true"></ field>
>> + <field name="longitude" type="floating-point" not-null="true"></ field>
>> + <field name="elevation" type="floating-point"></field>
>> + <field name="uomId" type="id"><description>We need an UOM for elevation (feet, meters, etc.)</description></field>
>> + <field name="information" type="comment"><description>To enter any related information</description></field>
>> + <prim-key field="geoPointId"/>
>> + <relation type="one" fk-name="GEOPOINT_DTSRC" rel-entity- name="DataSource">
>> + <key-map field-name="dataSourceId"/>
>> + </relation>
>> + <relation type="one" fk-name="GPT_TYPE_UOM" rel-entity- name="Uom">
>> + <key-map field-name="uomId"/>
>> + </relation>
>> + </entity>
>> +
>> <!-- ========================================================= -->
>> <!-- org.ofbiz.common.keyword -->
>> <!-- ========================================================= -->
>>
>
Re: svn commit: r735404 - in /ofbiz/trunk: applications/accounting/entitydef/ applications/ecommerce/data/ applications/party/ applications/party/data/ applications/party/entitydef/ applications/party/src/org/ofbiz/party/party/ applications/party/webapp/pa
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <da...@hotwaxmedia.com>
>
> On Jan 22, 2009, at 2:34 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>>> http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration
>>> Hans originally wrote that page, and I have updated it to recommend
>>> following the established deprecation pattern, as I've described
>>> above (those who have followed the mailing list know that a few
>>> committers have rebelled against this pattern claiming it is too
>>> much work... so I also added a request to end-users to complain so
>>> that we all understand better why it is important).
>>
>> Are you sure? I have followed that type of discussion pretty
>> closely, and I recall some committers being confused about the
>> pattern and needing additional guidance, but I don't recall a
>> committer rebelling against it.
>
> Just check out that page and look at the instructions there for
> various revisions.
>
> Maybe "rebelling" is too strong a word, but personally with my "End-
> User Advocate" hat on I'd much rather see us writing services to move
> data around when migration is needed rather than saying "do it
> manually using export, a text editor, and import".
>
> -David
Yes, this sounds more "professional"
Jacques
Re: svn commit: r735404 - in /ofbiz/trunk: applications/accounting/entitydef/
applications/ecommerce/data/ applications/party/ applications/party/data/
applications/party/entitydef/ applications/party/src/org/ofbiz/party/party/
applications/party/webapp/pa
Posted by Ray <ra...@makeyour-point.com>.
Hmmm I added a comment to one of those "export, text editor, import"
sections because I spent to long trying to find what the problem was
with an update. But I only added that comment in the hope of reducing
others pain for a change that had already been made rather than going
against the guidance.
Really until there's an update system that actually drives you through
the change process required it's always going to be a pain or something
that gets missed until problems show, but that's another job in itself.
Ray
David E Jones wrote:
>
> On Jan 22, 2009, at 2:34 PM, Adrian Crum wrote:
>
>> David E Jones wrote:
>> Are you sure? I have followed that type of discussion pretty closely,
>> and I recall some committers being confused about the pattern and
>> needing additional guidance, but I don't recall a committer rebelling
>> against it.
>
> Just check out that page and look at the instructions there for various
> revisions.
>
> Maybe "rebelling" is too strong a word, but personally with my "End-User
> Advocate" hat on I'd much rather see us writing services to move data
> around when migration is needed rather than saying "do it manually using
> export, a text editor, and import".
>
> -David
>
>
Re: svn commit: r735404 - in /ofbiz/trunk: applications/accounting/entitydef/ applications/ecommerce/data/ applications/party/ applications/party/data/ applications/party/entitydef/ applications/party/src/org/ofbiz/party/party/ applications/party/webapp/pa
Posted by David E Jones <da...@hotwaxmedia.com>.
On Jan 22, 2009, at 2:34 PM, Adrian Crum wrote:
> David E Jones wrote:
>> http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration
>> Hans originally wrote that page, and I have updated it to recommend
>> following the established deprecation pattern, as I've described
>> above (those who have followed the mailing list know that a few
>> committers have rebelled against this pattern claiming it is too
>> much work... so I also added a request to end-users to complain so
>> that we all understand better why it is important).
>
> Are you sure? I have followed that type of discussion pretty
> closely, and I recall some committers being confused about the
> pattern and needing additional guidance, but I don't recall a
> committer rebelling against it.
Just check out that page and look at the instructions there for
various revisions.
Maybe "rebelling" is too strong a word, but personally with my "End-
User Advocate" hat on I'd much rather see us writing services to move
data around when migration is needed rather than saying "do it
manually using export, a text editor, and import".
-David
Re: svn commit: r735404 - in /ofbiz/trunk: applications/accounting/entitydef/
applications/ecommerce/data/ applications/party/ applications/party/data/
applications/party/entitydef/ applications/party/src/org/ofbiz/party/party/
applications/party/webapp/pa
Posted by Adrian Crum <ad...@hlmksw.com>.
David E Jones wrote:
> http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration
>
> Hans originally wrote that page, and I have updated it to recommend
> following the established deprecation pattern, as I've described above
> (those who have followed the mailing list know that a few committers
> have rebelled against this pattern claiming it is too much work... so I
> also added a request to end-users to complain so that we all understand
> better why it is important).
Are you sure? I have followed that type of discussion pretty closely,
and I recall some committers being confused about the pattern and
needing additional guidance, but I don't recall a committer rebelling
against it.
-Adrian
Re: svn commit: r735404 - in /ofbiz/trunk: applications/accounting/entitydef/ applications/ecommerce/data/ applications/party/ applications/party/data/ applications/party/entitydef/ applications/party/src/org/ofbiz/party/party/ applications/party/webapp/pa
Posted by David E Jones <da...@hotwaxmedia.com>.
These things are not all that difficult to go back and change, but are
very inconvenient. Changing them requires changes in the model and
code that uses it, and in custom code, and in production databases
which will need data migration.
If someone wanted to work on this it could be done, and there is
precedent for it with other data model changes that deprecate old
fields or entire entities. The "old" prefix pattern used for entities
should be used for the fields, and services should be written to move
the data from the "oldUomId" fields to whatever their new name is.
And, these should be documented on the data model change page:
http://docs.ofbiz.org/display/OFBTECH/Revisions+Requiring+Data+Migration
Hans originally wrote that page, and I have updated it to recommend
following the established deprecation pattern, as I've described above
(those who have followed the mailing list know that a few committers
have rebelled against this pattern claiming it is too much work... so
I also added a request to end-users to complain so that we all
understand better why it is important).
-David
On Jan 22, 2009, at 1:24 AM, Jacques Le Roux wrote:
> Yes, actually to be frank I did it in a hurry and forgot about using
> rel-field-name and also I guess I copied from PeriodType (just above
> in file) which has the same issue.
> Done in r736586
>
> Should we change PeriodType also (inconvenient for legacy reasons I
> guess) ?
> Actually
> FixedAsset,
> InvoiceItem, InvoiceTerm (no relation with Uom),
> SettlementTerm (no relation with Uom),
> BillingAccountTerm,
> OrderTerm,
> QuoteItem, QuoteTerm (no relation with Uom),
> ProductFeature (no relation with Uom),
> InventoryItem
> are in the same case...
>
> Jacques
>
> From: "David E Jones" <de...@me.com>
>>
>> This looks good Jacques. One thing I'd recommend changing is the
>> field name "uomId". As-is it is ambiguous. You mentioned the field
>> it describes in the comment for it, and that's great, but I've
>> been trying to push for more descriptive names that include the
>> name of the field it modifies, like "elevationUomId" since it only
>> describes the elevation field.
>>
>> -David
>>
>>
>> On Jan 18, 2009, at 2:09 AM, jleroux@apache.org wrote:
>>
>>>
>>> Modified: ofbiz/trunk/framework/common/entitydef/entitymodel.xml
>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/entitydef/entitymodel.xml?rev=735404&r1=735403&r2=735404&view=diff
>>> = = = = = = = =
>>> =
>>> =
>>> ====================================================================
>>> --- ofbiz/trunk/framework/common/entitydef/entitymodel.xml
>>> (original)
>>> +++ ofbiz/trunk/framework/common/entitydef/entitymodel.xml Sun
>>> Jan 18 01:09:32 2009
>>> @@ -156,6 +156,7 @@
>>> <field name="geoCode" type="short-varchar"></field>
>>> <field name="geoSecCode" type="short-varchar"></field>
>>> <field name="abbreviation" type="short-varchar"></field>
>>> + <field name="wellKnownText" type="very-long"></field>
>>> <prim-key field="geoId"/>
>>> <relation type="one" fk-name="GEO_TO_TYPE" rel-entity-
>>> name="GeoType">
>>> <key-map field-name="geoTypeId"/>
>>> @@ -205,7 +206,24 @@
>>> <key-map field-name="parentTypeId" rel-field-
>>> name="geoTypeId"/>
>>> </relation>
>>> </entity>
>>> -
>>> + <entity entity-name="GeoPoint" package-
>>> name="org.ofbiz.common.geo" default-resource-
>>> name="CommonEntityLabels"
>>> + title="Geographic Location">
>>> + <field name="geoPointId" type="id-ne"></field>
>>> + <field name="dataSourceId" type="id"></field>
>>> + <field name="latitude" type="floating-point" not-
>>> null="true"></ field>
>>> + <field name="longitude" type="floating-point" not-
>>> null="true"></ field>
>>> + <field name="elevation" type="floating-point"></field>
>>> + <field name="uomId" type="id"><description>We need an UOM
>>> for elevation (feet, meters, etc.)</description></field>
>>> + <field name="information" type="comment"><description>To
>>> enter any related information</description></field>
>>> + <prim-key field="geoPointId"/>
>>> + <relation type="one" fk-name="GEOPOINT_DTSRC" rel-entity-
>>> name="DataSource">
>>> + <key-map field-name="dataSourceId"/>
>>> + </relation>
>>> + <relation type="one" fk-name="GPT_TYPE_UOM" rel-entity-
>>> name="Uom">
>>> + <key-map field-name="uomId"/>
>>> + </relation>
>>> + </entity>
>>> +
>>> <!-- ========================================================= -->
>>> <!-- org.ofbiz.common.keyword -->
>>> <!-- ========================================================= -->
>>>
>