X-CGP-ClamAV-Result: CLEAN X-VirusScanner: Niversoft's CGPClamav Helper v1.22.2a (ClamAV engine v0.102.2) X-Junk-Score: 0 [] X-KAS-Score: 0 [] From: "Ricardo Parada" Received: from st43p00im-ztbu10063601.me.com ([17.58.63.174] verified) by post.selbstdenker.com (CommuniGate Pro SMTP 6.3.3) with ESMTPS id 25627531 for webobjects-dev@wocommunity.org; Thu, 25 Mar 2021 19:12:16 +0100 Received-SPF: pass receiver=post.selbstdenker.com; client-ip=17.58.63.174; envelope-from=rparada@mac.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mac.com; s=1a1hai; t=1616695914; bh=IbvzBCOJ9aGdaksu3zGNzMgLqIGQOmF7PmAVXkYAEYw=; h=Content-Type:From:Mime-Version:Subject:Date:Message-Id:To; b=ACE4FmeCix57FHmdwLIeuyKNE3GyuTXU+oy2DXdDURZDqmT5nTSCyMhDQzaSouUas i4tdqk0J8BRpdnFhPdBOaGvtzuLbWIqJAJVjc7McV0RSORfAZMqnIr5Mwjsc3QA92P irPLeFgLK/3RxWp+uSm6Nn4IZVT5xKE0vpf0G5YecwxY/GBdiw6bcRU8CGqMvC2QmJ XGAh/p8RzaqMSQBMBjchlS9jynlpHAyyq0SAteIK/PZh3OPiHD6q93hiP7v1Xbf67n MgulshEjKd9ysfsj2KjytmGxTIv3/odUi/R1zgZB9/eUtVhJ23jeXRIZ2A4i6aLr4U jSWnmj60jzy+A== Received: from [10.0.0.34] (c-174-61-52-234.hsd1.fl.comcast.net [174.61.52.234]) by st43p00im-ztbu10063601.me.com (Postfix) with ESMTPSA id 0FBAE700341 for ; Thu, 25 Mar 2021 18:11:53 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-84F79E43-D9FD-4BE6-9876-826F6360FF23 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [WO-DEV] Re: ERXCopyable.CopyType = Nullify on to-many relationship should empty instead Date: Thu, 25 Mar 2021 14:11:50 -0400 Message-Id: References: In-Reply-To: To: WebObjects & WOnder Development X-Mailer: iPhone Mail (18D61) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369,18.0.761 definitions=2021-03-25_05:2021-03-25,2021-03-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2103250134 --Apple-Mail-84F79E43-D9FD-4BE6-9876-826F6360FF23 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m gonna play with it but I see a couple of things to advance this.= One is to have an ignoresToManyNullify property that defaults to false so th= at we don=E2=80=99t change the existing behavior.=20 Then for us who don=E2=80=99t want to deal with null to-many relationships. W= e could set the property to true.=20 Another option is to allow Skip to work on relationships.=20 Thanks Aaron for the feedback.=20 I think that code was written by David Avendasora.=20 Ricardo >=20 > On Mar 25, 2021, at 1:35 PM, Aaron Rosenzweig wrote: >=20 > =EF=BB=BFHi Ricardo, >=20 > I have similar feelings as you do that it=E2=80=99s not right as is.=20 >=20 > I believe the original author had in their mind =E2=80=9Ca perfect copy=E2= =80=9D - meaning that if there was something the copy got from awakeFromInse= rtion =E2=80=9Cfor free=E2=80=9D then it isn=E2=80=99t really a copy of the s= ource=E2=80=A6 so the author asked us to nullify.=20 >=20 > That said, there are issues with the current state of affairs: >=20 > 1) =E2=80=9CNullify=E2=80=9D for a toMany relationship should not set it t= o =E2=80=9Cnull=E2=80=9D - it should at least set it to an empty array. Havi= ng it =E2=80=9Cnull=E2=80=9D can cause us gas because we are not expecting t= oMany relationships to ever be null=E2=80=A6 they can be empty arrays but no= t null.=20 >=20 > 2) =E2=80=9CSkip=E2=80=9D is valid for attributes, why not have it valid f= or relationships? If we =E2=80=9Cskip=E2=80=9D then we can leave it alone. Fo= r some reason, the author expressly didn=E2=80=99t want relationships to be s= kipped. It=E2=80=99s presently a syntax error.=20 >=20 > Cheers, > =E2=80=94 Aaron >=20 >> On Mar 25, 2021, at 1:25 PM, Ricardo Parada wrote: >>=20 >> I think ERXCopyable.java: 1286 should be changed to something like this: >>=20 >> case NULLIFY: >> // Only set to-one relationships to null. For to-many relationships w= e leave it alone with the empty array setup during the creation of the EO >> if (!relationship.isToMany()) { >> destination.takeStoredValueForKey(null, relationshipName); >> } >>=20 >>=20 >>=20 >>=20 >>>> On Mar 25, 2021, at 1:02 PM, Ricardo Parada wrote: >>>>=20 >>> =EF=BB=BFHello everyone, >>>=20 >>> I like that in Wonder when you create an EO all the to-many relationship= s are initialized to an empty array because it means that I don=E2=80=99t ha= ve to worry about null checking every time I access the to-many relationship= in order to avoid NullPointerExceptions.=20 >>>=20 >>> However, if I create my EO by copying an existing one using ERXCopyable t= hen any to-many relationships that have ERXCopyable.CopyType set to Nullify w= ill be set to null.=20 >>>=20 >>> Wouldn=E2=80=99t it be better to set them to an empty array? Or should w= e have an Emptify option? >>>=20 >>> Thanks >>> Ricardo Parada >=20 --Apple-Mail-84F79E43-D9FD-4BE6-9876-826F6360FF23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99m gonna play with it but I see a c= ouple of things to advance this.

