Mailing-List: contact cayenne-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cayenne-user@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 20 Jun 2006 09:24:49 -0700
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: modifying relationship list
In-reply-to: <110DED9F5106CC47A186602C0DD3938201168B60@EXVF.fanniemae.com>
Sender: Craig.Russell@Sun.COM
To: cayenne-user@incubator.apache.org
Message-id: <1D080DEA-A9BF-4808-9A6F-EAF2889C24EF@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-165-714799694; micalg=sha1
References: <110DED9F5106CC47A186602C0DD3938201168B60@EXVF.fanniemae.com>

--Apple-Mail-165-714799694
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

I hate to be a curmudgeon, but it sounds like this might go in the  
wrong direction, if I understand correctly. You need two sets of  
functionality: one that the user sees and transparently updates both  
sides of the relationship; the other, internal, that is called by the  
external methods and individually updates only one side. Many users  
would see void add(Room theRoom) and expect to call it instead of  
void removeObjectFromBothSidesOfRelationshipWithKey(Room theRoom,  
Site theSite). Or perhaps it's really static void  
RelationshipHelper.removeObjectFromBothSidesOfRelationshipWithKey 
(Object oneSide, Object theOtherSide) which can be called from any  
context and has to be omniscient.

If the removeObjectFromBothSidesOfRelationshipWithKey is intended to  
be the user-visible method, then it's very descriptive. Is this the  
user-visible method?

By the way, this is one case where I really miss the "friend"  
annotation of C++. You don't want the internal methods to be visible  
to users, just to the classes on the other side of the relationship.  
Nothing like this semantic exists for Java. :-(

Craig

On Jun 20, 2006, at 6:04 AM, Gentry, Michael (Contractor) wrote:

> Monstrous?  That was my favorite method name!  It stated precisely  
> what
> it was doing, too.  :-)  We hardly ever removed anything, so never got
> to use removeObjectFromBothSidesOfRelationshipWithKey all that much.
> Sigh.
>
> /dev/mrg
>
> PS. For me, it was actually  
> addObject:toBothSidesOfRelationshipWithKey:
> ... Much better.
>
>
>
> -----Original Message-----
> From: Andrus Adamchik [mailto:andrus@objectstyle.org]
> Sent: Tuesday, June 20, 2006 2:19 AM
> To: cayenne-user@incubator.apache.org
> Subject: Re: modifying relationship list
>
>
>>
>> "Someone" should write a paper.
>
> Yep :-)
>
> I recall back in my WebObjects/EOF days, instead of using property
> setters I always used a generic method with monstrous name of the
> Objective C heritage - "addObjectToBothSidesOfRelationshipWithKey"
> and its counterpart "removeObjectFromBothSidesOfRelationshipWithKey"
> exactly because it helped with graph consistency.
>
> So bidirectional relationship management was one of the first
> features in the early Cayenne to address that.
>
> Andrus
>
>
> On Jun 19, 2006, at 8:51 PM, Craig L Russell wrote:
>
>> Hi,
>>
>> This relationship change issue is a very old one in object modeling
>> and made even more interesting when mapping to a relational
>> database, where typically there is only one database column value
>> that represents both sides of the relationship.
>>
>> Among the standards for persistence (J2EE CMP, JDO 1, JDO 2, and
>> EJB3) the requirements are all over the map, with little to guide  
>> you.
>>
>> CMP defines the behavior as I understand Cayenne currently
>> implements it. That is, the relationship on the other side is
>> silently changed to be consistent.
>>
>> JDO 1 is silent on the issue.
>>
>> JDO 2 defines the behavior as "undefined until commit or flush", at
>> which point the relationships on both sides are silently changed to
>> be consistent.
>>
>> EJB3 is silent, and allows relationships to be inconsistent after
>> commit.
>>
>> I believe it is tricky to code defensively if you want to manage
>> relationships in memory. The issue is the possibility of updating
>> the relationship from either side. The apparently straightforward
>> technique is to implement the Room.setSite method to call
>> oldRoom.remove(this) and newRoom.add(this). And the Site.remove
>> method to call theRoom.setSite(null) and Site.add method to call
>> theRoom.setSite(this). But this causes recursion, unless you use
>> special add, remove, and set methods, that need to be protected
>> from public callers. That is, define package protected methods
>> uncoordinatedAdd, uncoordinatedRemove, and uncoordinatedSet that
>> don't manage the other side, but are called from within the public-
>> visible implementations of add, remove, and set. But clearly this
>> is a lot of work for developers, so it's nice that the persistence
>> implementation does some of the hard work for you.
>>
>> "Someone" should write a paper.
>>
>> Craig
>>
>> On Jun 19, 2006, at 1:12 AM, Tomi NA wrote:
>>
>>> On 6/19/06, Marcin Skladaniec <marcin@ish.com.au> wrote:
>>>> Hello
>>>> Just run into interesting cayenne feature.
>>>>
>>>> This code:
>>>>
>>>> rooms = site.getRooms();
>>>> rooms.remove(aRoom);
>>>>
>>>> would alter the relationship
>>>>
>>>> so aRoom.getSite() is now null
>>>>
>>>> I'm wondering if this is a desired effect ?
>>>> This behavior might cause bugs. When someone actually puts code to
>>>> know the fact of relationship being changed (ie. put code into Room
>>>> setSite() and Site add/removeFromRooms()/setRooms() methods ) he
>>>> might be disappointed, as those methods would not run, but the
>>>> relationship will change...
>>>
>>> I'm wrestling with this issue myself: I've extended the basic
>>> templates so that events are fired on setter calls, but this  
>>> practice
>>> has the exact shortcomings you pointed out.
>>> Is there a very good reason why cayenne objects don't fire events
>>> on a
>>> lower level (circumventing this problem) out of the box?
>>> Alternatively, if I expand my object code generation templates
>>> further
>>> so that objectA.removeFrom(objectB) fires a property change event  
>>> for
>>> it's objectA.getBArray() as well as objectB.getToA() - will this
>>> completely solve the problem?
>>>
>>> t.n.a.
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


