You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Lachlan Deck <la...@gmail.com> on 2008/11/11 12:41:09 UTC
restricting qualifiers turned off?
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
Re: restricting qualifiers turned off?
Posted by Andrus Adamchik <an...@objectstyle.org>.
One possibility is to install a custom DataChannel between DataContext
and DataDomain, and intercept and modify certain queries there.
Chaining DataChannels hasn't been tested extensively, so there might
be some pitfalls, but generally this is the easiest way to intercept
all traffic going between the app and the DB.
Andrus
On Nov 11, 2008, at 3:45 PM, Lachlan Deck wrote:
> On 11/11/2008, at 11:42 PM, Andrus Adamchik wrote:
>
>> On Nov 11, 2008, at 2:30 PM, Lachlan Deck wrote:
>>
>>> Yeah and should you share that model in a framework/lib between
>>> more than one app it really needs to be optional.
>>
>> I really don't see how you can make it "optional". Entity qualifier
>> is not optional by design. It is either mapped or not.
>
> That's what I meant. Applied instead by some means during ObjEntity
> registration during app launch. I'm not aware of what hooks are
> available for this purpose in Cayenne. But I'd prefer to pull them
> out if the below suggestion was available instead.
>
>> I have a solution in mind for the "library" case - smart mapping
>> overrides. So that a piece of shared mapping could be modified as
>> needed by the downstream users, with full reuse of the library
>> mapping. I started developing that as I needed to customize
>> listeners per project, but I am sure it can be put to good use in
>> many other cases.
>>
>> If you need both qualified and unqualified entity in the same
>> project, then the more I think about it the more I am convinced
>> that a solution is to map this as two entities.
>
> What about what I suggested before? i.e., the delegate option (or
> something similar) where you can optionally inject an auxiliary
> expression and/or orderings (if null) for each query. Mapping
> separate entities sounds like it would make it difficult to re-use
> existing logic for an entity.
>
> e.g., by default a fetch of objects would apply a restricting
> qualifier (e.g., for public viewing) but the background service I'm
> working on picks up a list of records that were committed and seeks
> to operate on them even if they were marked as deleted.
>
> with regards,
> --
>
> Lachlan Deck
>
>
Re: restricting qualifiers turned off?
Posted by Mike Kienenberger <mk...@gmail.com>.
On Tue, Nov 11, 2008 at 8:45 AM, Lachlan Deck <la...@gmail.com> wrote:
> What about what I suggested before? i.e., the delegate option (or something
> similar) where you can optionally inject an auxiliary expression and/or
> orderings (if null) for each query. Mapping separate entities sounds like it
> would make it difficult to re-use existing logic for an entity.
>
> e.g., by default a fetch of objects would apply a restricting qualifier
> (e.g., for public viewing) but the background service I'm working on picks
> up a list of records that were committed and seeks to operate on them even
> if they were marked as deleted.
DataContext Delegation is how restricting qualifiers originally could
be implemented in Cayenne 1.1. You could override
willPerformSelect() to modify the query.
public GenericSelectQuery willPerformSelect(DataContext dataContext,
GenericSelectQuery genericSelectQuery)
That allowed you to be able to turn them on and off at will, as well
as change the restricting qualifier.
I think there are a large enough set of us who need the "record is
marked as deleted" functionality that the framework should make it
easy for us to handle these cases.
I know in my own particular case, there's only one exception where I
disable the restricting qualifier, then re-enable it.
I see Andrus just posted something similar while I was writing this --
not surprising since Andrus helped me with the original implementation
years back. I can post the class I have for Cayenne 1.1 to give some
ideas, although there's a known race condition in how I've implemented
it. The way I did it also requires that the restricting qualifier be
specified in code, although there's no reason why it couldn't be done
another way.
Re: restricting qualifiers turned off?
Posted by Lachlan Deck <la...@gmail.com>.
On 11/11/2008, at 11:42 PM, Andrus Adamchik wrote:
> On Nov 11, 2008, at 2:30 PM, Lachlan Deck wrote:
>
>> Yeah and should you share that model in a framework/lib between
>> more than one app it really needs to be optional.
>
> I really don't see how you can make it "optional". Entity qualifier
> is not optional by design. It is either mapped or not.
That's what I meant. Applied instead by some means during ObjEntity
registration during app launch. I'm not aware of what hooks are
available for this purpose in Cayenne. But I'd prefer to pull them out
if the below suggestion was available instead.
> I have a solution in mind for the "library" case - smart mapping
> overrides. So that a piece of shared mapping could be modified as
> needed by the downstream users, with full reuse of the library
> mapping. I started developing that as I needed to customize
> listeners per project, but I am sure it can be put to good use in
> many other cases.
>
> If you need both qualified and unqualified entity in the same
> project, then the more I think about it the more I am convinced that
> a solution is to map this as two entities.
What about what I suggested before? i.e., the delegate option (or
something similar) where you can optionally inject an auxiliary
expression and/or orderings (if null) for each query. Mapping separate
entities sounds like it would make it difficult to re-use existing
logic for an entity.
e.g., by default a fetch of objects would apply a restricting
qualifier (e.g., for public viewing) but the background service I'm
working on picks up a list of records that were committed and seeks to
operate on them even if they were marked as deleted.
with regards,
--
Lachlan Deck
Re: restricting qualifiers turned off?
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 11, 2008, at 2:30 PM, Lachlan Deck wrote:
> Yeah and should you share that model in a framework/lib between more
> than one app it really needs to be optional.
I really don't see how you can make it "optional". Entity qualifier is
not optional by design. It is either mapped or not.
I have a solution in mind for the "library" case - smart mapping
overrides. So that a piece of shared mapping could be modified as
needed by the downstream users, with full reuse of the library
mapping. I started developing that as I needed to customize listeners
per project, but I am sure it can be put to good use in many other
cases.
If you need both qualified and unqualified entity in the same project,
then the more I think about it the more I am convinced that a solution
is to map this as two entities.
Andrus
Re: restricting qualifiers turned off?
Posted by Lachlan Deck <la...@gmail.com>.
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 <la...@gmail.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
Re: restricting qualifiers turned off?
Posted by Lachlan Deck <la...@gmail.com>.
Hi there,
any input?
On 29/04/2009, at 3:16 PM, Lachlan Deck wrote:
> Resurrecting this thread...
>
> On 12/11/2008, at 1:57 AM, Andrey Razumovsky wrote:
>
>> Thanks, it works! Here's the snippet:
>>
>> String cloneName = objEntity.getName() + "_no_qualifier";
>> ObjEntity clone = dataMap.getObjEntity(cloneName);
>> if (clone == null) {
>> clone = new ObjEntity(cloneName);
>> clone.setDbEntity(objEntity.getDbEntity());
>> objEntity.getDataMap().addObjEntity(clone);
>> }
>>
>> Works on every Cayenne
>
> Isn't there more to it than this?
>
> What javaClass are you mapping to? I didn't think the cloned
> objentity could map to the same java class (given that the map
> allows you to look up via javaclass). And what about
> relationships .. do you need to recursively re-define relations so
> that they also map to a similarly cloned entity?
>
> I'm about to attempt to do this as listed below[1] .. so any
> feedback welcome.
>
>> 2008/11/11, Andrus Adamchik <an...@objectstyle.org>:
>>> On Nov 11, 2008, at 2:15 PM, Andrey Razumovsky wrote:
>>>
>>> ObjEntity clone = (ObjEntity) SerializationUtils.clone(objEntity);
>>>> clone.setDeclaredQualifier(null);
>>>> SelectQuery query = new SelectQuery(clone);
>>>>
>>>
>>> In addition you'll need to rename the entity and register it with
>>> the
>>> DataMap. So you might as well map an alt. entity via the Modeler.
>>>
>>> Or use a separate stack all together to work with a parallel set of
>>> entities without qualifiers.
>
> Andrus, any clues on how one goes about creating a separate stack?
i.e., at runtime...
> Is there a simple way of finding the default stack and cloning it so
> as to recurse through the entities to turn off the declared qual?
>
> with regards,
> --
>
> Lachlan Deck
>
> [1] any improvements welcome...
>
> private static synchronized ObjEntity
> registeredNonRestrictingForObjEntity(DataMap map, ObjEntity
> originalEntity) {
> String cloneName = originalEntity.getName() + "_nonRestricting";
> ObjEntity cloneEntity = map.getObjEntity(cloneName);
> if (cloneEntity == null) {
> cloneEntity = new ObjEntity(cloneName);
> cloneEntity.setDbEntity(originalEntity.getDbEntity());
> cloneEntity.setDeclaredQualifier(null);
> cloneEntity.setClassName(originalEntity.getClassName() +
> "$NonRestricting");
>
> // define attributes
> cloneEntity.clearAttributes();
> for (Entry<String, ObjAttribute> attribute :
> originalEntity.getAttributeMap().entrySet()) {
> ObjAttribute att = (ObjAttribute)
> SerializationUtils.clone(attribute.getValue());
> att.setEntity(cloneEntity);
> cloneEntity.addAttribute(att);
> }
>
> map.addObjEntity(cloneEntity);
>
> // define relations
> cloneEntity.clearRelationships();
> SortedMap<String, ObjRelationship> relations =
> cloneEntity.getRelationshipMap();
> if (relations != null) {
> for (Entry<String, ObjRelationship> relation :
> relations.entrySet()) {
> ObjRelationship rel = relation.getValue();
> ObjEntity targetEntity =
> registeredNonRestrictingForObjEntity(map, (ObjEntity)
> relation.getValue().getTargetEntity());
>
> ObjRelationship relationClone = (ObjRelationship)
> SerializationUtils.clone(rel);
> relationClone.setTargetEntity(targetEntity);
> cloneEntity.removeRelationship(relation.getKey());
> cloneEntity.addRelationship(relationClone);
> }
> }
> }
> return cloneEntity;
> }
>
with regards,
--
Lachlan Deck
Re: restricting qualifiers turned off?
Posted by Andrey Razumovsky <ra...@gmail.com>.
Well, that code has changed since then :) Currently I do the following (much
like your code)
String cloneName = objEntity.getName() + OBJENTITY_POSTFIX;
ObjEntity clone = dataMap.getObjEntity(cloneName);
if (clone == null) {
clone = new ObjEntity(cloneName);
clone.setDbEntity(objEntity.getDbEntity());
clone.setClassName(objEntity.getClassName());
for (ObjAttribute attr : objEntity.getAttributes()) {
ObjAttribute attrClone = new
ObjAttribute(attr.getName());
attrClone.setDbAttributePath(attr.getDbAttributePath());
clone.addAttribute(attrClone);
}
for (ObjRelationship rel : objEntity.getRelationships())
{
ObjRelationship relClone = new
ObjRelationship(rel.getName());
relClone.setSourceEntity(rel.getSourceEntity());
relClone.setTargetEntity(rel.getTargetEntity());
relClone.setDbRelationshipPath(rel.getDbRelationshipPath());
clone.addRelationship(relClone);
}
objEntity.getDataMap().addObjEntity(clone);
}
That *almost* works. It fails when other thread is trying to perform query
with root=ObjEntity's CDO class (because two entities are mapped to same
class). I'm fine with this implementation by now. But ideally you need to
clone whole DataMap.
2009/4/29 Lachlan Deck <la...@gmail.com>
> Resurrecting this thread...
>
> On 12/11/2008, at 1:57 AM, Andrey Razumovsky wrote:
>
> Thanks, it works! Here's the snippet:
>>
>> String cloneName = objEntity.getName() + "_no_qualifier";
>> ObjEntity clone = dataMap.getObjEntity(cloneName);
>> if (clone == null) {
>> clone = new ObjEntity(cloneName);
>> clone.setDbEntity(objEntity.getDbEntity());
>> objEntity.getDataMap().addObjEntity(clone);
>> }
>>
>> Works on every Cayenne
>>
>
> Isn't there more to it than this?
>
> What javaClass are you mapping to? I didn't think the cloned objentity
> could map to the same java class (given that the map allows you to look up
> via javaclass). And what about relationships .. do you need to recursively
> re-define relations so that they also map to a similarly cloned entity?
>
> I'm about to attempt to do this as listed below[1] .. so any feedback
> welcome.
>
> 2008/11/11, Andrus Adamchik <an...@objectstyle.org>:
>>
>>> On Nov 11, 2008, at 2:15 PM, Andrey Razumovsky wrote:
>>>
>>> ObjEntity clone = (ObjEntity) SerializationUtils.clone(objEntity);
>>>
>>>> clone.setDeclaredQualifier(null);
>>>> SelectQuery query = new SelectQuery(clone);
>>>>
>>>>
>>> In addition you'll need to rename the entity and register it with the
>>> DataMap. So you might as well map an alt. entity via the Modeler.
>>>
>>> Or use a separate stack all together to work with a parallel set of
>>> entities without qualifiers.
>>>
>>
> Andrus, any clues on how one goes about creating a separate stack? Is there
> a simple way of finding the default stack and cloning it so as to recurse
> through the entities to turn off the declared qual?
>
> with regards,
> --
>
> Lachlan Deck
>
> [1] any improvements welcome...
>
> private static synchronized ObjEntity
> registeredNonRestrictingForObjEntity(DataMap map, ObjEntity originalEntity)
> {
> String cloneName = originalEntity.getName() + "_nonRestricting";
> ObjEntity cloneEntity = map.getObjEntity(cloneName);
> if (cloneEntity == null) {
> cloneEntity = new ObjEntity(cloneName);
> cloneEntity.setDbEntity(originalEntity.getDbEntity());
> cloneEntity.setDeclaredQualifier(null);
> cloneEntity.setClassName(originalEntity.getClassName() +
> "$NonRestricting");
>
> // define attributes
> cloneEntity.clearAttributes();
> for (Entry<String, ObjAttribute> attribute :
> originalEntity.getAttributeMap().entrySet()) {
> ObjAttribute att = (ObjAttribute)
> SerializationUtils.clone(attribute.getValue());
> att.setEntity(cloneEntity);
> cloneEntity.addAttribute(att);
> }
>
> map.addObjEntity(cloneEntity);
>
> // define relations
> cloneEntity.clearRelationships();
> SortedMap<String, ObjRelationship> relations =
> cloneEntity.getRelationshipMap();
> if (relations != null) {
> for (Entry<String, ObjRelationship> relation :
> relations.entrySet()) {
> ObjRelationship rel = relation.getValue();
> ObjEntity targetEntity =
> registeredNonRestrictingForObjEntity(map, (ObjEntity)
> relation.getValue().getTargetEntity());
>
> ObjRelationship relationClone =
> (ObjRelationship) SerializationUtils.clone(rel);
> relationClone.setTargetEntity(targetEntity);
>
> cloneEntity.removeRelationship(relation.getKey());
> cloneEntity.addRelationship(relationClone);
> }
> }
> }
> return cloneEntity;
> }
>
>
Re: restricting qualifiers turned off?
Posted by Lachlan Deck <la...@gmail.com>.
Resurrecting this thread...
On 12/11/2008, at 1:57 AM, Andrey Razumovsky wrote:
> Thanks, it works! Here's the snippet:
>
> String cloneName = objEntity.getName() + "_no_qualifier";
> ObjEntity clone = dataMap.getObjEntity(cloneName);
> if (clone == null) {
> clone = new ObjEntity(cloneName);
> clone.setDbEntity(objEntity.getDbEntity());
> objEntity.getDataMap().addObjEntity(clone);
> }
>
> Works on every Cayenne
Isn't there more to it than this?
What javaClass are you mapping to? I didn't think the cloned objentity
could map to the same java class (given that the map allows you to
look up via javaclass). And what about relationships .. do you need to
recursively re-define relations so that they also map to a similarly
cloned entity?
I'm about to attempt to do this as listed below[1] .. so any feedback
welcome.
> 2008/11/11, Andrus Adamchik <an...@objectstyle.org>:
>> On Nov 11, 2008, at 2:15 PM, Andrey Razumovsky wrote:
>>
>> ObjEntity clone = (ObjEntity) SerializationUtils.clone(objEntity);
>>> clone.setDeclaredQualifier(null);
>>> SelectQuery query = new SelectQuery(clone);
>>>
>>
>> In addition you'll need to rename the entity and register it with the
>> DataMap. So you might as well map an alt. entity via the Modeler.
>>
>> Or use a separate stack all together to work with a parallel set of
>> entities without qualifiers.
Andrus, any clues on how one goes about creating a separate stack? Is
there a simple way of finding the default stack and cloning it so as
to recurse through the entities to turn off the declared qual?
with regards,
--
Lachlan Deck
[1] any improvements welcome...
private static synchronized ObjEntity
registeredNonRestrictingForObjEntity(DataMap map, ObjEntity
originalEntity) {
String cloneName = originalEntity.getName() + "_nonRestricting";
ObjEntity cloneEntity = map.getObjEntity(cloneName);
if (cloneEntity == null) {
cloneEntity = new ObjEntity(cloneName);
cloneEntity.setDbEntity(originalEntity.getDbEntity());
cloneEntity.setDeclaredQualifier(null);
cloneEntity.setClassName(originalEntity.getClassName() +
"$NonRestricting");
// define attributes
cloneEntity.clearAttributes();
for (Entry<String, ObjAttribute> attribute :
originalEntity.getAttributeMap().entrySet()) {
ObjAttribute att = (ObjAttribute)
SerializationUtils.clone(attribute.getValue());
att.setEntity(cloneEntity);
cloneEntity.addAttribute(att);
}
map.addObjEntity(cloneEntity);
// define relations
cloneEntity.clearRelationships();
SortedMap<String, ObjRelationship> relations =
cloneEntity.getRelationshipMap();
if (relations != null) {
for (Entry<String, ObjRelationship> relation :
relations.entrySet()) {
ObjRelationship rel = relation.getValue();
ObjEntity targetEntity = registeredNonRestrictingForObjEntity(map,
(ObjEntity) relation.getValue().getTargetEntity());
ObjRelationship relationClone = (ObjRelationship)
SerializationUtils.clone(rel);
relationClone.setTargetEntity(targetEntity);
cloneEntity.removeRelationship(relation.getKey());
cloneEntity.addRelationship(relationClone);
}
}
}
return cloneEntity;
}
Re: restricting qualifiers turned off?
Posted by Andrey Razumovsky <ra...@gmail.com>.
Thanks, it works! Here's the snippet:
String cloneName = objEntity.getName() + "_no_qualifier";
ObjEntity clone = dataMap.getObjEntity(cloneName);
if (clone == null) {
clone = new ObjEntity(cloneName);
clone.setDbEntity(objEntity.getDbEntity());
objEntity.getDataMap().addObjEntity(clone);
}
Works on every Cayenne
2008/11/11, Andrus Adamchik <an...@objectstyle.org>:
>
>
> On Nov 11, 2008, at 2:15 PM, Andrey Razumovsky wrote:
>
> ObjEntity clone = (ObjEntity) SerializationUtils.clone(objEntity);
>> clone.setDeclaredQualifier(null);
>> SelectQuery query = new SelectQuery(clone);
>>
>
> In addition you'll need to rename the entity and register it with the
> DataMap. So you might as well map an alt. entity via the Modeler.
>
> Or use a separate stack all together to work with a parallel set of
> entities without qualifiers.
>
> Andrus
>
>
>
>
>
Re: restricting qualifiers turned off?
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 11, 2008, at 2:15 PM, Andrey Razumovsky wrote:
> ObjEntity clone = (ObjEntity) SerializationUtils.clone(objEntity);
> clone.setDeclaredQualifier(null);
> SelectQuery query = new SelectQuery(clone);
In addition you'll need to rename the entity and register it with the
DataMap. So you might as well map an alt. entity via the Modeler.
Or use a separate stack all together to work with a parallel set of
entities without qualifiers.
Andrus
Re: restricting qualifiers turned off?
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 11/11/2008, at 11:15 PM, Andrey Razumovsky wrote:
> BTW this thing will only work on the trunk, because Cay entities are
> made
> serializable in CAY-1080 and not in M4.
> I have qualifiers in all tables (deleted="0", as I've already
> explained
> somewhere). But sometimes I will need all records, even deleted ones.
That's exactly the same use-case for us, and I assume for what Lachlan
is working on now. In almost every place we want to suppress selecting
deleted records... except when we don't. Perhaps we could copy the
entire model and switch in a model without qualifiers when we need it?
Whatever the solution, disabling qualifiers could be a little bit of
trouble since it isn't something you want to do without the
programming equivalent of "are you really sure you want to do this?".
For this reason, having deleted="0" in the model is better than
remembering to add it to all select expressions, following relations,
etc.
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: restricting qualifiers turned off?
Posted by Andrey Razumovsky <ra...@gmail.com>.
No error, but qualifier is still inserted. I've had no time yet to
insvestigate. I'm doing this:
ObjEntity clone = (ObjEntity) SerializationUtils.clone(objEntity);
clone.setDeclaredQualifier(null);
SelectQuery query = new SelectQuery(clone);
...
BTW this thing will only work on the trunk, because Cay entities are made
serializable in CAY-1080 and not in M4.
I have qualifiers in all tables (deleted="0", as I've already explained
somewhere). But sometimes I will need all records, even deleted ones.
2008/11/11, Andrus Adamchik <an...@objectstyle.org>:
>
> 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. 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?
>
> Andrus
>
>
> 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.
>>
>> 2008/11/11, Lachlan Deck <la...@gmail.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
>>>
>>>
>>>
>>>
>>>
>
Re: restricting qualifiers turned off?
Posted by Andrus Adamchik <an...@objectstyle.org>.
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. 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?
Andrus
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.
>
> 2008/11/11, Lachlan Deck <la...@gmail.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
>>
>>
>>
>>
Re: restricting qualifiers turned off?
Posted by Andrey Razumovsky <ra...@gmail.com>.
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.
2008/11/11, Lachlan Deck <la...@gmail.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
>
>
>
>