Found it. The fix is checked in.
On Sep 9, 2005, at 12:50 PM, Gili wrote:
>
> Ok, so it's not just me :) Please note that I am not using any
> prefetching in my query (whereas the issue you pointed me to
> mentions it is related to prefetching). Is there any known
> workaround or ETA associated with this issue?
>
> Thank you,
> Gili
>
> Andrus Adamchik wrote:
>
>> This is a bug. I can reproduce it. Probably related to this one:
>> http://objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-352
>> On Sep 9, 2005, at 12:20 PM, Gili wrote:
>>
>>> Ah ha! Found it! It's a bug in the cached mapped query
>>> support again. DataContext line 1237, when we generate a new
>>> query we don't copy over the qualifier string. I've moved this
>>> email over to the dev list.
>>>
>>> The problem is that the code invokes select.createQuery()
>>> which constructs a new Query based upon the old one but defaults
>>> to pruneMissing = true... for some unknown reason, this strips
>>> away my qualifier. It is true it has no parameters, but none of
>>> them are bound parameters either, so I don't think it should be
>>> stripping them away. So that's one bug (I think) and I think
>>> there is also a second one in that that we shouldn't be using
>>> pruneMissing = true in the first place for constructing a cached
>>> SelectQuery based upon the original SelectQuery. The parameters
>>> before and after should match up 100% and if not we should throw
>>> an error.
>>>
>>> Gili
>>>
>>>
>
> --
> http://www.desktopbeautifier.com/
>
>
This archive was generated by hypermail 2.0.0 : Fri Sep 09 2005 - 13:05:44 EDT