--Apple-Mail-165-714799694
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICEB7Y7fLHmKoeHTUdbtYrvpAwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxNTIxNDc0NFoXDTA2MTIxNTIxNDc0
NFowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMXXgEAm88nu8cFbxXSWqTq+GaYpCx/0QSom
8kBbVxpJIURuO4ErLDupeXu6y9+5e7ZKLbeSQE5xbfYPcQR/IhqmYKy5YqRcuzPXREBj2zKEkZph
pNXWpHgMdx9W8dq0Cu2i9Ux/S6c2MuEHrP6gfGGll+b/mzLoO280QHTuE4pcpKntRnwZdGxQ/5l8
IL+eLP+jpJAbYW9C+KNKofZtS6V6R0uzlqTOsEdZvwxZQ4mmPgHoz1+Gjwme/PC5sKvF09MaJDiI
pj9SvZ4CTCgcDZV78J086YwlVbMC0VQotjhu1p42lr8CS33IXLz3OWNrDETCAepah/Dgw2ZZApQ9
9L0CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEEBQADgYEAKdIkgAWCg2Bi7ocnstfJA4iymTRI2/L4oQx9zvllM9bNJ2cR
cecJIx3HuoHbhPvemh1GExEPgHU+dXSxDmD0BEmPnhSReKCURyslnbMphPZ5kR6USzQFrRa+v0ii
J+SBO9VQYTQWT+xEjmRLM76MfkBFw3IOC9CUkRoYZ88pOoUwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEB7Y7fLHmKoeHTUdbtYrvpAwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNjIwMTYyNDUwWjAjBgkqhkiG9w0B
CQQxFgQUM1Dx7wdPzXIIT67i5n5WINi76ecwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe2O3yx5iqHh01HW7WK76QMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe
2O3yx5iqHh01HW7WK76QMA0GCSqGSIb3DQEBAQUABIIBAGoiGAE5QrPPa8GAGPbTEjflTp5WYp0B
Xx8xQ/u44vEqkCozA8Sg4eYLh+NoZW8GQhNN/wNd2iu+jSX5PqAuY5HXrXE4yEiGdbnmR+mI3zCv
aGf1qAQtqFHQQbQjG6OD/UkRlFkHfadNBjqgPi8mVVLCPEMwoxc/BNnviiapffKQ7cvfRmrici0t
dLlYPVJqekYjVdCKFMeSpXvmAo24PXugOekXJOw+H5veEeapASt+dW7pKNsePUYv09HXC+n9y9qX
t53/Ix8aXAgQFLpyuzYHoXj34j4OsJLjyA5jQkBz9UX4nzckaGSgrrVcN+54QOOC/fOcqnux2JyT
nNo8zFIAAAAAAAA=

--Apple-Mail-165-714799694--