Confirmed, that fixed it. Thanks again! :)
Gili
Andrus Adamchik wrote:
> 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/
>>
>>
>
>
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Fri Sep 09 2005 - 13:12:31 EDT