|
> There is something going on that you are not telling us.
I'm also assuming, that my "problem" is something for the school of bleeding obvious...
However, by way of trial, I changed the temporary table to a permanent one, and my problems have been solved (temporarily). Since I have to deal with temporary tables anyway, this did not help of course.
The only "solution" that is working (as far as I can evakzate) is the following one:
1. The data are inserted into the temporary table from the users session and editing context.
2. For each record fetched, a new one is created in the memory only (still in the user session and the object is not inserted into any editing context at this point)
3. The memory objects are passed to the thread
4. The thread (assuming he has to deal with enterprise objects only) has to insert these memory objects in its own editing context.
5. If done as described above, from now on, all attributes and relationships are accessible.
Note: point 2 does not work if using reflection (this, again, does induce everything to return null values), I really had to do the following in the users session:
NSMutableArray memoryObjects = new NSMutableArray();
Enumeration enumerator = userSessionObjects.objectEnumerator();
while (enumerator.hasMoreElements()) {
SomeEnterpriseObject aUserSessionObject = (SomeEnterpriseObject)enumerator.nextElement();
SomeEnterpriseObject aMemoryObject = new SomeEnterpriseObject(); // do not insert this one into any editing context (this is done by the thread)
aMemoryObject.setName(anObject.name()); // using the getter and setter methods (this may be cumbersome for lots of attributes and relationships)
aMemoryObject.setXY(anObject.XY()); // using the getter and setter methods (this may be cumbersome for lots of attributes and relationships)
...
That isn't nice, since every object is stored twice (for a short time only indeed) in the database, but it works.
|