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: Wed, 6 May 2009 09:51:46 -0700
On May 5, 2009, at 11:33 PM, Andri vonAllmen wrote:
Hi Chuck,
thanks again for your efforts.
>> 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?
Basically I'm developing a reporting tool for generating reports
(PDF, CSV, Excel, etc.) based on data coming out of a database.
A report is generated as follows:
1.
The user selects data. This happens on one of many search interfaces
provided by the application (it's a ERP System). The selected data
are fetched and either displayed on the user interface with the
possibility to generate a report, or a report configuration window
is shown directly (this configuration window is shown in every case
before generating a report).
The data that are fetched, are not stored permanently in the
database in every case. It may be the case, that these data
previously have been inserted into a temporary table (e.g. by a
stored procedure) and are available for the report generation only.
2.
On the report configuration page, the user may select some
predefined attributes and relationships available for the report,
create report templates and so on. The available attributes and
relationships are arranged by an admin, who has the possibility to
travel along the whole object graph available based on a root entity.
If you have just fetched the data from a temp table, how is it able to
navigate the graph?
3.
For generating a report, a thread is created and the already fetched
data as well as other report options are passed to this thread
(happens in the constructor).
4.
The thread migrates the received data into its own editing context
by faulting for the objects global id.
5.
The thread begins to handle all objects by processing the object
graph using reflection.
---
An Example not working for data whose source is a temporary table
(reduced to the basics):
# SEARCH ACTION (returning a report configuration window)
#
public WOComponent searchAction() {
NSMutableDictionary storedProcDict = new NSMutableDictionary();
storedProcDict.setObjectForKey(someValue, "someKey");
...
// fill the temporary table
EOUtilities.executeStoredProcedureNamed(editingContext,
"fillTempTable", storedProcDict);
Why not pass this knowledge into the reporting thread so that it can
do the fetch and skip the migration?
...
// fetch data from temporary table
EOFetchSpecification fetchSpecification = new
EOFetchSpecification("tempTable", null, null);
NSArray results =
editingContext.objectsWithFetchSpecification(fetchSpecification);
// create and return the report configuration page (pop-up)
ReportConfigurationPage page =
(ReportConfigurationPage)pageWithName("ReportConfigurationPage");
page.setRootEntity("TempTableObject");
page.setModuleDescription("Some Module Name");
page.setReportName("SomeReportName");
page.setArrayWithFetchedObjects(results); // the results are
migrated into the threads editing context in the threads constructor
page.setMigrateFromTempTable(true);
return (WOComponent)page;
}
# On the report configuration window, the user selects the
attributes that shall be displayed on the report and finally starts
the report generation (creates a thread)
# THREAD CONSTRUCTOR
#
public ReportThread(NSArray arrayWithFetchedObjects, Report
report, String reportName, ReportTemplate selectedTemplate,
NSDictionary titleDict, boolean migrateFromTempTable) {
...
this.arrayWithFetchedObjects =
XTEditingContext.migrate(arrayWithFetchedObjects); // right here the
migration is done which fails (only null values after migration)
when passing data with a temporary table as source
...
}
# MIGRATION
#
/** Moves database objects in an array into another editing
context */
public final static NSArray migrate(NSArray anArray,
EOEditingContext newEditingContext)
{
What is the fetch lag on newEditingContext? Is it rejecting the data
from the temp table as the snapshots are too old?
NSMutableArray returnArray = new NSMutableArray();
Enumeration enumerator = anArray.objectEnumerator();
while (enumerator.hasMoreElements()) {
EOEnterpriseObject anEOEnterpriseObject =
(EOEnterpriseObject)enumerator.nextElement();
returnArray.addObject(migrate(anEOEnterpriseObject,
newEditingContext));
}
return returnArray.immutableClone();
}
/** Moves database object into another editing context */
public final static EOEnterpriseObject migrate(EOEnterpriseObject
enterpriseObject, EOEditingContext newEditingContext)
{
EOEnterpriseObject result = enterpriseObject;
// is there an object?
if(enterpriseObject != null)
{
// old editing context
EOEditingContext oldEditingContext =
enterpriseObject.editingContext();
// only if object is in editing context and object is already
not in
// the new editing Context
if(oldEditingContext != null && oldEditingContext !=
newEditingContext)
{
// get global ID of the object
EOGlobalID globalID =
oldEditingContext.globalIDForObject(enterpriseObject);
// if the object has a global id
if(globalID != null)
// object with global id return to the editing context
result = newEditingContext.faultForGlobalID(globalID,
newEditingContext);
}
}
return result;
}
---
Andri
>>> Chuck Hill <email@hidden> Dienstag, 5. Mai 2009
17:12 >>>
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:
@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/
--
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