On 11/11/2008, at 11:09 PM, Andrus Adamchik wrote:
> I am not a big fan of entity qualifiers for things other than
> inheritance, as sooner or later you'd end up trying to work around
> it to get data they are hiding.
Yeah and should you share that model in a framework/lib between more
than one app it really needs to be optional.
So some delegate methods triggered from performQuery (prior to
actually performing the query - giving the delegate the opportunity to
alter the query properties or a clone thereof) might do the trick.
> And there's no way to just turn them off... Anyways, entity cloning
> hack should work, but may require some tweaking. So what exactly is
> the error?
I've not tried it yet, but was just posing the question as I've got a
background thread (server-side) which I'd like to have the usual
restricting qualifier (which by default is like ... 'isDeleted is null
or isDeleted = 0') turned off. For everything else in the app we
assume it's on.
> On Nov 11, 2008, at 2:00 PM, Andrey Razumovsky wrote:
>
>> Wow, I ran into same question yesterday (if you mean ObjEntity
>> qualifiers).
>> Still have no answer though. I though I could perform a SelectQuery
>> with a
>> phantom ObjEntity which is created by cloning ObjEntity with
>> qualifier and
>> setting qualifier to null, but that doesn't seem to work.
Probably the class for the entity is still associated with the old
ObjEntity .. which you want. Perhaps this would only work with a
different db connection stack?
>> 2008/11/11, Lachlan Deck <lachlan.dec..mail.com>:
>>>
>>> Hi there,
>>>
>>> I'm just wondering if it's possible to get a DataContext that has
>>> the
>>> restricting qualifiers (as defined in the model) turned off?
>>> Thanks.
with regards,
--Lachlan Deck
This archive was generated by hypermail 2.0.0 : Tue Nov 11 2008 - 07:31:25 EST