Ah right, as soon as I replied I remembered you could change the physical table 
an entity points too so there is that work around.

My suggestion is slightly different to the deprecating method noted at 

Rather than rename to Old* and create a migration service. My idea was that the 
old and new entities point to the same physical table and could flag an entity 
as deprecated

For OrderItemShipGroup example

<entity entity-name=”OrderItemShipGroup” deprecated=”true” 
… no fields but use all fields defined in OrderShipGroup

<entity entity-name=”OrderShipGroup” ….>
...fields defined here

OrderItemShipGroup references OrderShipGroup so the entity structure is the 
same (ie fields are the same) and both point to the same physical table.

You can then highlight deprecated entities in webtools or log a warning 
whenever deprecated entities are used. This will alleviate the risk for custom 
components/plugins upgrading to a newer release and give developers time to 
make the changes

Just a thought, I know for a fact that if OrderItemShipGroup and others are 
renamed, we would have a lot of refactoring to do

Gareth Carter

Software Development Analyst

Stannah Management Services Ltd

IT Department




01264 364311


[http://logos.stannah.co.uk/enviro.jpg]Please consider the environment before 
printing this email.

From: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com]
Sent: 17 April 2018 11:21 AM
To: dev@ofbiz.apache.org
Subject: Re: Confusing entity names

Hi Gareth,

Yes, this is how it's supposed to be handled in OFBiz from start, see my answer 
to Mathieu Lirzin in this thread:


Le 17/04/2018 à 12:04, Gareth Carter a écrit :
> Hi all
> This would certainly cause havoc for us! So I would propose not to change 
> them!
> I certainly do agree the names do not make sense so rather than rename, could 
> a new type of entity be created that can reference existing entities? So both 
> old and new entities would work on the same physical table?
> Gareth Carter
> Software Development Analyst
> Stannah Management Services Ltd
> IT Department
> Ext:
> 7036
> DDI:
> 01264 364311
> Please consider the environment before printing this email.
> -----Original Message-----
> From: Rajesh Mallah [mailto:mallah.raj...@gmail.com]
> Sent: 12 April 2018 2:47 PM
> To: dev@ofbiz.apache.org<mailto:dev@ofbiz.apache.org>
> Subject: Re: Confusing entity names
> -1
> is it really worth taking the risk , renaming generally wrecks havoc!
> specially considering OFBiz which have 100's of entities and dozens named 
> similarly.
> however i agree with the proposer that they are not named properly.
> secondly , Is the current state of test suites or integration checks touch 
> scenarios that use the entities in question.
> presence of test suites gives more confidence for undertaking such changes.
> May be once we have these it shall be a better time to fix things that aint' 
> broken.
> regds
> mallah.
> On Thu, Apr 12, 2018 at 6:18 PM, Michael Brohl 
> <michael.br...@ecomify.de<mailto:michael.br...@ecomify.de>>
> wrote:
>> Hi Suraj,
>> thanks for your proposal.
>> Looking at it in isolation, it seems a good idea to just rename these
>> entities.
>> Having the users in mind, I'm not sure if this is worth the need for
>> data migrations they have to do if they want to stay up-to-date.
>> I'm not sure where the original names came from. When I'm in the
>> office tomorrow, I'll consult the Data Model Resource Book. I'll be back 
>> then.
>> Thanks and regards,
>> Michael
>> Am 10.04.18 um 13:24 schrieb Suraj Khurana:
>> Hello,
>>> There are some entities which could be renamed as per their usage.
>>> - *OrderItemShipGroup*: It shows order ship groups and it doesn't
>>> contain anything at order item level. So, it could be re-named as
>>> *OrderShipGroup.*
>>> - *OrderItemShipGroupAssoc: *It do not maintain any association
>>> type, it
>>> just contains order item with respect to ship group, so this could be
>>> re-named as *OrderItemShipGroup *to maintain consistency and code
>>> readablity.
>>> I know that these entities are crucial part of OOTB data model since
>>> inception. Having thought in mind that 'Naming should be self
>>> explanatory', this is a proposal and It would be great to hear
>>> communities thought on this topic.
>>> Please share your opinions on this.
>>> --
>>> Thanks and Regards,
>>> *Suraj Khurana* | Omni-channel OMS Technical Expert *HotWax Commerce*
>>> by *HotWax Systems* Plot no. 80, Scheme no. 78, Vijay Nagar, Indore,
>>> M.P. India 452010 Cell phone: +91 96697-50002
> This email is intended only for the above addressee. It may contain 
> privileged information. If you are not the addressee you must not copy, 
> distribute, disclose or use any of the information in it. If you have 
> received it in error, please delete it and notify the sender.
> Stannah Lift Holdings Ltd registered No. 686996, Stannah Management Services 
> Ltd registered No. 2483693, Stannah Lift Services Ltd registered No. 1189799, 
> Stannah Microlifts Ltd registered No. 964804, Stannah Lifts Ltd registered 
> No. 1189836, Stannah Stairlifts Ltd registered No. 1401451, Global Upholstery 
> Solutions Ltd registered No. 02452728.
> All registered offices at Watt Close, East Portway, Andover, Hampshire, SP10 
> 3SD, England.
> All Registered in England and Wales.

Reply via email to