Confusing entity names

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Confusing entity names

innate Genius
+1 Taher

> On 14-Apr-2018, at 12:40 PM, Taher Alkhateeb <[hidden email]> wrote:
>
> Hi Everyone,
>
> Thinking some more about the concerns from multiple people in this thread
> like Michael, Rajesh, Gil and others I have a different suggestion.
>
> Why not make a sweeping review of the full domain model, and then decide on
> one comprehensive change, with even a migration script that we can offer to
> users. That would be easier than randomly changing a few entities every
> once in a while.
>
> The domain model seems sensitive to many users and I understand that
> because everything builds on top of it. I heard enough objections to
> recommend postponing this task and coming up with something better as
> suggested above.
>
> On Sat, Apr 14, 2018, 9:56 AM Michael Brohl <[hidden email]>
> wrote:
>
>> Suraj,
>>
>> I still do not see much value in this change, compared to the effort
>> needed for development and testing as well as the migration the users
>> have to do.
>>
>> Please consider to not do this change.
>>
>> Thanks,
>>
>> Michael
>>
>>
>> Am 13.04.18 um 10:09 schrieb Suraj Khurana:
>>> Thanks everyone for your thoughts.
>>>
>>> One more point is we also manage Data Migration By release document so it
>>> will help existing uses. Such as https://cwiki.apache.org/confl
>>> uence/display/OFBIZ/Data+Migration+by+releases
>>> <
>> https://www.google.com/url?q=https://cwiki.apache.org/confluence/display/OFBIZ/Data%2BMigration%2Bby%2Breleases&sa=D&source=hangouts&ust=1523684384066000&usg=AFQjCNHrGuEkvs9NdHkf_MUX3tPFJfp2Wg
>>>
>>> Handling of deprecated entities is also properly defined at
>>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/General+Entity+Overview,
>>> we can easily follow these steps.
>>>
>>> We will change entity name and its occurrence everywhere in code base,
>>> provide a data migration service which will be helpful for existing uses.
>>> Further on, thanks to Arun's suggestion, there will not be any confusion
>>> related to entity name as well.
>>>
>>> @Nicolas, Arun also suggested two names to avoid confusion, may be anyone
>>> of them makes more sense to you.
>>>
>>> --
>>> Thanks and Regards,
>>> *Suraj Khurana* | Sr. Enterprise Software Engineer
>>> HotWax Commerce  by  HotWax Systems
>>> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>>> Cell phone: +91 96697-50002
>>>
>>> On Fri, Apr 13, 2018 at 1:22 PM, Nicolas Malin <[hidden email]
>>>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> On 10/04/2018 13:24, Suraj Khurana wrote:
>>>>
>>>>> 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.
>>>>>
>>>> It's big modification with potential side-effect.
>>>> I suggest to move carefully and migrate entities one by one and not all
>> in
>>>> one :)
>>>>
>>>> For the renaming OrderItemShipGroupto OrderShipGroupit's ok but I'm
>>>> against OrderItemShipGroupAssoc to OrderItemShipGroup. As pragmatic
>>>> OrderItemShipGroupAssoc isn't perfect like you spotted but it's easily
>>>> understandable.
>>>>
>>>> Nicolas
>>>>
>>>>> --
>>>>>
>>>>> 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
>>>>>
>>>>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Jacques Le Roux
Administrator
In reply to this post by Jacques Le Roux
Let me clarify my position. I'm not strictly against this change. I don't fear a such OOTB change, after all it's only name change, isn't ? And what
you mentioned below Suraj is the right way to go. Obviously the concern is for custom projects.

Though I'm not directly concerned (I have no current direct responsibilities on custom projects which could be impacted) I can foresee issues on
custom projects even if we provide tests to cover the change as Rajesh rightly suggested. Because tests can't guarantee  to reveal issues in custom
code, so people might overlook when migrating. We have no ideas of what users do in their project, it can be surprising sometimes. So I'd like to have
more opinions and especially ideas of people concerned. I'm not sure we will get them in dev ML. So I think we should ask on user ML. Even if I guess
all users are not reading all messages on user ML, at least we would have done our best.

So it's more a +0 from me.

Jacques


Le 13/04/2018 à 23:01, Jacques Le Roux a écrit :

