Filter on level 2 properties

[daankets]

I am trying to use the ?filter rest method, in order to query on nested properties. However, this doesn't seem to work:

/someResource?filter[where][field.subField][like]=abc

neither does this (which I think is wrong anyway):

/someResource?filter[where][field][subField][like]=abc

Any hints?

[fabien]

Which connector are you using?

[daankets]

Memory in dev, mongo in test and beyond. It's the memory connector that has the issues. We use this one for our dev setup as it resets upon restart...

It's the 'dot' notation that is working with mongo.

[fabien]

This is currently a limitation of the memory connector.

@raymondfeng perhaps we can use something like https://github.com/logicalparadox/filtr or https://github.com/crcn/sift.js to enable this

[daankets]

Well, the nice thing about the memory connector is that it resets, so you test every run with a clean sheet. And of course it's rather speedy ;-)

[fabien]

Of course - however, you can easily reset the test database before you start, like this:

app.datasources['db'].automigrate(next);

[daankets]

Will this drop the entire schema?

[fabien]

Yes, but in the case of MongoDB collections will be empties and indexes re-created. There's no real schema, like with SQL databases.

[daankets]

Sure. Just calling it a 'schema' as a 'habit'

[fabien]

Of course! While collections are being recreated, they are not really removed from the database first. So any obsolete collections will stay around, until you delete them, or the database itself. AFAIK loopback will create the db for you, in case it doesn't exist.

[raymondfeng]

@fabien These libraries are interesting:

• https://github.com/logicalparadox/filtr
• https://github.com/crcn/sift.js

I also looked at:

• https://github.com/louischatriot/nedb

Keep in mind, RDBs won't support nested queries.

[fabien]

@raymondfeng sift.js looks good to me, but it doesn't support skip/limit. nedb does, but it seems quite a bit more involved. It can probably be implemented as a new connector altogether.

Users should be made aware of the limits of RDBM's, which is perhaps easiest when having this as a separate connector - so users have to be explicit about it, instead of relying on the memory connector (for tests and so forth) to support any type (both SQL as well as NoSQL style) of query. It's probably easy to copy the mongodb connector's query normalization code and implement this.

Here are some more libraries of interest:

• https://github.com/kawanet/obop
• http://kawanet.github.io/kagodb/
• https://github.com/sergeyksv/tingodb (but why use this, over mongodb?)
• https://github.com/bevry/query-engine (nevermind, too heavy)

[bajtos]

Loosely related: #683 How can i set condition where on include model

[yagobski]

How this can work for mysql connector? I have same issue

[stringbeans]

Looks like Loopback currently does not support nested include filtering. This seems like a huge limitation. I don't believe the db connector should make any difference because ideally the Loopback framework would work the same regardless of what db connector you're using

[weslley39]

i'm having the same problem trying to do a nested include. Any solution ?

[GameScripting]

So are there any plans to support nested properties? Is there any way to get the "native" mongodb-connection so we can query the database without the loopback abstraction?

[dominikriedel]

Hey! I've got the Same Problem. I want to query a List of objects based on the property of an related model as well as the property of the wanted model e.g:

Event.find( { where: { and: [ { endDate : { lt : givenDate}}, { location.name : "Abc" }]} }, cb );

So, am I right, that this is not supported atm?

[bajtos]

I want to query a List of objects based on the property of an related model as well as the property of the wanted model. So, am I right, that this is not supported atm?

You are right, this it not supported yet.

[dominikriedel]

so the easiest way would be to just query via SQL? Without any further knowlage: is there any caching mechanism I could use?

[pungoyal]

Can we upvote on this feature?

[bajtos]

Sure, leave a comment containing one of :+1: or +1 (as regular text, not like I did).

[pungoyal]

:+1:

[Jeff-Lewis]

+1

[GameScripting]

+1

[weslley39]

+1

[violet-day]

:+1:

[manlito]

+1

[stringbeans]

+1

[jsam]

+1

[mrbatista]

+1

[raymondfeng]

I guess we can make it happen for NoSQL DBs, but it will be difficult for RDBs.

[rabchev]

+1

[bajtos]

As far as I am concerned, a good start would be to support nested filters for embedded objects and embedded models.

[johnsoftek]

+1

[hotaru355]

+1

[yagobski]

+1

[AurelieV]

+1

[jbeurel]

+1

[wxqp]

+1

[osunacons]

+1

[bajtos]

What databases are you using? Is it enough to support filtering on second-level properties for memory and MongoDB, or do you need it for SQL databases too?

[bajtos]

https://github.com/strongloop/loopback-datasource-juggler/pull/544 is adding support for dot-notation to the memory connector, to make it consistent with MongoDB.

This should hopefully fix the issue for @daankets as described in his earlier comment:

Memory in dev, mongo in test and beyond. It's the memory connector that has the issues. We use this one for our dev setup as it resets upon restart... It's the 'dot' notation that is working with mongo.

Implementing this feature for non-embedded relations (e.g. hasMany, belongsTo) and supporting SQL connectors (both embedded and non-embedded relations) requires significant amount of time, which we can't invest right now.

[mattiaaccornero]

+1

[daankets]

Thanks for this! It's making testing quite a bit easier ;-)

[sisardor]

+1

[eugenehp]

:+1:

[erikverheij]

+1

I really love the way PHP's Doctrine ORM has implemented this feature. For some databases filtering takes place on the database level. When a specific database connector does not support the filtering interface Doctrine does the filtering for you using PHP.

http://doctrine-orm.readthedocs.org/en/latest/reference/working-with-associations.html#filtering-collections

I understand it would take a lot of time to provide this feature for all databases, so perhaps it is an option to adapt such a pattern.

[jasiedu]

+1

[jgpacheco]

+1

[bryannaegele]

:+1: