Implicit And not added when parsing

[mfzl]

When I do quick query such as below:

{ id: "some-id", tag: "some-tag" }

Parsed expressions does not have an implicit And added. Is it suppose to be this way?

This test case: {"$and": [{"foo": "bar"}, {"foo": "baz"}]} Query{Equal{Field: "foo", Value: "bar"}, Equal{Field: "foo", Value: "baz"}}

Shouldn't it be: Query{And{Equal{Field: "foo", Value: "bar"}, Equal{Field: "foo", Value: "baz"}}}

Looks like implicit And as documentation says is added to sub expressions only.

I'm trying to implement an SQL storage layer and reference sqlite implementation also breaks with the above example.

[rs]

Yes, this is expected. The Query itself to be treated as a And.

[mfzl]

Understood. I think it maybe a good idea to add that to sqlite library when there is more than one root expressions.

[rs]

I don't maintain the sqlite library but yes, it sounds like a good idea.

Regarding your work on SQL storage implementation, @smyrman was also talking about working on something like that. It might be interesting to join forces.

I was thinking about adding a flexible query.Query to SQL conversion package to rest-layer itself that could be used by the different SQL based storers. As each engine might require a slightly different SQL produced, this might be easier said than done. I would be interested in discussing what those differences would be and if you guys think such helper package would be useful.

[smyrman]

I was thinking about adding a flexible query.Query to SQL conversion package to rest-layer itself that could be used by the different SQL based storers.

That would be awesome.

[mfzl]

I'm not making a general storage layer that is compatible with rest-layer as I don't use rest-layer's REST API. I'm trying to add filters using rest-layer's filter DSL to an existing non-rest-layer API. Sorry for the confusion there.

For now I'm working based on SQLite's translateQuery with a small modification to use placeholders instead of using actual values and returning the Values as a slice from translateQuery.

[smyrman]

@faxal, you might want to be aware of #115, which is implementing a move of query logic from schema -> schema/query, with some other improvements as well.

If you want to share any of your work with us at some point, in some form, that would be most welcome.

[rs]

Are you using the resource package? All rest-layer packages are decoupled. You can use the resource package and all its compatible storers with the schema and query package independently from the rest package. The graphql experiment is a good example of that.

[mfzl]

@smyrman Thanks for the heads up, I didn't see it before. That is a great change. Only reason I'm using resource package is to use it's Lookup functionality.

@rs I'm using the resource package, specifically resource.Lookup and schema for validation of filters. I didn't have to touch rest package, which is great. Hopefully I won't have to touch resource package too after #115

I'll definitely share If I do anything interesting that isn't already here.