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 <[EMAIL PROTECTED]>:
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
