🚀 Feature: Intermediate Relationship support for Queries #7033
Comments
|
@mattie-cmsp, thanks for opening this issue! 🙏🏼 It looks like you're looking to perform a select query on a relationship. If so, it looks like we have this issue already. Perhaps you can 👍🏼 that issue and close this one as a duplicate? |
I did see that issue before reporting this one. The other issue stated in the reply from joeyouss, that querying on a relationship is not currently supported. And the docs state as much and that further support is planned. This feature request is proposing an interim form of support that requires less effort to develop, but wouldn't provide as feature rich of a form of support as that other issue would require. This FR would provide only the IDs of the related records, not the actual fields of the related objects. Without this feature, in order to pull, let's say, 5 fields of data for a user's request, I'm pulling 30 fields plus another 10 from a related child object, and another 10 from each of those related child objects relations, and one more set as that's my only option if I want to get at related records. With this FR, I would still need to issue a second set of query requests to get the related data for the related objects I need, but it would be a tiny fraction of the data I'm having to pull right now. A good example is when an app starts, my app currently needs to pull around 2 + 10 fields(one array of 10 related rows of IDs) for 38 rows of data, around 460 fields of data. However, as I can't query just the fields that I need(2 fields off the main table plus the related IDs), I'm having to pull well over 100 fields of data for 38 rows, so more like 4000 fields. To be clear, the solution to the other issue that was referenced, is superior, and more ideal than this FR. But this FR is meant to be a temporary(though compatibly permanent option) simple solution until the more complex features are completed. Below is a visualization of what a single object looks like with the current state of Appwrite, vs after my FR. As you can see, the current implementation requires pulling so much data that the visualization can't fit on the screen and still have readable text. While after the FR, we would have a much smaller dataset. We are talking 28 KB of data vs 590 B... (per record). With the current implementation it takes a little under 5 seconds to load all of that data. I expect this to take a fraction of a second after my FR. Without this FR: With this FR: |
|
To ensure we end up with a complete solution, it would be good to include your request in the existing request rather than have a separate issue. Also, for now, perhaps it would be best if you don't use a relationship attribute and only use an array of strings instead. |
Uh oh!
There was an error while loading. Please reload this page.
🔖 Feature description
Provide intermediate support for performing queries on relationships, by allowing query.select of the "$id" value found in the table relationship field, before full support for relationship queries is completed.
🎤 Pitch
While it is planned to add more support in to the Query functions for Relationships, now that they are in place in live environments, a very minor level of Query support could go a long way. I'm proposing allowing use of the Query.select function to include the name(id) of the relationship field on the appropriate object.
The Query would return the $id of the related object, which is what is found in the table field right now. This behavior should very closely mimic what was likely being done by most in previous version of AppWrite before relationship support, where most devs were likely storing the id's in a field in varying tables.
As is, the only way to get to related objects, is to not use a Select query, which will result in an up to 4 level deep object per row, being returned, which can mean a heck of a lot more data(and backend work) than is needed in many situations.
I expect this to be relatively simple to implement, (like, probably a line or two or less of code) and would be willing to work on a PR myself if no one with more knowledge on the codebase is willing to pop this one out.
Full relationship support in queries is almost certainly going to be a much larger and longer project to tackle, and we may be waiting for months, with no efficient way of querying relationships, without this feature.
I'm also going to propose a max_depth query as another possible solution, in a related FR: 7034
👀 Have you spent some time to check if this issue has been raised before?
🏢 Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: