Returning whole resource, along with its sub-resouce

[Dragomir-Ivanov]

Right now, having a query:
api/shema/[id] works and returns all fields without the referrers
api/shema/[id]?fields=id,name,sub works and returns id and name of the shema resource and its sub sub-resource.

The problem is that we can't have both. Would like to return all the fields of the schema without specifing them one by one. Something like:
api/shema/[id]?fields=*,sub

[Dragomir-Ivanov]

However there is a deeper issue I think. Trying to get multiple sub-resources and selecting its fields on each of them, doesn't work as expected.

My concrete example:

GET http://192.168.0.103:3001/api/clients/59a962a5eaba9ebd0180ac67?fields=id,name,address,telephones,notes,visits,services{id,createdDT,status,name,zipCode,insuraceCompany,workOrder,ownOrder},appliances

, doesn't filter the fields of the services. If I remove the appliances sub-resource, it filters them.

[smyrman]

If I remove the appliances sub-resource, it filters them

This sounds like a bug. Do you mind raise this as a separate issue?

[Dragomir-Ivanov]

@smyrman In a second. Can you look at issue #123 and test this at your side. It might be real after all.

[smyrman]

#148 raised to deal with the buggy part.

This issue will deal with how to return whole resource, along with expanded fields for sub-resouce(s), without having to list all resource fields.

[Dragomir-Ivanov]

PR #155

[Dragomir-Ivanov]

Guys I want to revive discussion on this topic. I did a PR #155 about it, however we didn't agreed on solution, so it got stale. I don't want anything fancy, just want to have a way to get all fields of resource/sub-resource. My motivation is as follows:

1. Development speed. It is more convenient to say ?fields=*,reference{*} than manually adding each new field you add to resources during development sprints.
2. Since ?fields=reference{} doesn't work, rest-layer returns error ParseProjection unexpected error: looking for field name at char 10, client of the REST API doesn't have a way to know the shape of reference resource. This can be a real bumper, especially of lacking docs and if reference resource is not accessible from index but only used as sub-resource.

I have a private patch that seems to work, and it allows queries like these:

?fields=*,reference{*}
?fields=*,n:name        // This will return both name and n, as alias to name
?fields=reference{*}(filter:{name:"foo"}}
?fields=reference{*,user{*}}

I want to make this right, so no rush. In the meantime I will use mine patch.
Your input appreciated.

[smyrman]

I think your way of handling it makes sense to me. Just to clarify; I assume reference in your example is meant to be a field-name.

I want to raise though, that I think the most useful use-case or a * expansion, would be to allow expanding references in a map where all the fields can't necessarily be known in advance. E.g. consider a field:

"refmap": `{
    Validator: &schema.Dict{
        Value:schema.Field{
            Validator: schema.Reference{Path: "foo"},
        },
}

It would be good for that case to be handled when implementing this, if possible.

[Dragomir-Ivanov]

Thanks for the response Sindre. However I have no experience with schema.Dict and schema.Object and don't quite understand what the snipped above accomplishes. Perhaps you can make some small real live examples that I can try understand, and try to use them as test cases.

[smyrman]

Given an existing resource foo with an id and a name field, consider another resource bar with schema:

barSchmea := &schema.Schema{
    Fields: schema.Fields{
        "id": schema.IDField,
        "refmap": `{
            Validator: &schema.Dict{
                Values: schema.Field{
                    Validator: schema.Reference{Path: "foo"},
                },
        },
}

Now we should be allowed to upload documents with arbitrary keys in the "refmap" field, and references to the "foo" resource as values. E.g.

{"refmap":{"x": "1", "y": "2"} }

Now, there would be nice if there was a way to embed the linked foo resources without knowing the field names in all documents. E.g. GET /bar?filelds=refmap{*} giving:

{"refmap":{"x": {"id":"1", "name": "foo1"}, "y":  {"id":"2", "name": "foo2"}}}

[Dragomir-Ivanov]

@smyrman Does the code snipped you showed above works with latest rest-layer? It seems that schema.Reference in schema.Dict doesn't expand with:

GET /bar?filelds=refmap{x,y}

[smyrman]

Probably doesn't work to expand. We use a field handler parameter ourselves as a workaround.

You could try refmap.x to see if that works. It may depend on weather expansion is utilizing the FieldGetter interface.

Just thought I would mention the use-case, but it's also perfectly reasonable to leave such support for a different PR.