> Hi Suraj,
>
> Did you get a chance to check if these entities are covered by tests somehow?
>
> Thanks
>
> Jacques
>
>
> Le 13/04/2018 à 10:09, Suraj Khurana a écrit :
>> Thanks everyone for your thoughts.
>>
>> One more point is we also manage Data Migration By release document so it
>> will help existing uses. Such as https://cwiki.apache.org/confl
>> uence/display/OFBIZ/Data+Migration+by+releases
>> <https://www.google.com/url?q=https://cwiki.apache.org/confluence/display/OFBIZ/Data%2BMigration%2Bby%2Breleases&sa=D&source=hangouts&ust=1523684384066000&usg=AFQjCNHrGuEkvs9NdHkf_MUX3tPFJfp2Wg>
>>
>> Handling of deprecated entities is also properly defined at
>> https://cwiki.apache.org/confluence/display/OFBIZ/General+Entity+Overview,
>> we can easily follow these steps.
>>
>> We will change entity name and its occurrence everywhere in code base,
>> provide a data migration service which will be helpful for existing uses.
>> Further on, thanks to Arun's suggestion, there will not be any confusion
>> related to entity name as well.
>>
>> @Nicolas, Arun also suggested two names to avoid confusion, may be anyone
>> of them makes more sense to you.
>>
>> --
>> Thanks and Regards,
>> *Suraj Khurana* | Sr. Enterprise Software Engineer
>> HotWax Commerce  by  HotWax Systems
>> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>> Cell phone: +91 96697-50002
>>
>> On Fri, Apr 13, 2018 at 1:22 PM, Nicolas Malin <[hidden email]>
>> wrote:
>>
>>> Hi
>>>
>>> On 10/04/2018 13:24, Suraj Khurana wrote:
>>>
>>>> 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.
>>>>
>>> It's big modification with potential side-effect.
>>> I suggest to move carefully and migrate entities one by one and not all in
>>> one :)
>>>
>>> For the renaming OrderItemShipGroupto OrderShipGroupit's ok but I'm
>>> against OrderItemShipGroupAssoc to OrderItemShipGroup. As pragmatic
>>> OrderItemShipGroupAssoc isn't perfect like you spotted but it's easily
>>> understandable.
>>>
>>> Nicolas
>>>
>>>> --
>>>>
>>>> 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
>>>>
>>>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Jacques Le Roux
Administrator
In reply to this post by innate Genius
I wonder, should it be really all or nothing? Will it not add more concerns and difficulties to deliver a such big package? Should we wait for that to
happen, and how long?

Jacques


Le 15/04/2018 à 02:55, innate Genius a écrit :

> +1 Taher
>
>> On 14-Apr-2018, at 12:40 PM, Taher Alkhateeb <[hidden email]> wrote:
>>
>> Hi Everyone,
>>
>> Thinking some more about the concerns from multiple people in this thread
>> like Michael, Rajesh, Gil and others I have a different suggestion.
>>
>> Why not make a sweeping review of the full domain model, and then decide on
>> one comprehensive change, with even a migration script that we can offer to
>> users. That would be easier than randomly changing a few entities every
>> once in a while.
>>
>> The domain model seems sensitive to many users and I understand that
>> because everything builds on top of it. I heard enough objections to
>> recommend postponing this task and coming up with something better as
>> suggested above.
>>
>> On Sat, Apr 14, 2018, 9:56 AM Michael Brohl <[hidden email]>
>> wrote:
>>
>>> Suraj,
>>>
>>> I still do not see much value in this change, compared to the effort
>>> needed for development and testing as well as the migration the users
>>> have to do.
>>>
>>> Please consider to not do this change.
>>>
>>> Thanks,
>>>
>>> Michael
>>>
>>>
>>> Am 13.04.18 um 10:09 schrieb Suraj Khurana:
>>>> Thanks everyone for your thoughts.
>>>>
>>>> One more point is we also manage Data Migration By release document so it
>>>> will help existing uses. Such as https://cwiki.apache.org/confl
>>>> uence/display/OFBIZ/Data+Migration+by+releases
>>>> <
>>> https://www.google.com/url?q=https://cwiki.apache.org/confluence/display/OFBIZ/Data%2BMigration%2Bby%2Breleases&sa=D&source=hangouts&ust=1523684384066000&usg=AFQjCNHrGuEkvs9NdHkf_MUX3tPFJfp2Wg
>>>> Handling of deprecated entities is also properly defined at
>>>>
>>> https://cwiki.apache.org/confluence/display/OFBIZ/General+Entity+Overview,
>>>> we can easily follow these steps.
>>>>
>>>> We will change entity name and its occurrence everywhere in code base,
>>>> provide a data migration service which will be helpful for existing uses.
>>>> Further on, thanks to Arun's suggestion, there will not be any confusion
>>>> related to entity name as well.
>>>>
>>>> @Nicolas, Arun also suggested two names to avoid confusion, may be anyone
>>>> of them makes more sense to you.
>>>>
>>>> --
>>>> Thanks and Regards,
>>>> *Suraj Khurana* | Sr. Enterprise Software Engineer
>>>> HotWax Commerce  by  HotWax Systems
>>>> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
>>>> Cell phone: +91 96697-50002
>>>>
>>>> On Fri, Apr 13, 2018 at 1:22 PM, Nicolas Malin <[hidden email]
>>>>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On 10/04/2018 13:24, Suraj Khurana wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>> It's big modification with potential side-effect.
>>>>> I suggest to move carefully and migrate entities one by one and not all
>>> in
>>>>> one :)
>>>>>
>>>>> For the renaming OrderItemShipGroupto OrderShipGroupit's ok but I'm
>>>>> against OrderItemShipGroupAssoc to OrderItemShipGroup. As pragmatic
>>>>> OrderItemShipGroupAssoc isn't perfect like you spotted but it's easily
>>>>> understandable.
>>>>>
>>>>> Nicolas
>>>>>
>>>>>> --
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Gil Portenseigne
Hi all,

