We already use this approach for changes in code. Even with rules to how when
removing deprecated things
I don't see why it would be different for data model, and data (seed, etc.) at
large
Other opinions?
Jacques
Le 17/04/2018 à 16:28, Rajesh Mallah a écrit :
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.
![http://logos.stannah.co.uk/enviro.jpg]Please](http://logos.stannah.co.uk/enviro.jpg]Please){kind=link}