Entity and Service definition

[Rishi Solanki]

Dear Folks,

While working/reviewing recent work in community, I observed some
improvement/fixes required at entity and related service implementation.
For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
to create/update/delete. At the time of writing migration scripts I always
see lack of such services, which can be used to define new types or
attributes. Also Many entities have some other problems in basic design of
CRUD operations and in definitions;

On further look into this in detail found many such entities which do not
have services. I would like to propose a refactoring at basic design level
which covers following which does not impact on functionality we have;

1) Many entity definitions having relationships with view-entities, like
OrderHeader entity maintain relationship with OrderHeaderNoteView and
OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
at view-entities level if required. Also change the code where this
relation is in use.
2) Many entities having service implementation exists but they can be
simply convert into entity-auto, that means can use the power OFBiz
provides.
3) As mentioned initially many entities do not have CRUD services exists,
we should implement or use entity-auto for them wherever applicable. Also
remove direct use of delegator for them.
4) Many entities having from date and thru date, Or status Or Enumeration
to manage the historical data, but services actually remove those entity
data. We should change the service implementation to maintain the
historical data.

After this effort, OFBiz will have minimum direct use of delegator,
enriched use of service engine, we would be able to established
patterns/best practice to introduce a new entities, and writing new
services.

I would love to hear more improvements in this area from community. We will
add them in this effort only.


Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

[taher]

Hi Rishi,

Great Ideas, +1 for all suggestions.

I only have one warning because this happened in the past: Do not switch
from Services to entity-auto without being 100% sure this is the right
thing to do. Sometimes you miss important logic that breaks things
elsewhere.

Thank you for the initiative, I love this enthusiasm and energy :)

Cheers!

Taher Alkhateeb

On Tue, Jul 12, 2016 at 11:31 AM, Rishi Solanki <[hidden email]>
wrote:

> Dear Folks,
>
> While working/reviewing recent work in community, I observed some
> improvement/fixes required at entity and related service implementation.
> For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
> to create/update/delete. At the time of writing migration scripts I always
> see lack of such services, which can be used to define new types or
> attributes. Also Many entities have some other problems in basic design of
> CRUD operations and in definitions;
>
> On further look into this in detail found many such entities which do not
> have services. I would like to propose a refactoring at basic design level
> which covers following which does not impact on functionality we have;
>
> 1) Many entity definitions having relationships with view-entities, like
> OrderHeader entity maintain relationship with OrderHeaderNoteView and
> OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
> at view-entities level if required. Also change the code where this
> relation is in use.
> 2) Many entities having service implementation exists but they can be
> simply convert into entity-auto, that means can use the power OFBiz
> provides.
> 3) As mentioned initially many entities do not have CRUD services exists,
> we should implement or use entity-auto for them wherever applicable. Also
> remove direct use of delegator for them.
> 4) Many entities having from date and thru date, Or status Or Enumeration
> to manage the historical data, but services actually remove those entity
> data. We should change the service implementation to maintain the
> historical data.
>
> After this effort, OFBiz will have minimum direct use of delegator,
> enriched use of service engine, we would be able to established
> patterns/best practice to introduce a new entities, and writing new
> services.
>
> I would love to hear more improvements in this area from community. We will
> add them in this effort only.
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>

[Rishi Solanki]

Thank you Taher, and yes I had the same concern for it, even when we are
working on enforcing noninstantiability, but we will be able to achieve
zero regression till now by doing internal multi-level QA.

