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 coul
+1 Deepak!!
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co
On Sat, Feb 24, 2018 at 11:44 AM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:
> Yes it may confuse but I think its correct, t
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
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, 2
perhaps updatePostalAddressWithHistory
On Fri, Feb 23, 2018 at 5:41 PM, gil portenseigne
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.
>
> Actual
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