I like the all or nothing (yet) proposal (thanks Taher btw :) ), since it offers a way to
communicate around this big change and a way to migrate existing
implementation. It's an optimum choice for this kind of refactoring, but it will need more effort to deliver it.

So now we'll need to gather opinions to know if there is people willing to contribute to
such a task.

Gil


Le dimanche 15 avril 2018 à 09:48:56 (+0200), Jacques Le Roux a écrit :

> I wonder, should it be really all or nothing? Will it not add more concerns
> and difficulties to deliver a such big package? Should we wait for that to
> happen, and how long?
>
> Jacques
>
>
> Le 15/04/2018 à 02:55, innate Genius a écrit :
> > +1 Taher
> >
> > > On 14-Apr-2018, at 12:40 PM, Taher Alkhateeb <[hidden email]> wrote:
> > >
> > > Hi Everyone,
> > >
> > > Thinking some more about the concerns from multiple people in this thread
> > > like Michael, Rajesh, Gil and others I have a different suggestion.
> > >
> > > Why not make a sweeping review of the full domain model, and then decide on
> > > one comprehensive change, with even a migration script that we can offer to
> > > users. That would be easier than randomly changing a few entities every
> > > once in a while.
> > >
> > > The domain model seems sensitive to many users and I understand that
> > > because everything builds on top of it. I heard enough objections to
> > > recommend postponing this task and coming up with something better as
> > > suggested above.
> > >
> > > On Sat, Apr 14, 2018, 9:56 AM Michael Brohl <[hidden email]>
> > > wrote:
> > >
> > > > Suraj,
> > > >
> > > > I still do not see much value in this change, compared to the effort
> > > > needed for development and testing as well as the migration the users
> > > > have to do.
> > > >
> > > > Please consider to not do this change.
> > > >
> > > > Thanks,
> > > >
> > > > Michael
> > > >
> > > >
> > > > Am 13.04.18 um 10:09 schrieb Suraj Khurana:
> > > > > Thanks everyone for your thoughts.
> > > > >
> > > > > One more point is we also manage Data Migration By release document so it
> > > > > will help existing uses. Such as https://cwiki.apache.org/confl
> > > > > uence/display/OFBIZ/Data+Migration+by+releases
> > > > > <
> > > > https://www.google.com/url?q=https://cwiki.apache.org/confluence/display/OFBIZ/Data%2BMigration%2Bby%2Breleases&sa=D&source=hangouts&ust=1523684384066000&usg=AFQjCNHrGuEkvs9NdHkf_MUX3tPFJfp2Wg
> > > > > Handling of deprecated entities is also properly defined at
> > > > >
> > > > https://cwiki.apache.org/confluence/display/OFBIZ/General+Entity+Overview,
> > > > > we can easily follow these steps.
> > > > >
> > > > > We will change entity name and its occurrence everywhere in code base,
> > > > > provide a data migration service which will be helpful for existing uses.
> > > > > Further on, thanks to Arun's suggestion, there will not be any confusion
> > > > > related to entity name as well.
> > > > >
> > > > > @Nicolas, Arun also suggested two names to avoid confusion, may be anyone
> > > > > of them makes more sense to you.
> > > > >
> > > > > --
> > > > > Thanks and Regards,
> > > > > *Suraj Khurana* | Sr. Enterprise Software Engineer
> > > > > HotWax Commerce  by  HotWax Systems
> > > > > Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010
> > > > > Cell phone: +91 96697-50002
> > > > >
> > > > > On Fri, Apr 13, 2018 at 1:22 PM, Nicolas Malin <[hidden email]
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > On 10/04/2018 13:24, Suraj Khurana wrote:
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > It's big modification with potential side-effect.
> > > > > > I suggest to move carefully and migrate entities one by one and not all
> > > > in
> > > > > > one :)
> > > > > >
> > > > > > For the renaming OrderItemShipGroupto OrderShipGroupit's ok but I'm
> > > > > > against OrderItemShipGroupAssoc to OrderItemShipGroup. As pragmatic
> > > > > > OrderItemShipGroupAssoc isn't perfect like you spotted but it's easily
> > > > > > understandable.
> > > > > >
> > > > > > Nicolas
> > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > >
> > > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Mathieu Lirzin
In reply to this post by Jacques Le Roux
Jacques Le Roux <[hidden email]> writes:

> Let me clarify my position. I'm not strictly against this change. I
> don't fear a such OOTB change, after all it's only name change, isn't
> ? And what you mentioned below Suraj is the right way to go. Obviously
> the concern is for custom projects.
>
> Though I'm not directly concerned (I have no current direct
> responsibilities on custom projects which could be impacted) I can
> foresee issues on custom projects even if we provide tests to cover
> the change as Rajesh rightly suggested. Because tests can't guarantee 
> to reveal issues in custom code, so people might overlook when
> migrating. We have no ideas of what users do in their project, it can
> be surprising sometimes. So I'd like to have more opinions and
> especially ideas of people concerned. I'm not sure we will get them in
> dev ML. So I think we should ask on user ML. Even if I guess all users
> are not reading all messages on user ML, at least we would have done
> our best.

It's free software so you never know who is going to be impacted, even
if you ask on a user ML.  :-)

IIUC the question is to know if changing an entity name is an acceptable
breaking change and how it should be handled.  Is there a way to
deprecate the old entity name, while introducing the new one?

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
Reply | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Jacques Le Roux
Administrator

Le 15/04/2018 à 14:30, Mathieu Lirzin a écrit :

> Jacques Le Roux <[hidden email]> writes:
>
>> Let me clarify my position. I'm not strictly against this change. I
>> don't fear a such OOTB change, after all it's only name change, isn't
>> ? And what you mentioned below Suraj is the right way to go. Obviously
>> the concern is for custom projects.
>>
>> Though I'm not directly concerned (I have no current direct
>> responsibilities on custom projects which could be impacted) I can
>> foresee issues on custom projects even if we provide tests to cover
>> the change as Rajesh rightly suggested. Because tests can't guarantee
>> to reveal issues in custom code, so people might overlook when
>> migrating. We have no ideas of what users do in their project, it can
>> be surprising sometimes. So I'd like to have more opinions and
>> especially ideas of people concerned. I'm not sure we will get them in
>> dev ML. So I think we should ask on user ML. Even if I guess all users
>> are not reading all messages on user ML, at least we would have done
>> our best.
> It's free software so you never know who is going to be impacted, even
> if you ask on a user ML.  :-)
>
> IIUC the question is to know if changing an entity name is an acceptable
> breaking change and how it should be handled.  Is there a way to
> deprecate the old entity name, while introducing the new one?
>
Yes of course this exists, OFBiz is a serious software ;)
https://cwiki.apache.org/confluence/display/OFBIZ/General+Entity+Overview#GeneralEntityOverview-DeprecatedEntities
There is a link from
https://cwiki.apache.org/confluence/display/OFBIZ/Revisions+Requiring+Data+Migration+-+upgrade+ofbiz

Actually it's now mostly about getting a (possibly lazy, obviously not in this case) consensus, and if really needed a vote
https://www.apache.org/foundation/voting.html
http://theapacheway.com/consensus/

Jacques

Reply | Threaded
Open this post in threaded view
|

RE: Confusing entity names