Thanks for pointing this, we will ensure before proceeding for any changes.
:)

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Tue, Jul 12, 2016 at 2:13 PM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Rishi,
>
> Great Ideas, +1 for all suggestions.
>
> I only have one warning because this happened in the past: Do not switch
> from Services to entity-auto without being 100% sure this is the right
> thing to do. Sometimes you miss important logic that breaks things
> elsewhere.
>
> Thank you for the initiative, I love this enthusiasm and energy :)
>
> Cheers!
>
> Taher Alkhateeb
>
> On Tue, Jul 12, 2016 at 11:31 AM, Rishi Solanki <[hidden email]>
> wrote:
>
> > Dear Folks,
> >
> > While working/reviewing recent work in community, I observed some
> > improvement/fixes required at entity and related service implementation.
> > For few entities like InvoiceAttribute, InvoiceType, etc. no service
> exists
> > to create/update/delete. At the time of writing migration scripts I
> always
> > see lack of such services, which can be used to define new types or
> > attributes. Also Many entities have some other problems in basic design
> of
> > CRUD operations and in definitions;
> >
> > On further look into this in detail found many such entities which do not
> > have services. I would like to propose a refactoring at basic design
> level
> > which covers following which does not impact on functionality we have;
> >
> > 1) Many entity definitions having relationships with view-entities, like
> > OrderHeader entity maintain relationship with OrderHeaderNoteView and
> > OrderItemAndShipGroupAssoc. We should remove it, maintain the
> relationship
> > at view-entities level if required. Also change the code where this
> > relation is in use.
> > 2) Many entities having service implementation exists but they can be
> > simply convert into entity-auto, that means can use the power OFBiz
> > provides.
> > 3) As mentioned initially many entities do not have CRUD services exists,
> > we should implement or use entity-auto for them wherever applicable. Also
> > remove direct use of delegator for them.
> > 4) Many entities having from date and thru date, Or status Or Enumeration
> > to manage the historical data, but services actually remove those entity
> > data. We should change the service implementation to maintain the
> > historical data.
> >
> > After this effort, OFBiz will have minimum direct use of delegator,
> > enriched use of service engine, we would be able to established
> > patterns/best practice to introduce a new entities, and writing new
> > services.
> >
> > I would love to hear more improvements in this area from community. We
> will
> > add them in this effort only.
> >
> >
> > Rishi Solanki
> > Manager, Enterprise Software Development
> > HotWax Systems Pvt. Ltd.
> > Direct: [phone]
> > http://www.hotwaxsystems.com
> >
>

[Swapnil Mane]

+1 for all suggestions, seems good improvements to me :-)

- Best Regards,
Swapnil M Mane
H <http://www.hotwaxsystems.com/>otWax Systems
<http://www.hotwaxsystems.com/> - *The global leader in innovative
enterprise commerce s**olutions **powered by Apache OFBiz.*
ApacheCon US 2015 Silver Sponsor
<http://events.linuxfoundation.org/events/archive/2015/apachecon-north-america>


On Tue, Jul 12, 2016 at 2:01 PM, Rishi Solanki <[hidden email]>
wrote:

> Dear Folks,
>
> While working/reviewing recent work in community, I observed some
> improvement/fixes required at entity and related service implementation.
> For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
> to create/update/delete. At the time of writing migration scripts I always
> see lack of such services, which can be used to define new types or
> attributes. Also Many entities have some other problems in basic design of
> CRUD operations and in definitions;
>
> On further look into this in detail found many such entities which do not
> have services. I would like to propose a refactoring at basic design level
> which covers following which does not impact on functionality we have;
>
> 1) Many entity definitions having relationships with view-entities, like
> OrderHeader entity maintain relationship with OrderHeaderNoteView and
> OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
> at view-entities level if required. Also change the code where this
> relation is in use.
> 2) Many entities having service implementation exists but they can be
> simply convert into entity-auto, that means can use the power OFBiz
> provides.
> 3) As mentioned initially many entities do not have CRUD services exists,
> we should implement or use entity-auto for them wherever applicable. Also
> remove direct use of delegator for them.
> 4) Many entities having from date and thru date, Or status Or Enumeration
> to manage the historical data, but services actually remove those entity
> data. We should change the service implementation to maintain the
> historical data.
>
> After this effort, OFBiz will have minimum direct use of delegator,
> enriched use of service engine, we would be able to established
> patterns/best practice to introduce a new entities, and writing new
> services.
>
> I would love to hear more improvements in this area from community. We will
> add them in this effort only.
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>

