Re: Antw: Re: Migrating Data from a temporary table into anothereditingcontext
Re: Antw: Re: Migrating Data from a temporary table into anothereditingcontext
- Subject: Re: Antw: Re: Migrating Data from a temporary table into anothereditingcontext
- From: Chuck Hill <email@hidden>
- Date: Tue, 5 May 2009 08:12:12 -0700
On May 5, 2009, at 5:30 AM, Andri vonAllmen wrote:
> 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.
I think that is the start of your problem. What exactly are you doing?
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)
"not inserted into any editing context"
EOF is not going to to like this. Later, it will take revenge.
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.
EOF will not be too happy about this either.
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.
If you don't save, how is it in the database?
Chuck
Andri
>>> Chuck Hill <email@hidden> Freitag, 1. Mai 2009 16:50
>>>
On May 1, 2009, at 5:07 AM, Andri vonAllmen wrote:
> Hi Chuck,
>
> thanks for your response.
>
> I can't fetch inside the thread because the thread did not insert
> the data into the temporary table
Change it so that it does. Move the code.
> and can't access them at all. But the session should be able to
> transfer these data to the thread somehow.
Try fetching this temp data as raw rows instead of EOs. Or do you
need the Java classes.
> I also tried to invoke all getter methods of the objects in the
> session for getting the attribute (and relationship) values in order
> to set them to a newly created object (using reflection) by using
> the respective setter methods, but, with the same results....the
> getter methods already return null values (but they don't if I'm
> doing the same with some data from a "permanent" table).
>
> Using the mentioned copy code from Practical WebObjects didn't help
> too.
>
> I can't figure out whats going wrong. Hard copying, refetching,
> refreshing, faulting, everything i do, lets the objects forget about
> their attributes values...
There is something going on that you are not telling us.
Chuck
> >>> Chuck Hill <email@hidden> Mittwoch, 29. April 2009
> 19:09 >>>
> Hi Andri,
>
>
> On Apr 29, 2009, at 5:19 AM, Andri vonAllmen wrote:
>
> > 'loha folks,
> >
> > short: How do i migrate data, fetched from a temporary table, from
> > one editing context into another?
> >
> > Details below...
> >
> > The situation is as follows:
> >
> > First, data are inserted into a temporary table (Oracle 8i) by
using
> > a stored procedure. Then, in the same procedure, these data are
> > fetched from the temporary table into the user sessions editing
> > context.
> >
> > Up to now, I've used ReportMill for generating reports based on
this
> > temporary data. This happens in the same editing context and does
> > not cause any problems.
> >
> > But since ReportMill isn't fun to work with at all, I've decided
to
> > implement my own web-based reporting tool. This one generates the
> > report in its own thread and uses its own editing context (no
shared
> > editing context). It works by simply processing a object graph and
> > invoking all methods (attributes, relationships) using reflection
> > (java.lang.reflect) based on some root objects that have to be
> > passed to the reporting tool.
> >
> > Since the data source is a temporary table in this case, the data
> > objects can't be inserted into another editing context, because an
> > exception, telling that these objects can't be registered in two
> > editing contexts, would be (and is) shown.
>
> It sounds to me like you were doing something wrong. Why not just
> fetch the data into the thread's EC instead of the session's?
>
>
> > So, I've tried to migrate them into a new editing context by
> > faulting for the objects global id in the original editing
context.
> > This basically works, but the migrated data, namely all attribute
> > values, relationships etc. are NULL.
>
> I don't understand why that should be.
>
>
> > For permanent tables, this way of migration works well (code
below):
> >
> > EOEditingContext oldEditingContext =
> > enterpriseObject.editingContext();
> > EOGlobalID globalID =
> > oldEditingContext.globalIDForObject(enterpriseObject);
> > result = newEditingContext.faultForGlobalID(globalID,
> > newEditingContext);
> >
> > Another trial was, to "copy" all objects, telling the old editing
> > context to forget about them and inserting the copy into the new
> > editing context (see code below).
> >
> > EOEnterpriseObject result = enterpriseObject;
> > enterpriseObject.editingContext().forgetObject(enterpriseObject);
> > newEditingContext.insertObject(result);
> >
> > But this does not work either. When trying to get some attributes
> > value or another object reachable over a relationship, still
null is
> > returned.
>
> Because you told it to forget the data!
>
>
> > BUT, when adding e.g. a system out BEFORE migrating the data,
> > accessing some value (e.g. the primary key), the migrated data are
> > not null (in fact, now all attributes and relationships and so on
> > are accessible and do return the correct value).
>
> That is because it then faults in the data.
>
>
> > Since I'm treating this phenomenon for hours and don't see the
> > light, I finally have to ask for help. Any hints would be
> appreciated.
>
> I'd try and fetch directly into the thread's EC. Failing that,
> Practical WebObjects has code to copy a graph of objects.
>
>
> Chuck
>
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Come to WOWODC'09 in San Fran this June!
> http://www.wocommunity.org/wowodc09/
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
@cedes.com
>
> This email sent to email@hidden
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC'09 in San Fran this June!
http://www.wocommunity.org/wowodc09/
_______________________________________________
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
--
Chuck Hill Senior Consultant / VP Development
Come to WOWODC'09 in San Fran this June!
http://www.wocommunity.org/wowodc09/
_______________________________________________
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