I feel this approach ( deprecated=”true” ) gives breathing space for
stakeholders
to absorb changes at their own pace. And its not unique here , most
reputable
softwares takes this path of warning deprecated usages.

Also it is not going to be first or last sweeping change (if at all we take
that approach)
I feel we must take backward compatibility seriously in our approaches as
ERP systems
are usually of CRITICAL nature and losses due to non-availability tends to
multiply downstream.

regds
mallah.



On Tue, Apr 17, 2018 at 5:26 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> That's interesting, I had no idea about
>     deprecated=”true” entity-ref=”OrderShipGroup”
>
> So this would need some changes in the Entity Engine, but at 1st glance it
> seems doable.
>
> Would you mind provide a patch for review, if others agree about the idea?
>
> Jacques
>
>
> Le 17/04/2018 à 13:22, Gareth Carter a écrit :
>
>> 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
>> https://cwiki.apache.org/confluence/display/OFBIZ/General+
>> Entity+Overview#GeneralEntityOverview-DeprecatedEntities
>>
>> 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”
>> entity-ref=”OrderShipGroup”>
>> … no fields but use all fields defined in OrderShipGroup
>> </entity>
>>
>> <entity entity-name=”OrderShipGroup” ….>
>> ...fields defined here
>> </entity>
>>
>> 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
>>
>>
>> Ext:
>>
>>
>> 7036
>>
>>
>> DDI:
>>
>>
>> 01264 364311
>>
>>
>>
>>
>> [http://logos.stannah.co.uk/stan150.jpg]
>>
>>
>> [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:
>> https://markmail.org/message/wypy4tuhyyv5bugw<https://markma
>> il.org/message/wypy4tuhyyv5bugw>
>>
>> Jacques
>>
>>
>> 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