[Nicolas Malin-2]

Hi Rishi,

:) I totaly agree with your remarks

In line

Le 12/07/2016 10:31, Rishi Solanki a écrit :

> Dear Folks,
>
> While working/reviewing recent work in community, I observed some
> improvement/fixes required at entity and related service implementation.
> For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
> to create/update/delete. At the time of writing migration scripts I always
> see lack of such services, which can be used to define new types or
> attributes. Also Many entities have some other problems in basic design of
> CRUD operations and in definitions;
>
> On further look into this in detail found many such entities which do not
> have services. I would like to propose a refactoring at basic design level
> which covers following which does not impact on functionality we have;
>
> 1) Many entity definitions having relationships with view-entities, like
> OrderHeader entity maintain relationship with OrderHeaderNoteView and
> OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
> at view-entities level if required. Also change the code where this
> relation is in use.

Agree
> 2) Many entities having service implementation exists but they can be
> simply convert into entity-auto, that means can use the power OFBiz
> provides.
I has been started this work from 2 years :) , and currently I have
stopped by Shipment Entities with a premission service refactoring
https://issues.apache.org/jira/browse/OFBIZ-7113 and
https://issues.apache.org/jira/browse/OFBIZ-6996

I'm sure we can found some other service to convert ;)
> 3) As mentioned initially many entities do not have CRUD services exists,
> we should implement or use entity-auto for them wherever applicable. Also
> remove direct use of delegator for them.
After the migration, I would be move all generic service crud on the
data model component to detect what missing service and list the reason
> 4) Many entities having from date and thru date, Or status Or Enumeration
> to manage the historical data, but services actually remove those entity
> data. We should change the service implementation to maintain the
> historical data.
++++1, I created the action expire on entity-auto to manage that ;)
>
> After this effort, OFBiz will have minimum direct use of delegator,
> enriched use of service engine, we would be able to established
> patterns/best practice to introduce a new entities, and writing new
> services.
I appreciate your message :) it's pretty good to read that

>
> I would love to hear more improvements in this area from community. We will
> add them in this effort only.
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>

[Jacques Le Roux]

+1

Jacques


Le 12/07/2016 à 14:02, Nicolas Malin a écrit :

> Hi Rishi,
>
> :) I totaly agree with your remarks
>
> In line
>
> Le 12/07/2016 10:31, Rishi Solanki a écrit :
>> Dear Folks,
>>
>> While working/reviewing recent work in community, I observed some
>> improvement/fixes required at entity and related service implementation.
>> For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
>> to create/update/delete. At the time of writing migration scripts I always
>> see lack of such services, which can be used to define new types or
>> attributes. Also Many entities have some other problems in basic design of
>> CRUD operations and in definitions;
>>
>> On further look into this in detail found many such entities which do not
>> have services. I would like to propose a refactoring at basic design level
>> which covers following which does not impact on functionality we have;
>>
>> 1) Many entity definitions having relationships with view-entities, like
>> OrderHeader entity maintain relationship with OrderHeaderNoteView and
>> OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
>> at view-entities level if required. Also change the code where this
>> relation is in use.
> Agree
>> 2) Many entities having service implementation exists but they can be
>> simply convert into entity-auto, that means can use the power OFBiz
>> provides.
> I has been started this work from 2 years :) , and currently I have stopped by Shipment Entities with a premission service refactoring
> https://issues.apache.org/jira/browse/OFBIZ-7113 and https://issues.apache.org/jira/browse/OFBIZ-6996
>
> I'm sure we can found some other service to convert ;)
>> 3) As mentioned initially many entities do not have CRUD services exists,
>> we should implement or use entity-auto for them wherever applicable. Also
>> remove direct use of delegator for them.
> After the migration, I would be move all generic service crud on the data model component to detect what missing service and list the reason
>> 4) Many entities having from date and thru date, Or status Or Enumeration
>> to manage the historical data, but services actually remove those entity
>> data. We should change the service implementation to maintain the
>> historical data.
> ++++1, I created the action expire on entity-auto to manage that ;)
>>
>> After this effort, OFBiz will have minimum direct use of delegator,
>> enriched use of service engine, we would be able to established
>> patterns/best practice to introduce a new entities, and writing new
>> services.
> I appreciate your message :) it's pretty good to read that
>>
>> I would love to hear more improvements in this area from community. We will
>> add them in this effort only.
>>
>>
>> Rishi Solanki
>> Manager, Enterprise Software Development
>> HotWax Systems Pvt. Ltd.
>> Direct: [phone]
>> http://www.hotwaxsystems.com
>>
>
>

