Feature Request: indexOn nested key.

[Tom]

I would like to request the ability to create an index for nested keys such as: "users/$user", where users is an array of user_id's as keys, with true as values. This allows for filtering a list of items by a common child users/{uid}.

Currently the docs explain a many to many relationship should be stored in both locations and be resolved as shown here. This example however does not take value changes on the related model into account (I do understand that using on('value') resolves this, but this feels like overkill for the server). It is currently possible to 'abuse' orderByChild('users/' + uid).equalTo(true) to achieve similar behavior while keeping the data stored in one location, and not breaking live updates on the related values. This however throws a warning to 'Consider adding ".indexOn": "users/12346789-1234-1234-1234-123456789012"'.

[Kato Richardson]

Hi Tom,

Most likely, you’ll need to work on some flattened data structures, and maybe duplicate a bit of data to get this working. It’s hard to guess without a detailed use case and sample data structures (you’ve provided the Y of the XY Problem in your question, but not the goal and constraints you’re trying to meet).

Note that queries can use a nested child as the value, such as orderByChild('foo/bar/baz') (see here), but not a wildcard, such as /users/*/some/field. You can often achieve similar results with an index and some joining.

☼, Kato

​

On Fri, Apr 22, 2016 at 4:26 AM, Tom <tom_de...@hotmail.com> wrote:

I would like to request the ability to create an index for nested keys such as: "users/$user", where users is an array of user_id's as keys, with true as values. This allows for filtering a list of items by a common child users/{uid}.

Currently the docs explain a many to many relationship should be stored in both locations and be resolved as shown here. This example however does not take value changes on the related model into account (I do understand that using on('value') resolves this, but this feels like overkill for the server). It is currently possible to 'abuse' orderByChild('users/' + uid).equalTo(true) to achieve similar behavior while keeping the data stored in one location, and not breaking live updates on the related values. This however throws a warning to 'Consider adding ".indexOn": "users/12346789-1234-1234-1234-123456789012"'.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/62633d0b-7c89-48ef-8111-b84925a34a8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398