You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Jacopo Cappellato <ti...@sastau.it> on 2007/02/24 12:07:45 UTC

Re: Proposed change to the pk of ProductStoreShipmentMeth

This is now implemented in rev. 511250

Jacopo

David E. Jones wrote:
> 
> I'm personally a very big fan of composite "natural" primary keys, and 
> think they should always be the default.
> 
> Still, sometimes they just don't work or apply because in the end there 
> is no natural composite key, and these sorts of "rule" types entities 
> with possibly many varying factors often have this problem.
> 
> So, yeah, I'm fine with the change. It means everyone updating will have 
> to re-create the primary key, and between dropping the old one and 
> creating a new one they'll have to fill in the new sequenced ID.
> 
> BTW, an easy way to do this for everyone reading in: just export the 
> data to an XML file, drop the table, have OFBiz re-create it, and then 
> import the data (without changing it...). The entity engine will 
> automatically sequence the data for the new field with the entity name 
> as the sequence name. It always does this if there is a single pk field 
> and there is not value for it in the entity engine XML file.
> 
> Just another trick of the trade I guess. It's also the type that's 
> documented, but the application of it is not always obvious. This is why 
> I like the training video idea so much, or even throwing the audio from 
> it onto an ipod or something, so that you can spend some time every week 
> reviewing things. Anyway, I guess that's a side thought, and a bit off 
> topic.
> 
> Whatever the case, yeah, go for it. The upgrade path is fairly straight 
> and not too foggy.
> 
> -David
> 
> 
> On Feb 13, 2007, at 1:50 AM, Jacopo Cappellato wrote:
> 
>> What about changing the primary key of the ProductStoreShipmentMeth from:
>>
>> productStoreId
>> shipmentMethodTypeId
>> partyId
>> roleTypeId
>>
>> to:
>>
>> productStoreShipMethId (new field)
>>
>> I did it some time ago for a customer with the need to express rather 
>> complex shipping rules where:
>>
>> 1) the order amount was used to determine the shipping cost estimate
>> 2) the postal address and weight were used to select the available 
>> shipping options
>>
>> For #1 the existing shipping estimate and quantity breaks entities 
>> were perfect.
>> For #2 I had to change the primary key for the 
>> ProductStoreShipmentMeth entity because I had to associate the same 
>> "shipment method|carrier" to the store many times for different 
>> combinations of geo and weight.
>>
>> For example:
>> * USPS is available in NY if weight is less than 30kg
>> * UPS is available in NY if weight is more than 30kg
>> * UPS is the only available method in LA
>> etc...
>>
>> If you agree with the above change, I will commit a patch that it will 
>> address all the business logic changes (and ui changes) needed to 
>> support the different pk (that are really very few); and the modified 
>> system is much more flexible and is woking fine.
>>
>> What do you think?
>>
>> Jacopo
>>
>> Index: applications/product/entitydef/entitymodel.xml
>> ===================================================================
>> --- applications/product/entitydef/entitymodel.xml    (revisione 505884)
>> +++ applications/product/entitydef/entitymodel.xml    (copia locale)
>> @@ -3520,6 +3520,7 @@
>>      <entity entity-name="ProductStoreShipmentMeth"
>>              package-name="org.ofbiz.product.store"
>>              title="Product Store Carrier Shipment Method Entity">
>> +      <field name="productStoreShipMethId" type="id-ne"></field>
>>        <field name="productStoreId" type="id-ne"></field>
>>        <field name="shipmentMethodTypeId" type="id-ne"></field>
>>        <field name="partyId" type="id-ne"></field>
>> @@ -3543,10 +3544,7 @@
>>        <field name="serviceName" type="long-varchar"></field>
>>        <field name="configProps" type="long-varchar"></field>
>>        <field name="sequenceNumber" type="numeric"></field>
>> -      <prim-key field="productStoreId"/>
>> -      <prim-key field="shipmentMethodTypeId"/>
>> -      <prim-key field="partyId"/>
>> -      <prim-key field="roleTypeId"/>
>> +      <prim-key field="productStoreShipMethId"/>
>>        <relation type="one-nofk" rel-entity-name="Party">
>>          <key-map field-name="companyPartyId" rel-field-name="partyId"/>
>>        </relation>
>> @@ -3562,6 +3560,7 @@
>>              title="Product Store Carrier And Shipment Method Type 
>> View Entity">
>>        <member-entity entity-alias="PSSM" 
>> entity-name="ProductStoreShipmentMeth"/>
>>        <member-entity entity-alias="SM" 
>> entity-name="ShipmentMethodType"/>
>> +      <alias entity-alias="PSSM" name="productStoreShipMethId"/>
>>        <alias entity-alias="PSSM" name="productStoreId"/>
>>        <alias entity-alias="PSSM" name="shipmentMethodTypeId"/>
>>        <alias entity-alias="PSSM" name="partyId"/>
>