[Deepak Dixit-3]

+1

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Wed, Jul 13, 2016 at 11:19 AM, Jacques Le Roux <
[hidden email]> wrote:

> +1
>
> Jacques
>
>
>
> Le 12/07/2016 à 14:02, Nicolas Malin a écrit :
>
>> Hi Rishi,
>>
>> :) I totaly agree with your remarks
>>
>> In line
>>
>> Le 12/07/2016 10:31, Rishi Solanki a écrit :
>>
>>> Dear Folks,
>>>
>>> While working/reviewing recent work in community, I observed some
>>> improvement/fixes required at entity and related service implementation.
>>> For few entities like InvoiceAttribute, InvoiceType, etc. no service
>>> exists
>>> to create/update/delete. At the time of writing migration scripts I
>>> always
>>> see lack of such services, which can be used to define new types or
>>> attributes. Also Many entities have some other problems in basic design
>>> of
>>> CRUD operations and in definitions;
>>>
>>> On further look into this in detail found many such entities which do not
>>> have services. I would like to propose a refactoring at basic design
>>> level
>>> which covers following which does not impact on functionality we have;
>>>
>>> 1) Many entity definitions having relationships with view-entities, like
>>> OrderHeader entity maintain relationship with OrderHeaderNoteView and
>>> OrderItemAndShipGroupAssoc. We should remove it, maintain the
>>> relationship
>>> at view-entities level if required. Also change the code where this
>>> relation is in use.
>>>
>> Agree
>>
>>> 2) Many entities having service implementation exists but they can be
>>> simply convert into entity-auto, that means can use the power OFBiz
>>> provides.
>>>
>> I has been started this work from 2 years :) , and currently I have
>> stopped by Shipment Entities with a premission service refactoring
>> https://issues.apache.org/jira/browse/OFBIZ-7113 and
>> https://issues.apache.org/jira/browse/OFBIZ-6996
>>
>> I'm sure we can found some other service to convert ;)
>>
>>> 3) As mentioned initially many entities do not have CRUD services exists,
>>> we should implement or use entity-auto for them wherever applicable. Also
>>> remove direct use of delegator for them.
>>>
>> After the migration, I would be move all generic service crud on the data
>> model component to detect what missing service and list the reason
>>
>>> 4) Many entities having from date and thru date, Or status Or Enumeration
>>> to manage the historical data, but services actually remove those entity
>>> data. We should change the service implementation to maintain the
>>> historical data.
>>>
>> ++++1, I created the action expire on entity-auto to manage that ;)
>>
>>>
>>> After this effort, OFBiz will have minimum direct use of delegator,
>>> enriched use of service engine, we would be able to established
>>> patterns/best practice to introduce a new entities, and writing new
>>> services.
>>>
>> I appreciate your message :) it's pretty good to read that
>>
>>>
>>> I would love to hear more improvements in this area from community. We
>>> will
>>> add them in this effort only.
>>>
>>>
>>> Rishi Solanki
>>> Manager, Enterprise Software Development
>>> HotWax Systems Pvt. Ltd.
>>> Direct: [phone]
>>> http://www.hotwaxsystems.com
>>>
>>>
>>
>>
>