gareth.carter
In reply to this post by Rajesh Mallah
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:[hidden email]]
Sent: 12 April 2018 2:47 PM
To: [hidden email]
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 <[hidden email]>
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 | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Jacques Le Roux
Administrator
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

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:[hidden email]]
> Sent: 12 April 2018 2:47 PM
> To: [hidden email]
> 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 <[hidden email]>
> 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 | Threaded
Open this post in threaded view
|

RE: Confusing entity names

gareth.carter
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:[hidden email]]
Sent: 17 April 2018 11:21 AM
To: [hidden email]
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://markmail.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:[hidden email]]
> Sent: 12 April 2018 2:47 PM
> To: [hidden email]<mailto:[hidden email]>
> 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 <[hidden email]<mailto:[hidden email]>>
> 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 | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Jacques Le Roux
Administrator
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:[hidden email]]
> Sent: 17 April 2018 11:21 AM
> To: [hidden email]
> 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://markmail.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:[hidden email]]
>> Sent: 12 April 2018 2:47 PM
>> To: [hidden email]<mailto:[hidden email]>
>> 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 <[hidden email]<mailto:[hidden email]>>
>> 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 | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Suraj Khurana
Hello,

I think it will create more hassle, I would prefer renaming effort rather
introducing some change on entity engine and marking entity as deprecated.
After this, you need to remember two names referring a single entity and
one of them is not making sense (everyone agrees this point)

I already said that these entities are crucial part of OOTB data model
since inception, so most of us are fond of these names. But, actually its
confusing for someone who is not aware of it.
Change is the need of the hour, we should accept it. :)

--
Thanks and Regards,
*Suraj Khurana* | Sr. Enterprise Software Engineer
HotWax Commerce  by  HotWax Systems
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010


On Tue, Apr 17, 2018 at 5:26 PM, Jacques Le Roux <
[hidden email]> 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:[hidden email]]
>> Sent: 17 April 2018 11:21 AM
>> To: [hidden email]
>> 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:[hidden email]]
>>> Sent: 12 April 2018 2:47 PM
>>> To: [hidden email]<mailto:[hidden email]>
>>> 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 <[hidden email]
>>> <mailto:[hidden email]>>
>>> 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 | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Rajesh Mallah
In reply to this post by Jacques Le Roux
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 <
[hidden email]> 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:[hidden email]]
>> Sent: 17 April 2018 11:21 AM
>> To: [hidden email]
>> 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:[hidden email]]
>>> Sent: 12 April 2018 2:47 PM
>>> To: [hidden email]<mailto:[hidden email]>
>>> 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 <[hidden email]
>>> <mailto:[hidden email]>>
>>> 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 | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Jacques Le Roux
Administrator
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 <
> [hidden email]> 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:[hidden email]]
>>> Sent: 17 April 2018 11:21 AM
>>> To: [hidden email]
>>> 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:[hidden email]]
>>>> Sent: 12 April 2018 2:47 PM
>>>> To: [hidden email]<mailto:[hidden email]>
>>>> 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 <[hidden email]
>>>> <mailto:[hidden email]>>
>>>> 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 | Threaded
Open this post in threaded view
|

RE: Confusing entity names

gareth.carter
In reply to this post by Rajesh Mallah
It was an idea and maybe the development required outweighs the value to the project. Adding a deprecated flag may be useful but you have that with the existing process (prepend Old to entity name)

