polymerfire
polymerfire copied to clipboard
Ordered by child is not working for deeply nested children
Hi All,
I'm having an issue with firebase-query when using order-by-child, seems like it's not supporting order by deeply nested children. Firebase has that feature, refer 'Filtering by a specified child key' section in, https://firebase.google.com/docs/database/rest/retrieve-data.
But tried to query by ordering by deep nested child with equal-to as follows, but it didn't worked.
<firebase-query order-by-child="deepChildNodeName" equal-to="childNodeValue"></firebase-query>
Hi @ThilinaTCH is it working now? If it is not, can you provide us with a minimal repo to check? Thanks
I am having the same problem @tjmonsi
There was also another issue here on GitHub that mentioned equal-to working when the value is boolean and not with string - which is exactly what I encountered as well. Unfortunately I cannot find this thread right now.
Here is an example repository https://github.com/almirbi/firebase-query-test/blob/master/firebase-query-test.html
@almirbi can you try to define a Boolean property and bind it to equal-to?
Booleans work as I mentioned, when the equal-to is a string (or anything else), that's where the problem arises.
Does not work when bound to a property either. I already tried endless of possible combinations :)
Ok, just to be clear: it shouldn't work as given in the example. true !== 'true'
It is confusing because in the Polymer implementation, in the query element, we have query.equalTo(equalTo), while the actual Firebase query.equalTo expects two parameters, key and value. Not sure if the function was modified for the Polymer implementation or a bug.
Also why do we have to set orderByChild then? Should it maybe be something like
query.equalTo(orderByChild, equalTo) instead of query.equalTo(equalTo)
And I think Polymer drops off the string and passes null to __computeQuery function because the equalTo prop is defined as an object. Although that does not explain why 'true'/'false' is passed in as a boolean.
Ok, I've created a PR to somehow enhance the documentation for this property, it might help you understand what's going on: https://github.com/firebase/polymerfire/pull/320
equalTo does indeed accept two arguments, but the second one (key) is optional and currently not supported by the Polymerfire. It is used to specify a child key to start at, among the children with the previously specified priority. It's only allowed if ordering by child, value, or priority.
This element is insufficiently documented that is good. But the bug still remains.
Does this mean that Polymerfire does not support queries with equal-to as string?
It should still work when order-by-child is set even if the key parameter is unsupported.
This is a basic use case and makes polymerfire much less usable. Also, a 'true' string being passed in as a boolean also still sounds like a bug.
Oh, I get it now. I'll try to make a PR to fix this in the coming days, but it will need some discussion since it will most definitely be a breaking change. Unfortunately, there are some... troubles... with repo owners, so it can take months :(
Yes I thought the same - a breaking change is necessary. Alright, I need this now so I will fork the repo and make the fix there. I will probably use an object like
{
key: 'key',
value: 'value'
}
Hopefully this is something you will be able to use later.
Cheers
I think for having an equal-to to work, you should add order-by-child. Problem with having a value that is true in firebase is that it will not work on equal-to="true". I have to check the firebase-database.js behavior if it can take in a truth value for equalTo but if you want to check try just doing this <firebase-query order-by-child="someAttribute" equal-to> and see if it works out
As for order-by-child not working on deeply nested children. It will not. orderByChild only checks the direct child attribute of a given path.