[Amardeep Singh Jhajj-2]

+1

Thanks & Regards
--
Amardeep Singh Jhajj

On Tue, Jul 12, 2016 at 2:01 PM, Rishi Solanki <[hidden email]>
wrote:

> Dear Folks,
>
> While working/reviewing recent work in community, I observed some
> improvement/fixes required at entity and related service implementation.
> For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
> to create/update/delete. At the time of writing migration scripts I always
> see lack of such services, which can be used to define new types or
> attributes. Also Many entities have some other problems in basic design of
> CRUD operations and in definitions;
>
> On further look into this in detail found many such entities which do not
> have services. I would like to propose a refactoring at basic design level
> which covers following which does not impact on functionality we have;
>
> 1) Many entity definitions having relationships with view-entities, like
> OrderHeader entity maintain relationship with OrderHeaderNoteView and
> OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
> at view-entities level if required. Also change the code where this
> relation is in use.
> 2) Many entities having service implementation exists but they can be
> simply convert into entity-auto, that means can use the power OFBiz
> provides.
> 3) As mentioned initially many entities do not have CRUD services exists,
> we should implement or use entity-auto for them wherever applicable. Also
> remove direct use of delegator for them.
> 4) Many entities having from date and thru date, Or status Or Enumeration
> to manage the historical data, but services actually remove those entity
> data. We should change the service implementation to maintain the
> historical data.
>
> After this effort, OFBiz will have minimum direct use of delegator,
> enriched use of service engine, we would be able to established
> patterns/best practice to introduce a new entities, and writing new
> services.
>
> I would love to hear more improvements in this area from community. We will
> add them in this effort only.
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>

[Pierre Smits]

I am all for improving the code base towards more consistency.

Having service definitions for CRUD functions for all entities, but the
view entities, is part of that. And it opens the opportunity to get a
potential future where OFBiz is opened up - in a relative easy way - to the
external environments via REST over HTTP microservices and what not.

I also concur with the posting done earlier by Taher: be careful when
migrating services to engine="entity-auto", as the devil is always in the
details.

At this moment in time, I can't fathom how much effort is involved in this
factoring, but I suggest to break it down as much as possible into separate
JIRA issues. For instance, the rework on the removal of the OrderHeaderNoteView
and OrderItemAndShipGroupAssoc from the OrderHeader entity can be a
separate issue. Please be aware, that this might have a big impact in
various functions/services/etc.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Jul 13, 2016 at 8:55 AM, Deepak Dixit <
[hidden email]> wrote:

