You were correct Andrus. I was able to implement a work-around that at the
object level made the Employee to RetirementAccount still behave and look
like a 1:1.
First I modeled the Employee to RetirementAccount relationship to be to
many, rather than to one. I left the RetirementAccount to Employee reverse
relationship to be to one.
Next I placed some methods in Employee.java to ease the replacement of a
RetirementAccount or adding one or getting one (if it existed). Since
Employee.java extends _Employee.java, these methods are simple workarounds
to what Cayenne does not support right now.
In Employee.java
<code>
//workaround methods for Cayenne Framework.
//Cayenne only supports 1:1 relationships that have identical primary key
values
public RetirementAccount getRetirementAccount() {
//throw exception if more than 1 account found.
List accounts = getRetirementAccounts();
if(accounts.size() > 1)
throw new CayenneRuntimeException(this.getClass().getName()
+ " can have at most 1 retirement account");
else if(accounts.size() == 0)
return null;
else
return (RetirementAccount)accounts.iterator().next();
}
//workaround methods for Cayenne Framework.
//Cayenne only supports 1:1 relationships that have identical primary key
values
public void setRetirementAccount(RetirementAccount account) {
//iterate over the list and disconnect existing RetirementAccount
from this Employee
Iterator accountIter = getRetirementAccounts().iterator();
while(accountIter.hasNext())
removeFromRetirementAccounts((RetirementAccount)accountIter.next());
//now add the new account
addToRetirementAccounts(account);
}</code>
relevant code in _Employee.java
This was autogenerated from Cayenne Modeler
<code>
public void addToRetirementAccounts(RetirementAccount obj) {
addToManyTarget("retirementAccounts", obj, true);
}
public void removeFromRetirementAccounts(RetirementAccount obj) {
removeToManyTarget("retirementAccounts", obj, true);
}
public List getRetirementAccounts() {
return (List)readProperty("retirementAccounts");
}
</code>
Thanks again for pointing out the answer.
Dave Paules
Quantum Leap
www.quantumleap.us
-----Original Message-----
From: Andrus Adamchik [mailto:andru..bjectstyle.org]
Sent: Friday, January 03, 2003 1:41 PM
To: Dave Paules
Cc: 'cayenne-use..bjectstyle.org'
Subject: Re: error on 1:1 relationship - Some parts of PK are missing in
s naps hot
Hi Dave,
Dave Paules writes:
> Hello Andrus,
>
> Well, I am not certain what "PK-> dep. PK" means. When I used EOModeler
the
> meaning of "Dependent Primary Key" could mean different things depending
on
> what you were talking about. Usually it meant that if I added a new
Employee
> object and a new RetirementAccount object, the primary key value for the
> Employee tuple would ALSO be the primary key value for the
RetirementAccount
> tuple.
Yes this is what it means in Cayenne too. Kind of "master-detail"
relationships. But as you described below, this is not the case in your
schema.
> 1. What does "To Dep PK" mean in Cayenne Modeler? With regard to your
> suggestion of setting that checkbox on the db relationship from Employee
to
> RetirementAccount, the modeler will not allow me to check it. When I do
> check it by setting the xml text to true, the run-time tells me that "the
> toDependentPK value is incorrectly set to true, unsetting it".
Sure. This checkbox shoudn't be checked, since my original guess about your
schema was incorrect. But from the database persoective a relationship from
Employee to RetirementAccount is "to-many", since RetirementAccount has a
Foreign Key to Employee. So this should be modeled as "to-many". I am almost
sure that it was mapping it as "to one" that caused the error.
I need to think some more how to handle this issue more gracefully in the
future, for now I suggest changing Employee->Account to be "to many".
Hope this helps.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jan 06 2003 - 12:33:30 EST