First of all, thanks a lot for the fantastic work on Eve & its sqlalchemy extension!
Would it not be great to have clients to the Eve endpoints also easily consume relationships without resorting to special views? The whole idea of Eve is to create the interface from the database definition isn't it?
Let's assume we have a client table with a relationship to projects, i.e. one-to-many. There are a couple of possibilities.
Ideally one would have an endpoint like /clients/10/projects for client with id==10 and that would drill down to /clients/10/projects/1 etc. Vice versa the endpoint projects/1/clients/10. This is already implemented somewhat in Eve itself, possibly only for the dict engine specified in DOMAIN with the url syntax. Perhaps hooking it there would be straightforward.
Another approach where the related links would be exposed through an HATEOAS type of approach would also work for me. When the result is a single element, like after /clients/10, links to child projects, and the parent client, could be added as a list to an HATEOAS element.
Something that is already somewhat implemented: a simple list of identifiers. I have seen that the backref link from an orm is made available as its identifier (like "parent_id": 10,) in the GET response. It makes sense because the backref is defined as a real column in the reflection engine. The other the other direction is left out. This might actually be the easiest way?
Of course functionality should be configureable as I understand that the orm approach can be slow and resourceful.
First of all, thanks a lot for the fantastic work on Eve & its sqlalchemy extension!
Would it not be great to have clients to the Eve endpoints also easily consume relationships without resorting to special views? The whole idea of Eve is to create the interface from the database definition isn't it?
Let's assume we have a client table with a relationship to projects, i.e. one-to-many. There are a couple of possibilities.
/clients/10/projectsfor client with id==10 and that would drill down to/clients/10/projects/1etc. Vice versa the endpointprojects/1/clients/10. This is already implemented somewhat in Eve itself, possibly only for thedictengine specified inDOMAINwith the url syntax. Perhaps hooking it there would be straightforward./clients/10, links to child projects, and the parent client, could be added as a list to an HATEOAS element."parent_id": 10,) in the GET response. It makes sense because the backref is defined as a real column in the reflection engine. The other the other direction is left out. This might actually be the easiest way?Of course functionality should be configureable as I understand that the orm approach can be slow and resourceful.
Thanks a lot for your consideration!
Best regards, Jeroen