updatePostalAddress, updateTelecomNumber (contactMechs) missnamed ?

[Gil Portenseigne]

Hello,

While working on a new contactMech type (no spoiler yet, that will come
in some days ;)), I wanted to develop the CRUD services , and stumbled
upon something that bother me.

Actually, when we update a contactMech in OFBiz, the service keep
history of it, to keep reference for related entity (like
communicationEvent and such). Thanks to that, old communication
event/invoice/etc. refer to the old contact mechanism.

That's fine with me, but what is bothering me is that
updatePostalAddress (and others) service is named like every auto-entity
CRUD services within OFBiz, that could be misleading for newcomers

I feel like we have to change the naming of these services. No good idea
yet about a new name... Am I the only one wondering about that ? Is that
fine to keep "udpate" in this context ?

WDYT ?

Gil


--
logoNrd <http://nereide.fr/>
        Gil PORTENSEIGNE
Intégrateur Apache-OFBiz, ERP en logiciel Libre
[hidden email]
8 rue des Déportés 37000 TOURS
02 47 50 30 54

| Réseau Libre Entreprise <http://www.libre-entreprise.org/>

[taher]

perhaps updatePostalAddressWithHistory

On Fri, Feb 23, 2018 at 5:41 PM, gil portenseigne
<[hidden email]> wrote:

> Hello,
>
> While working on a new contactMech type (no spoiler yet, that will come in
> some days ;)), I wanted to develop the CRUD services , and stumbled upon
> something that bother me.
>
> Actually, when we update a contactMech in OFBiz, the service keep history of
> it, to keep reference for related entity (like communicationEvent and such).
> Thanks to that, old communication event/invoice/etc. refer to the old
> contact mechanism.
>
> That's fine with me, but what is bothering me is that updatePostalAddress
> (and others) service is named like every auto-entity CRUD services within
> OFBiz, that could be misleading for newcomers
>
> I feel like we have to change the naming of these services. No good idea yet
> about a new name... Am I the only one wondering about that ? Is that fine to
> keep "udpate" in this context ?
>
> WDYT ?
>
> Gil
>
>
> --
> logoNrd <http://nereide.fr/>
>         Gil PORTENSEIGNE
> Intégrateur Apache-OFBiz, ERP en logiciel Libre
> [hidden email]
> 8 rue des Déportés 37000 TOURS
> 02 47 50 30 54
>
> | Réseau Libre Entreprise <http://www.libre-entreprise.org/>
>

[pierre.gaudin]

Hi Gil,

Personally, I understand your point of view, but renaming service could
have major impact to existing code...
May be we could add a parameter to keep or leave history.

regards

Pierre
On 23/02/2018 15:56, Taher Alkhateeb wrote:

> perhaps updatePostalAddressWithHistory
>
> On Fri, Feb 23, 2018 at 5:41 PM, gil portenseigne
> <[hidden email]> wrote:
>> Hello,
>>
>> While working on a new contactMech type (no spoiler yet, that will come in
>> some days ;)), I wanted to develop the CRUD services , and stumbled upon
>> something that bother me.
>>
>> Actually, when we update a contactMech in OFBiz, the service keep history of
>> it, to keep reference for related entity (like communicationEvent and such).
>> Thanks to that, old communication event/invoice/etc. refer to the old
>> contact mechanism.
>>
>> That's fine with me, but what is bothering me is that updatePostalAddress
>> (and others) service is named like every auto-entity CRUD services within
>> OFBiz, that could be misleading for newcomers
>>
>> I feel like we have to change the naming of these services. No good idea yet
>> about a new name... Am I the only one wondering about that ? Is that fine to
>> keep "udpate" in this context ?
>>
>> WDYT ?
>>
>> Gil
>>
>>
>> --
>> logoNrd <http://nereide.fr/>
>>          Gil PORTENSEIGNE
>> Intégrateur Apache-OFBiz, ERP en logiciel Libre
>> [hidden email]
>> 8 rue des Déportés 37000 TOURS
>> 02 47 50 30 54
>>
>> | Réseau Libre Entreprise <http://www.libre-entreprise.org/>
>>

[Deepak Dixit-3]

Yes it may confuse but I think its correct, the basic rule is if you want
to update postal address (ContactMech) it will expire old one and create
new one with update. So Ideally PostalAddress is an immutable object where
you can;t do modification in it.

if you want to update you need to clone it and do update.

I think we can add this in entity auto engine so that it will be part of
entity auto framework.

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

On Fri, Feb 23, 2018 at 8:11 PM, gil portenseigne <
[hidden email]> wrote:

> Hello,
>
> While working on a new contactMech type (no spoiler yet, that will come in
> some days ;)), I wanted to develop the CRUD services , and stumbled upon
> something that bother me.
>
> Actually, when we update a contactMech in OFBiz, the service keep history
> of it, to keep reference for related entity (like communicationEvent and
> such). Thanks to that, old communication event/invoice/etc. refer to the
> old contact mechanism.
>
> That's fine with me, but what is bothering me is that updatePostalAddress
> (and others) service is named like every auto-entity CRUD services within
> OFBiz, that could be misleading for newcomers
>
> I feel like we have to change the naming of these services. No good idea
> yet about a new name... Am I the only one wondering about that ? Is that
> fine to keep "udpate" in this context ?
>
> WDYT ?
>
> Gil
>
>
> --
> logoNrd <http://nereide.fr/>
>         Gil PORTENSEIGNE
> Intégrateur Apache-OFBiz, ERP en logiciel Libre
> [hidden email]
> 8 rue des Déportés 37000 TOURS
> 02 47 50 30 54
>
> | Réseau Libre Entreprise <http://www.libre-entreprise.org/>
>
>

[Rishi Solanki]

+1 Deepak!!

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

On Sat, Feb 24, 2018 at 11:44 AM, Deepak Dixit <
[hidden email]> wrote:

> Yes it may confuse but I think its correct, the basic rule is if you want
> to update postal address (ContactMech) it will expire old one and create
> new one with update. So Ideally PostalAddress is an immutable object where
> you can;t do modification in it.
>
> if you want to update you need to clone it and do update.
>
> I think we can add this in entity auto engine so that it will be part of
> entity auto framework.
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Fri, Feb 23, 2018 at 8:11 PM, gil portenseigne <
> [hidden email]> wrote:
>
> > Hello,
> >
> > While working on a new contactMech type (no spoiler yet, that will come
> in
> > some days ;)), I wanted to develop the CRUD services , and stumbled upon
> > something that bother me.
> >
> > Actually, when we update a contactMech in OFBiz, the service keep history
> > of it, to keep reference for related entity (like communicationEvent and
> > such). Thanks to that, old communication event/invoice/etc. refer to the
> > old contact mechanism.
> >
> > That's fine with me, but what is bothering me is that updatePostalAddress
> > (and others) service is named like every auto-entity CRUD services within
> > OFBiz, that could be misleading for newcomers
> >
> > I feel like we have to change the naming of these services. No good idea
> > yet about a new name... Am I the only one wondering about that ? Is that
> > fine to keep "udpate" in this context ?
> >
> > WDYT ?
> >
> > Gil
> >
> >
> > --
> > logoNrd <http://nereide.fr/>
> >         Gil PORTENSEIGNE
> > Intégrateur Apache-OFBiz, ERP en logiciel Libre
> > [hidden email]
> > 8 rue des Déportés 37000 TOURS
> > 02 47 50 30 54
> >
> > | Réseau Libre Entreprise <http://www.libre-entreprise.org/>
> >
> >
>

[Gil Portenseigne]

Hello Deepak,

Nice Idea ! Thanks !

I think that we could have a new entity-auto invoke type, kind of
"update-immutable" to manage the immutable case.

Then for the specific but existing need of PostalAddress fix (we met the
need to fix a postalAddress without creating a new instance), we could
use the basic invoce "update", with a serviceName (fixPostalAddress),
with appropriate documentation for newcomers.

Regards,

Gil

On 24/02/2018 07:14, Deepak Dixit wrote:

> Yes it may confuse but I think its correct, the basic rule is if you want
> to update postal address (ContactMech) it will expire old one and create
> new one with update. So Ideally PostalAddress is an immutable object where
> you can;t do modification in it.
>
> if you want to update you need to clone it and do update.
>
> I think we can add this in entity auto engine so that it will be part of
> entity auto framework.
>
> Thanks & Regards
> --
> Deepak Dixit
> www.hotwaxsystems.com
> www.hotwax.co
>
> On Fri, Feb 23, 2018 at 8:11 PM, gil portenseigne <
> [hidden email]> wrote:
>
>> Hello,
>>
>> While working on a new contactMech type (no spoiler yet, that will come in
>> some days ;)), I wanted to develop the CRUD services , and stumbled upon
>> something that bother me.
>>
>> Actually, when we update a contactMech in OFBiz, the service keep history
>> of it, to keep reference for related entity (like communicationEvent and
>> such). Thanks to that, old communication event/invoice/etc. refer to the
>> old contact mechanism.
>>
>> That's fine with me, but what is bothering me is that updatePostalAddress
>> (and others) service is named like every auto-entity CRUD services within
>> OFBiz, that could be misleading for newcomers
>>
>> I feel like we have to change the naming of these services. No good idea
>> yet about a new name... Am I the only one wondering about that ? Is that
>> fine to keep "udpate" in this context ?
>>
>> WDYT ?
>>
>> Gil
>>
>>
>> --
>> logoNrd <http://nereide.fr/>
>>          Gil PORTENSEIGNE
>> Intégrateur Apache-OFBiz, ERP en logiciel Libre
>> [hidden email]
>> 8 rue des Déportés 37000 TOURS
>> 02 47 50 30 54
>>
>> | Réseau Libre Entreprise <http://www.libre-entreprise.org/>
>>
>>