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?



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 PROTECTED]>
Date: October 15, 2008 9:58:11 AM GMT-05:00
To: David LeBer <[EMAIL PROTECTED]>
Cc: WebObjects-Dev Apple <webobjects-dev@lists.apple.com>
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      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/dleber_wodev%40codeferous.com

This email sent to [EMAIL PROTECTED]

;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      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com

This email sent to [EMAIL PROTECTED]


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to