One is to have an ignore= sToManyNullify property that defaults to false so that we don=E2=80=99t chan= ge the existing behavior. 

Then for us who don= =E2=80=99t want to deal with null to-many relationships. We could set the pr= operty to true. 

Another option is to allow Sk= ip to work on relationships. 

Thanks Aaron for= the feedback. 

I think that code was written b= y David Avendasora. 

Ricardo


On Mar 25, 2021, at 1:35 PM, Aaron Rosen= zweig <webobjects-dev@wocommunity.org> wrote:

=EF=BB=BFHi Ricardo,

I have similar feelings as you do tha= t it=E2=80=99s not right as is. 

I believe the original author had in their mind =E2=80=9C= a perfect copy=E2=80=9D - meaning that if there was something the copy got f= rom awakeFromInsertion =E2=80=9Cfor free=E2=80=9D then it isn=E2=80=99t real= ly a copy of the source=E2=80=A6 so the author asked us to nullify. 

That said, there are= issues with the current state of affairs:

1) =E2=80=9CNullify=E2=80=9D for a toMany relations= hip should not set it to =E2=80=9Cnull=E2=80=9D - it should at least set it t= o an empty array. Having it =E2=80=9Cnull=E2=80=9D can cause us gas because w= e are not expecting toMany relationships to ever be null=E2=80=A6 they can b= e empty arrays but not null. 

2) =E2=80=9CSkip=E2=80=9D is valid for attributes, why not h= ave it valid for relationships? If we =E2=80=9Cskip=E2=80=9D then we can lea= ve it alone. For some reason, the author expressly didn=E2=80=99t want relat= ionships to be skipped. It=E2=80=99s presently a syntax error. 

Cheers,
=E2=80=94 Aaron

On M= ar 25, 2021, at 1:25 PM, Ricardo Parada <webobjects-dev@wocommunity.org> wrote:
I think ERXCopyable.java: 1286 should be changed to som= ething like this:

case N= ULLIFY:
    // Only set to-one relationships t= o null. For to-many relationships we leave it alone with the empty array set= up during the creation of the EO
    if (!rel= ationship.isToMany()) {
        des= tination.takeStoredValueForKey(null, relationshipName);
    }




On Mar 25, 2021, at 1:02 PM, Ri= cardo Parada <webobjects-dev@wocommunity.org> wrote:

=EF=BB=BFHello everyone,

I like that in Wonder when you create an EO all the to-man= y relationships are initialized to an empty array because it means that I do= n=E2=80=99t have to worry about null checking every time I access the to-man= y relationship in order to avoid NullPointerExceptions. 

However, if I create my EO by co= pying an existing one using ERXCopyable then any to-many relationships that h= ave ERXCopyable.C= opyType set to Nullify will be set to null. 
Wouldn=E2=80=99t it be better to s= et them to an empty array? Or should we have an Emptify option?

Thanks
Ricardo Parada
<= div dir=3D"ltr" class=3D"">
=

= --Apple-Mail-84F79E43-D9FD-4BE6-9876-826F6360FF23--