For such a small change, this can have a major impact for existing installations


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: Rajesh Mallah [mailto:[hidden email]]
Sent: 17 April 2018 3:29 PM
To: [hidden email]
Subject: Re: Confusing entity names

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 <
[hidden email]<mailto:[hidden email]>> 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+<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/stan150.jpg>]
>>
>>
>> [http://logos.stannah.co.uk/enviro.jpg<http://logos.stannah.co.uk/enviro.jpg>]Please consider the environment
>> before printing this email.
>>
>> From: Jacques Le Roux [mailto:[hidden email]]
>> Sent: 17 April 2018 11:21 AM
>> To: [hidden email]<mailto:[hidden email]>
>> 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://markmail.org/message/wypy4tuhyyv5bugw><https://markma
>> il.org/message/wypy4tuhyyv5bugw<http://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:[hidden email]]
>>> Sent: 12 April 2018 2:47 PM
>>> To: [hidden email]<mailto:[hidden email]<mailto:[hidden email]%3cmailto:[hidden email]>>
>>> 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 <[hidden email]
<mailto:[hidden email]%0b>>>> <mailto:[hidden email]>>

>>> 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 | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Scott Gray-3
In reply to this post by Suraj Khurana
Just to throw in my 2 cents, I don't think the naming is so confusing that
it warrants changing.  The number of replies in this thread highlights that
it isn't a straightforward thing to change, and personally I don't think
the names are so bad that it's worth any of the pain that might come from
changing them.

IMO "OrderShipGroup" could just as easily imply a group of orders that
should be shipped together as though they were a single order.  So to me,
"OrderItemShipGroup" does make some sense for the parent entity.

The child entity is a bit trickier, because "OrderItemShipGroupOrderItem"
is terrible so I guess that's why "Assoc" was chosen as the suffix.
"OrderItemShipGroupItem" could work but it's not much better than "Assoc".

Sometime's names aren't perfect, but they're usually close enough that it
doesn't matter very much.

Regards
Scott


On 10 April 2018 at 23:24, Suraj Khurana <[hidden email]>
wrote:

> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Rishi Solanki
+1 Scott.
I'm also not in favor of changing the names. Suraj suggested better names
but existing are also fine. Another point is OrderItemShipGrpInvRes have
relation with both the mentioned entities. Which tells by modeling that,
one OISG may have more than one OISGIR which may in turn have different
shipgroups. That means, one OISG having one order may be connected with
with single OISGIR or more than one OISGIR. And here item word makes sense
in the entity names.



Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Wed, Apr 18, 2018 at 1:20 PM, Scott Gray <[hidden email]>
wrote:

> Just to throw in my 2 cents, I don't think the naming is so confusing that
> it warrants changing.  The number of replies in this thread highlights that
> it isn't a straightforward thing to change, and personally I don't think
> the names are so bad that it's worth any of the pain that might come from
> changing them.
>
> IMO "OrderShipGroup" could just as easily imply a group of orders that
> should be shipped together as though they were a single order.  So to me,
> "OrderItemShipGroup" does make some sense for the parent entity.
>
> The child entity is a bit trickier, because "OrderItemShipGroupOrderItem"
> is terrible so I guess that's why "Assoc" was chosen as the suffix.
> "OrderItemShipGroupItem" could work but it's not much better than "Assoc".
>
> Sometime's names aren't perfect, but they're usually close enough that it
> doesn't matter very much.
>
> Regards
> Scott
>
>
> On 10 April 2018 at 23:24, Suraj Khurana <[hidden email]>
> wrote:
>
> > 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Confusing entity names

Suraj Khurana
Thanks everyone for all your inputs.
Seems that there is no common conclusion derived for this change.

I will hold/discard the ticket created for this soon.

--
Thanks and Regards,
*Suraj Khurana* | Sr. Enterprise Software Engineer
HotWax Commerce  by  HotWax Systems
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010

On Wed, Apr 18, 2018 at 3:52 PM, Rishi Solanki <[hidden email]>
wrote:

> +1 Scott.
> I'm also not in favor of changing the names. Suraj suggested better names
> but existing are also fine. Another point is OrderItemShipGrpInvRes have
> relation with both the mentioned entities. Which tells by modeling that,
> one OISG may have more than one OISGIR which may in turn have different
> shipgroups. That means, one OISG having one order may be connected with
> with single OISGIR or more than one OISGIR. And here item word makes sense
> in the entity names.
>
>
>
> Rishi Solanki
> Sr Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
> www.hotwax.co
>
> On Wed, Apr 18, 2018 at 1:20 PM, Scott Gray <[hidden email]>
> wrote:
>
> > Just to throw in my 2 cents, I don't think the naming is so confusing
> that
> > it warrants changing.  The number of replies in this thread highlights
> that
> > it isn't a straightforward thing to change, and personally I don't think
> > the names are so bad that it's worth any of the pain that might come from
> > changing them.
> >
> > IMO "OrderShipGroup" could just as easily imply a group of orders that
> > should be shipped together as though they were a single order.  So to me,
> > "OrderItemShipGroup" does make some sense for the parent entity.
> >
> > The child entity is a bit trickier, because "OrderItemShipGroupOrderItem"
> > is terrible so I guess that's why "Assoc" was chosen as the suffix.
> > "OrderItemShipGroupItem" could work but it's not much better than
> "Assoc".
> >
> > Sometime's names aren't perfect, but they're usually close enough that it
> > doesn't matter very much.
> >
> > Regards
> > Scott
> >
> >
> > On 10 April 2018 at 23:24, Suraj Khurana <suraj.khurana@hotwaxsystems.
> com>
> > wrote:
> >
> > > 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
> > >
> >
>
12