Re: You crossed editing context boundaries...Fixzed, now NullPointerException, now fixing db
Re: You crossed editing context boundaries...Fixzed, now NullPointerException, now fixing db
- Subject: Re: You crossed editing context boundaries...Fixzed, now NullPointerException, now fixing db
- From: David Avendasora <email@hidden>
- Date: Wed, 15 Oct 2008 13:59:31 -0400
I don't think it is.
A Turn can have more than one Employee and an Employee and have more
than one Turn, right?
If so, you need the Employee to EmployeeXTurn to be a to-Many and the
Turn to EmployeeXTurn to be a to-Man, and EmployeeXTurn has to-One
relationships to Employee and Turn.
Dave
On Oct 15, 2008, at 1:28 PM, WebObjects wrote:
Hello Dave and David,. Let me know please if its all right now with
the EOModel
regards
Gus
<ScheduleControl.eomodeld>
On Oct 15, 2008, at 11:29 AM, David LeBer wrote:
On 15-Oct-08, at 12:05 PM, WebObjects wrote:
Aha, so im sticking with the initial model. making the changes
David suggested:
- Remove the flattened relationships from Employee to Turn
- Expose the relationships from Employee and Turn to
EmployeeXTurn
- Use only id as the PK.
- Manage the creation of EmployeeXTurn manually.
Im having problem with a nullpointer exception when trying to save
the turns a employee register, actually its not when saving, but
when doing this.
Employee localEmployee =
(Employee)EOUtilities.localInstanceOfObject(myEC, emp);
System.out.println(selectedItems());
NSArray<Turn> localSelectedItems =
EOUtilities.localInstancesOfObjects(myEC, selectedItems());
System.out.println(localSelectedItems);
for (Turn actualTurn : localSelectedItems){
localEmployee
.addObjectToBothSidesOfRelationshipWithKey(actualTurn,
Employee.TURNS_KEY);
}
//
localEmployee
.addObjectsToBothSidesOfRelationshipWithKey(localSelectedItems,
Employee.TURNS_KEY);
myEC.saveChanges();
I tried before, without the for loop, doing just:
localEmployee
.addObjecstToBothSidesOfRelationshipWithKey(localSelectedItems,
Employee.TURNS_KEY);
and had the same Exception, I guess its because of the relationship.
So im making those changes and see what happens.
and then before saving changes I will need to add the turn and
emplyee to EmoployeeXTurn relationships no?
Yes.
You will no longer have a direct relationship between Employee and
Turn, so you need to do create the EmployeeXTurn instance and join
it to the Employee and Turn manually. I'd probably add a factory
method to EmployeeXTurn and maybe a convenience method to Employee
to make this cleaner.
Gus
On Oct 15, 2008, at 10:30 AM, David Avendasora wrote:
Hi Gus,
Sorry to be so late on this thread as I am the one that suggested
you model your application like this.
Flattening makes many-to-many relationships more convenient, BUT
it only works if the join table is nothing but a join table that
exists simply to manage a relationship. The fact is that in this
situation it is not _just_ a join table. It contains important
business information.
You will need to manage this table manually. But with WO,
"manually" is still pretty simple. Treat it like any other
relationship. You'll just need to use key paths to resolve the
relationship and you can create your own convenience methods for
this so you only have to do it once. For example, if you want all
a Turn's employees, create the following method on Turn:
public NSArray<Employee> employees() {
return employeeXTurns().valueForKey("Employee");
}
OR, if more safely:
public NSArray<Employee> employees() {
return employeeXTurns(). valueForKey(EmployeeXTurn.EMPLOYEE_KEY);
}
Don't go changing your Entity Model to make your programming
easier. Make it match the real world as closely as possible -
that in itself will make developing your application easier.
Dave
On Oct 15, 2008, at 11:03 AM, WebObjects wrote:
well is it easier to manage it leaving EOF to handle the
relationships, i guess, so if ther is a way to get the date the
turn was assigned to the Employee not doing it by the
EmployeeXTurn Entity, then will be fine, just I can't see it
where, or how.
Gus
Begin forwarded message:
From: WebObjects <email@hidden>
Date: October 15, 2008 9:58:11 AM GMT-05:00
To: David LeBer <email@hidden>
Cc: WebObjects-Dev Apple <email@hidden>
Subject: Re: You crossed editing context boundaries...
Aha, I need the CreationDate in the EmployeeXTurn table
because I will need to know sometimes when was created the
turn by the employee, for administrative reasons.
So following your advise I will need to make the relatonship
again, but this time I shouldn't flattened (im not familiar
with the term ;-)) ... ok let me see if I can do it, the only
problem i see, is that i tried once to leave id as the only PK,
but then when trying to make the relationship, EOModeler
complained when trying to make the relationship to attributes
that weren't PK, Im gonna try it once again.. I will let you
know.
Gus
PS taking care of babies and trying to programing.... hard work.
On Oct 14, 2008, at 10:32 PM, David LeBer wrote:
On 14-Oct-08, at 10:19 PM, WebObjects wrote:
mmm.. weird I tried to add it one by one using the
addObjectToBothSidesOfRelationshipWithKey() method
and it stills giving me the java.lang.nullpointerexception
:S:S:S:
maybe something wrong with my EOModel???
Im attaching it..
<ScheduleControl.eomodeld>
The join table between Employee and Turn looks whacked.
- It has a three way compound primary key. (employeeId, id,
turnId)
- It has a 'creationDate' attribute.
- It participates in a flattened relationship between Employee
and Turn.
EOF is not going to know how generate that three way compound
primary key.
If EmployeeXTurn is just a join table and is going to be
flattened out of the object graph then it should just have a 2
way compound PK based on the FKs from Employee and Turn and it
should NOT have any other attributes.
If EmployeeXTurn has attributes you need to gain access to
(i.e. creationDate) then you should treat it like a standard EO.
- Remove the flattened relationships from Employee to Turn
- Expose the relationships from Employee and Turn to
EmployeeXTurn
- Use only id as the PK.
- Manage the creation of EmployeeXTurn manually.
apart of the consistency names and other stuff, are the
relations good?
Regards
Gus
On Oct 14, 2008, at 7:43 PM, Ricardo J. Parada wrote:
How about your registerTurns() method? Did you change it to
use myEC instead of ERXEC.newEditingContext()?
On Oct 14, 2008, at 8:17 PM, WebObjects wrote:
aha... you are right, after whole day sitting here, I
didn't realize I had teh emp at login with the
session().defaultEditingContext, and here at PaguinaUsuario
I m using another one.
My mind its kind of distracted...
I made the changes, and still Im getting the
nullpointerexception
java.lang.NullPointerException
[2008-10-14 19:13:51 COT] <WorkerThread0>
java.lang.NullPointerException
at
com
.webobjects
.eoaccess
.EODatabaseContext
._objectFaultWithSnapshotRelationshipEditingContext
(EODatabaseContext.java:2356)
at
com
.webobjects
.eoaccess
.EODatabaseContext
._fireDeferredFaultWithSourceObject(EODatabaseContext.java:
2401)
at
com
.webobjects
.eoaccess
.EOAccessDeferredFaultHandler
.createFaultForDeferredFault
(EOAccessDeferredFaultHandler.java:49)
at
com
.webobjects
.eocontrol
.EOCustomObject.willReadRelationship(EOCustomObject.java:
1279)
at
er
.extensions
.eof
.ERXGenericRecord
.willReadRelationship(ERXGenericRecord.java:348)
at com.webobjects.eocontrol._EOMutableKnownKeyDictionary
$Initializer
$
_LazyGenericRecordBinding
.valueInObject(_EOMutableKnownKeyDictionary.java:614)
at
com
.webobjects
.eocontrol
.EOCustomObject.storedValueForKey(EOCustomObject.java:1634)
at
com
.webobjects
.eoaccess
.EODatabaseContext
.databaseOperationForObject(EODatabaseContext.java:4814)
at
com
.webobjects
.eoaccess
.EODatabaseContext.valuesForKeys(EODatabaseContext.java:6535)
at
com
.webobjects
.eocontrol
.EOObjectStoreCoordinator
.valuesForKeys(EOObjectStoreCoordinator.java:326)
at com.webobjects.eoaccess.EOQualifierSQLGeneration
$
_KeyValueQualifierSupport
.schemaBasedQualifierWithRootEntity
(EOQualifierSQLGeneration.java:439)
at er.extensions.ERXExtensions
$
KeyValueQualifierSQLGenerationSupport
.schemaBasedQualifierWithRootEntity(ERXExtensions.java:304)
at com.webobjects.eoaccess.EOQualifierSQLGeneration
$
Support
._schemaBasedQualifierWithRootEntity
(EOQualifierSQLGeneration.java:179)
at
com
.webobjects
.eoaccess
.EODatabaseChannel
.selectObjectsWithFetchSpecification(EODatabaseChannel.java:
227)
and more........ much more.
On Oct 14, 2008, at 7:06 PM, Ricardo J. Parada wrote:
It looks like you got the employee object using the
session's default editing context. And you are saying
that your PaginaUsuario creates its own editing context in
the constructor. So there you have it: two different
editing contexts.
I would modify your setEmp() method in the PaginaUsuario
that you make a copy of the emp object passed in to the
editing context used in that page. Something like this:
public void estEmp(Employee anEmp) {
emp = anEmp.localInstanceIn(myEC);
}
Then your registerTurns() method is yet creating another
editing context. Shouldn't that be also myEC??
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden
)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
;david
--
David LeBer
Codeferous Software
'co-def-er-ous' adj. Literally 'code-bearing'
site: http://codeferous.com
blog: http://davidleber.net
profile: http://www.linkedin.com/in/davidleber
twitter: http://twitter.com/rebeld
--
Toronto Area Cocoa / WebObjects developers group:
http://tacow.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
;david
--
David LeBer
Codeferous Software
'co-def-er-ous' adj. Literally 'code-bearing'
site: http://codeferous.com
blog: http://davidleber.net
profile: http://www.linkedin.com/in/davidleber
twitter: http://twitter.com/rebeld
--
Toronto Area Cocoa / WebObjects developers group:
http://tacow.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Re: You crossed editing context boundaries... (From: WebObjects <email@hidden>) |
| | >Re: You crossed editing context boundaries...Fixzed, no NullPointerException, now fixing db (From: WebObjects <email@hidden>) |
| | >Re: You crossed editing context boundaries...Fixzed, no NullPointerException, now fixing db (From: David Avendasora <email@hidden>) |
| | >Re: You crossed editing context boundaries...Fixzed, now NullPointerException, now fixing db (From: WebObjects <email@hidden>) |
| | >Re: You crossed editing context boundaries...Fixzed, now NullPointerException, now fixing db (From: David LeBer <email@hidden>) |
| | >Re: You crossed editing context boundaries...Fixzed, now NullPointerException, now fixing db (From: WebObjects <email@hidden>) |