Duplicated. Kinda odd as well. Looks like the placement is in the wrong place as you mentioned.

This predicate as suggest in the initial report works and has the correct placement for @allvalues

let subquery = NSPredicate(format: "SUBQUERY(flags.@allValues, $flag, $flag.isLoud == true).@count == 3", "")

from realm-swift.

➤ PM Bot commented:

Jira ticket: RCOCOA-2412

from realm-swift.

Updated the issue with a more concise summary.

An Aside:

It would be nice if the Realm Query Syntax API were smart enough to add == true when required. My initial query was:

($0.flags.values.isLoud).count > 0

The compiler showed no errors here, but at runtime the resulting predicate failed to parse and it took me a minute to realize why, since the other issue with @allValues misplacement happened simultaneously. I think most Swift developers don't write == true when evaluating a boolean, so that habit carries over into the query syntax and it'll bite you. If possible, Realm should consider adding handling for that or a more explicit warning about the footgun.

from realm-swift.

I am not exactly sure what the expected result is so let me take a crack at it.

Looking at the code - it appears the goal is to return all Bar objects where the flags Map property contains isLoud == true.

Allow me to set up a test case

let f0 = Flag()
f0.isLoud = false

let f1 = Flag()
f1.isLoud = true

let f2 = Flag()
f2.isLoud = false

let f3 = Flag()
f3.isLoud = false

let bar0 = Bar()
bar0.flags["a"] = f0
bar0.flags["b"] = f1 //f1.isLoud == true

let bar1 = Bar()
bar1.flags["c"] = f2
bar1.flags["d"] = f3

try! realm.write {
    realm.add(bar0)
    realm.add(bar1)
}

So the result here is that bar0's flags property "b" key contains value f1 where isLoud is true but bar1 (which contains f2 and f3, has no flags property where isLoud is true.

The goal is return bar0 since it has at least one flags property where isLoud == true

Doesn't this query solve that?

let results = realm.objects(Bar.self).where { $0.flags.values.isLoud == true }
print(results)

and the result is bar 0

Results<Bar> <0x151e3bd40> (
	[0] Bar {
		flags = Map<string, Flag> <0x6000014b5800> (
		[a]: Flag {
				isLoud = 0;
			},
		[b]: Flag {
				isLoud = 1;
			}
		);
	}
)

likewise if we change f2, which is in bar1 to have isLoud set to true, both bar0 and bar1 are returned.

let f2 = Flag()
f2.isLoud = true

I think the .count is extraneous in this case as any flags within a bar where isLoud == true will be returned. e.g. if the count was 0, it would not be returned because there is no isLoud == true.

Let me know if the desired result is different than my guess.

from realm-swift.

Perhaps I've not been clear.

Realm translates .where{} clauses into NSPredicate objects on-the-fly. It would appear that this translation layer is placing @allValues in the wrong spot.

Whether .count > 0 is strictly necessary is not the point. The point is that given the where{} clause above (which IS valid), the translation-on-the-fly layer is producing an invalid NSPredicate.

In other words, adding .count > 0 should not cause the translation layer to place @allValues where it is when a SUBQUERY is written by that translation layer.

(In my actual app, there's several parts to this query. I've narrowed it down to a simplified example.)

from realm-swift.

@Jaycyn here's another way to see the problem: suppose we wanted to fetch all Bar objects that have exactly 3 loud flags in their Map property.

Now .count == 3 is needed and you should be able to reproduce the bug I'm reporting here.

from realm-swift.