Re: back to ERXBatchingDisplayGroup instead of ERXDisplayGroup
Re: back to ERXBatchingDisplayGroup instead of ERXDisplayGroup
- Subject: Re: back to ERXBatchingDisplayGroup instead of ERXDisplayGroup
- From: Baiss Eric Magnusson <email@hidden>
- Date: Tue, 4 May 2010 11:08:17 -0700
On May 3, 2010, at 6:18 PM, Chuck Hill wrote:
>> public ERXBatchingDisplayGroup<Transaction> curTrans;
>> curTrans.queryBindings().setObjectForKey( … );
>> try {
>> curTrans.setObjectArray( theOwner.transactions() );
>> curTrans.qualifyDataSource();
>
> That looks... odd. Especially this part:
> curTrans.setObjectArray( theOwner.transactions() ) I'd expect to set ERXBatchingDisplayGroup up for Transaction and use a
> qualifier like "owner = $owner
This really stops me, owner is an object reference to a huge class, I don't understand the generation of anything like owner=$owner in sql, unless EOModeler does some magic substitution of the primary key for the owner equality.
I tried to do so as a test, but I can't get it to generate a meaningful error, just throws a message relating to <$endMonth> the last variable of the list
<owner = $owner and date >= $startMonth and date < $endMonth>
************************
Exception
at java.lang.Thread.run(Thread.java:637) Caused by: com.webobjects.foundation.NSForwardException [java.lang.IllegalStateException] sqlStringForKeyValueQualifier: attempt to generate SQL for com.webobjects.eocontrol.EOKeyValueQualifier (date < $endMonth) failed because the qualifier variable '$endMonth' is unbound.:CurrentSit throw an Exception trying to fetch the transactions.
at Components.CurrentSit.<init>(CurrentSit.java:73) ... 45 more Caused by: java.lang.IllegalStateException: sqlStringForKeyValueQualifier: attempt to generate SQL for com.webobjects.eocontrol.EOKeyValueQualifier (date < $endMonth) failed because the qualifier variable '$endMonth' is unbound.
at com.webobjects.jdbcadaptor.FrontbasePlugIn$FrontbaseExpression.sqlStringForKeyValueQualifier(FrontbasePlugIn.java:1351)
************************
I'm pursuing this because of a gap in understanding I may have.
Before this last years rewrite there were many, many fetch specs, like
loginId = $loginId and accountId = $accountId
i.e. the old code always explicitly stored/accessed the primary key id of the related object, and in the related object made the primary key accessible as a class member.
I try to undo as I go along this code, there's a lot of it.
***********************
Interesting, I've not used <new EODatabaseDataSource> object, or the other routines, like you do below.
Still studying, thanks.
> and date >= $startMonth and date < $endMonth" Passing in theOwner.transactions() is likely to remove a lot of the benefit.
>
> I don't use model (or wherever you are getting this from) display groups, so I don't know what do tell you. In code it would look something like this:
>
> dataSource = new EODatabaseDataSource(editingContext(), entityName());
>
> dataSource.fetchSpecification().setPrefetchingRelationshipKeyPaths(prefetchingRelationshipKeyPaths());
> dataSource.fetchSpecification().setRefreshesRefetchedObjects( refreshesRefetchedObjects() );
> dataSource.fetchSpecification().setIsDeep( true );
> dataSource().fetchSpecification().setQualifier(qualifier());
> displayGroup.setDataSource(dataSource);
>
> I am guessing you mean an exception not a crash.
Yes, Exception, sorry.
----
Baiss Eric Magnusson
Cascade Web Design
_______________________________________________
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