> +1
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
>
> On Wed, Jul 13, 2016 at 11:19 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > +1
> >
> > Jacques
> >
> >
> >
> > Le 12/07/2016 à 14:02, Nicolas Malin a écrit :
> >
> >> Hi Rishi,
> >>
> >> :) I totaly agree with your remarks
> >>
> >> In line
> >>
> >> Le 12/07/2016 10:31, Rishi Solanki a écrit :
> >>
> >>> Dear Folks,
> >>>
> >>> While working/reviewing recent work in community, I observed some
> >>> improvement/fixes required at entity and related service
> implementation.
> >>> For few entities like InvoiceAttribute, InvoiceType, etc. no service
> >>> exists
> >>> to create/update/delete. At the time of writing migration scripts I
> >>> always
> >>> see lack of such services, which can be used to define new types or
> >>> attributes. Also Many entities have some other problems in basic design
> >>> of
> >>> CRUD operations and in definitions;
> >>>
> >>> On further look into this in detail found many such entities which do
> not
> >>> have services. I would like to propose a refactoring at basic design
> >>> level
> >>> which covers following which does not impact on functionality we have;
> >>>
> >>> 1) Many entity definitions having relationships with view-entities,
> like
> >>> OrderHeader entity maintain relationship with OrderHeaderNoteView and
> >>> OrderItemAndShipGroupAssoc. We should remove it, maintain the
> >>> relationship
> >>> at view-entities level if required. Also change the code where this
> >>> relation is in use.
> >>>
> >> Agree
> >>
> >>> 2) Many entities having service implementation exists but they can be
> >>> simply convert into entity-auto, that means can use the power OFBiz
> >>> provides.
> >>>
> >> I has been started this work from 2 years :) , and currently I have
> >> stopped by Shipment Entities with a premission service refactoring
> >> https://issues.apache.org/jira/browse/OFBIZ-7113 and
> >> https://issues.apache.org/jira/browse/OFBIZ-6996
> >>
> >> I'm sure we can found some other service to convert ;)
> >>
> >>> 3) As mentioned initially many entities do not have CRUD services
> exists,
> >>> we should implement or use entity-auto for them wherever applicable.
> Also
> >>> remove direct use of delegator for them.
> >>>
> >> After the migration, I would be move all generic service crud on the
> data
> >> model component to detect what missing service and list the reason
> >>
> >>> 4) Many entities having from date and thru date, Or status Or
> Enumeration
> >>> to manage the historical data, but services actually remove those
> entity
> >>> data. We should change the service implementation to maintain the
> >>> historical data.
> >>>
> >> ++++1, I created the action expire on entity-auto to manage that ;)
> >>
> >>>
> >>> After this effort, OFBiz will have minimum direct use of delegator,
> >>> enriched use of service engine, we would be able to established
> >>> patterns/best practice to introduce a new entities, and writing new
> >>> services.
> >>>
> >> I appreciate your message :) it's pretty good to read that
> >>
> >>>
> >>> I would love to hear more improvements in this area from community. We
> >>> will
> >>> add them in this effort only.
> >>>
> >>>
> >>> Rishi Solanki
> >>> Manager, Enterprise Software Development
> >>> HotWax Systems Pvt. Ltd.
> >>> Direct: [phone]
> >>> http://www.hotwaxsystems.com
> >>>
> >>>
> >>
> >>
> >
>

[Arun Patidar-2]

+1 for all suggestions.

Thanks & Regards
---
Arun Patidar
Manager, Enterprise Software Development
HotWax Systems
www.hotwaxsystems.com

On Tuesday 12 July 2016 02:01 PM, Rishi Solanki wrote:

> Dear Folks,
>
> While working/reviewing recent work in community, I observed some
> improvement/fixes required at entity and related service implementation.
> For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
> to create/update/delete. At the time of writing migration scripts I always
> see lack of such services, which can be used to define new types or
> attributes. Also Many entities have some other problems in basic design of
> CRUD operations and in definitions;
>
> On further look into this in detail found many such entities which do not
> have services. I would like to propose a refactoring at basic design level
> which covers following which does not impact on functionality we have;
>
> 1) Many entity definitions having relationships with view-entities, like
> OrderHeader entity maintain relationship with OrderHeaderNoteView and
> OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
> at view-entities level if required. Also change the code where this
> relation is in use.
> 2) Many entities having service implementation exists but they can be
> simply convert into entity-auto, that means can use the power OFBiz
> provides.
> 3) As mentioned initially many entities do not have CRUD services exists,
> we should implement or use entity-auto for them wherever applicable. Also
> remove direct use of delegator for them.
> 4) Many entities having from date and thru date, Or status Or Enumeration
> to manage the historical data, but services actually remove those entity
> data. We should change the service implementation to maintain the
> historical data.
>
> After this effort, OFBiz will have minimum direct use of delegator,
> enriched use of service engine, we would be able to established
> patterns/best practice to introduce a new entities, and writing new
> services.
>
> I would love to hear more improvements in this area from community. We will
> add them in this effort only.
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>

[Pranay Pandey-3]

+1

