So, I had an interesting problem that I had not come across before. In my REST
controllers I have a baseQualifier() which restricts objects to those that the
user has access to. This base qualifier is used for the FetchSpec in the
indexAction and used for in-memory evaluation to check object access privileges
for single object actions such as show and update.
In one controller I had a qualifier keypath (constructed using ERXKeys of
course, but just keeping it simple here to illustrate) that qualified Prospect
objects (basically mailing name/address objects):
prospectLists.campaigns.program.location.customer.reseller
The first key is a flattened many-to-many.
The second key is a toMany
The remaining keys are toOne.
The qualifier is basically
new
EOKeyValueQualifier("dataLists.campaigns.program.location.customer.reseller",
EOQualifier.QualifierOperatorContains, reseller);
This qualifier returns the correct objects when used in a FetchSpec.
However using the same qualifier.evaluateWithObject(...) against any of the
objects returned in the fetchspec is false!
Debugging shows that for in-memory evaluation, we have an array of arrays of
'reseller', instead of the expected array of 'reseller' objects, which probably
makes sense since the keypath is toMany.toMany.toOne.toOne.toOne.toOne.
The workaround for this rest controller was easy, but it raises the question:
Should we expect in memory evaluateWithObject to always be true on objects that
the qualifier fetches with SQL?
Should valueForKeyPath default impl. return a flattened array of objects, or
should the qualifier class flatten the array of objects in evaluateWithObject,
or ........?
Any opinions?
Regards, Kieran
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
