I have an an entity containing two optional to-many relationships (childA <<-> parent <->> childB). Each of these two child entities contain an optional string that I am interested in querying on.
Using the same format, I get the results I expect for one, but not the other. I understand that means I don’t understand the tools I’m working with; and hoped for some insight. This is what the two queries look like:
childA.@count != 0 AND (0 == SUBQUERY(childA, $a, $a.string != NIL).@count)
childB.@count != 0 AND (0 == SUBQUERY(childB, $a, $a.string != NIL).@count)
I would expect to get back results from non-nil instances of both childA and childB only if each entity instances’ string is also nil. My question is, why would one give the results that I expect; while the other does not?
Clarification:
I’m trying to solve the general problem where I’m searching for one of two things. I’m either searching for a default value in an attribute. When the attribute is optional, I’m additionally searching for a nil attribute. The problem is further compounded when optional relationships’ should only be considered when the are populated. Without the relationship count != 0, I get back all parents with a nil relationship. In one case, this is the desired behavior. In another case, this appears to diminish the returned parent count (to 0 results).
For the optional attribute case, the query might look like:
parent.@count != 0 AND (parent.gender == -1) OR (parent.gender == NIL)
Where there are optional relationships in the key-paths, the query takes the form exemplified in the first example.
Again, I have gotten the results I have expected with all but one case, where there doesn’t seem to be anything unique to it’s relationships nor attribute characteristics. Or I should say, there’s nothing unique about this exception in data model structure or query format…
I understand the problem now.
In my case, it’s usually logical correct to first filter out NSSets with 0 count. But, in the problematic case, it’s logically correct to return the results of both NSSets with 0 count, and NSSets with > 0 count where the attribute is nil (when optional), or the attribute is set to its default value. In other words, in the problematic case, the left condition needs to be removed, resulting in the following format:
It seems I’ll need to have the managed objects indicate which scenario is appropriate on a case by case basis…yuk!