Thanks for posting idea in detail.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Tue, Jul 12, 2016 at 2:01 PM, Rishi Solanki <[hidden email]>
wrote:

> Dear Folks,
>
> While working/reviewing recent work in community, I observed some
> improvement/fixes required at entity and related service implementation.
> For few entities like InvoiceAttribute, InvoiceType, etc. no service exists
> to create/update/delete. At the time of writing migration scripts I always
> see lack of such services, which can be used to define new types or
> attributes. Also Many entities have some other problems in basic design of
> CRUD operations and in definitions;
>
> On further look into this in detail found many such entities which do not
> have services. I would like to propose a refactoring at basic design level
> which covers following which does not impact on functionality we have;
>
> 1) Many entity definitions having relationships with view-entities, like
> OrderHeader entity maintain relationship with OrderHeaderNoteView and
> OrderItemAndShipGroupAssoc. We should remove it, maintain the relationship
> at view-entities level if required. Also change the code where this
> relation is in use.
> 2) Many entities having service implementation exists but they can be
> simply convert into entity-auto, that means can use the power OFBiz
> provides.
> 3) As mentioned initially many entities do not have CRUD services exists,
> we should implement or use entity-auto for them wherever applicable. Also
> remove direct use of delegator for them.
> 4) Many entities having from date and thru date, Or status Or Enumeration
> to manage the historical data, but services actually remove those entity
> data. We should change the service implementation to maintain the
> historical data.
>
> After this effort, OFBiz will have minimum direct use of delegator,
> enriched use of service engine, we would be able to established
> patterns/best practice to introduce a new entities, and writing new
> services.
>
> I would love to hear more improvements in this area from community. We will
> add them in this effort only.
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>

[Jacques Le Roux]

Le 13/07/2016 à 09:39, Pierre Smits a écrit :

> At this moment in time, I can't fathom how much effort is involved in this
> factoring, but I suggest to break it down as much as possible into separate
> JIRA issues. For instance, the rework on the removal of the OrderHeaderNoteView
> and OrderItemAndShipGroupAssoc from the OrderHeader entity can be a
> separate issue. Please be aware, that this might have a big impact in
> various functions/services/etc.
>
> Best regards,
>
> Pierre Smits

That's a good advice Pierre, from what I have seen these last months from the HW effort, I'm confident they are totally aware of what to do :)

Jacques

[Rishi Solanki]

Thank you everyone for your approval and suggestion. We would try to follow
most, and log Jira accordingly. Soon will start on this.

Nicolas, thanks for pointing expire action on entity-auto.

Jacques, Pierre, thanks for suggestion on managing Jira tickets, and you
guys anyways helped us in our last effort in managing Jira tickets and
review. Thanks for that.

Plan is something like this, we would pick the easy entities first where we
found minimum changes. After delivering few we will be able to establish
practice internally, on what items we should take care before fixing an
entity/service. We would like to go slow initially, and as soon as we start
on it delivery process will more clear.


Thanks again for your help, and looking forward for same in the big effort
planned.



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Wed, Jul 13, 2016 at 2:36 PM, Jacques Le Roux <
[hidden email]> wrote:

> Le 13/07/2016 à 09:39, Pierre Smits a écrit :
>
>> At this moment in time, I can't fathom how much effort is involved in this
>> factoring, but I suggest to break it down as much as possible into
>> separate
>> JIRA issues. For instance, the rework on the removal of the
>> OrderHeaderNoteView
>> and OrderItemAndShipGroupAssoc from the OrderHeader entity can be a
>> separate issue. Please be aware, that this might have a big impact in
>> various functions/services/etc.
>>
>> Best regards,
>>
>> Pierre Smits
>>
> That's a good advice Pierre, from what I have seen these last months from
> the HW effort, I'm confident they are totally aware of what to do :)
>
> Jacques
>
>

[Rishi Solanki]

Starter effort on this under - OFBIZ-7828. Community review / feedback /
suggestion / concerns are welcome.

