cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lachlan Deck <>
Subject Re: restricting qualifiers turned off?
Date Tue, 11 Nov 2008 12:30:43 GMT
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 <>:
>>> 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

View raw message