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 <slidingfilame...@gmail.com> 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 <michael.br...@ecomify.de>
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 <nicolas.ma...@nereide.fr

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 via email to