Thanks!

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Thu, Jul 14, 2016 at 9:58 AM, Rishi Solanki <[hidden email]>
wrote:

> Thank you everyone for your approval and suggestion. We would try to
> follow most, and log Jira accordingly. Soon will start on this.
>
> Nicolas, thanks for pointing expire action on entity-auto.
>
> Jacques, Pierre, thanks for suggestion on managing Jira tickets, and you
> guys anyways helped us in our last effort in managing Jira tickets and
> review. Thanks for that.
>
> Plan is something like this, we would pick the easy entities first where
> we found minimum changes. After delivering few we will be able to establish
> practice internally, on what items we should take care before fixing an
> entity/service. We would like to go slow initially, and as soon as we start
> on it delivery process will more clear.
>
>
> Thanks again for your help, and looking forward for same in the big effort
> planned.
>
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>
> On Wed, Jul 13, 2016 at 2:36 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 13/07/2016 à 09:39, Pierre Smits a écrit :
>>
>>> At this moment in time, I can't fathom how much effort is involved in
>>> this
>>> factoring, but I suggest to break it down as much as possible into
>>> separate
>>> JIRA issues. For instance, the rework on the removal of the
>>> OrderHeaderNoteView
>>> and OrderItemAndShipGroupAssoc from the OrderHeader entity can be a
>>> separate issue. Please be aware, that this might have a big impact in
>>> various functions/services/etc.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>> That's a good advice Pierre, from what I have seen these last months from
>> the HW effort, I'm confident they are totally aware of what to do :)
>>
>> Jacques
>>
>>
>

[Divesh Dutta-2]

Very good initiative.

Thanks
--
Divesh Dutta .

On Sun, Jul 17, 2016 at 6:00 PM, Rishi Solanki <[hidden email]>
wrote:

> Starter effort on this under - OFBIZ-7828. Community review / feedback /
> suggestion / concerns are welcome.
>
> Thanks!
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: [phone]
> http://www.hotwaxsystems.com
>
> On Thu, Jul 14, 2016 at 9:58 AM, Rishi Solanki <[hidden email]>
> wrote:
>
> > Thank you everyone for your approval and suggestion. We would try to
> > follow most, and log Jira accordingly. Soon will start on this.
> >
> > Nicolas, thanks for pointing expire action on entity-auto.
> >
> > Jacques, Pierre, thanks for suggestion on managing Jira tickets, and you
> > guys anyways helped us in our last effort in managing Jira tickets and
> > review. Thanks for that.
> >
> > Plan is something like this, we would pick the easy entities first where
> > we found minimum changes. After delivering few we will be able to
> establish
> > practice internally, on what items we should take care before fixing an
> > entity/service. We would like to go slow initially, and as soon as we
> start
> > on it delivery process will more clear.
> >
> >
> > Thanks again for your help, and looking forward for same in the big
> effort
> > planned.
> >
> >
> >
> > Rishi Solanki
> > Manager, Enterprise Software Development
> > HotWax Systems Pvt. Ltd.
> > Direct: [phone]
> > http://www.hotwaxsystems.com
> >
> > On Wed, Jul 13, 2016 at 2:36 PM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> Le 13/07/2016 à 09:39, Pierre Smits a écrit :
> >>
> >>> At this moment in time, I can't fathom how much effort is involved in
> >>> this
> >>> factoring, but I suggest to break it down as much as possible into
> >>> separate
> >>> JIRA issues. For instance, the rework on the removal of the
> >>> OrderHeaderNoteView
> >>> and OrderItemAndShipGroupAssoc from the OrderHeader entity can be a
> >>> separate issue. Please be aware, that this might have a big impact in
> >>> various functions/services/etc.
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >> That's a good advice Pierre, from what I have seen these last months
> from
> >> the HW effort, I'm confident they are totally aware of what to do :)
> >>
> >> Jacques
> >>
> >>
> >
>