Open novoj opened 1 month ago
This feature request partially opens up a path to a larger extension of the reference fetching enhancements. It would be also beneficial to be able to fetch only chunks of references. After discussion with @lukashornych we'd like to:
In order to do so, this language extension makes sense to us:
// returns only counts for product reference (no PKs or bodies are sent)
referenceCount('products')
// returns only counts for all entity references (no PKs or bodies are sent)
referenceCount()
// returns only counts for product reference that match filtering criteria in a custom order (no PKs or bodies are sent)
referenceCount('products', filterBy(...), orderBy(...))
// returns first page of 20 primary keys that match filtering criteria in a custom order
referenceContent('products', filterBy(...), orderBy(...), page(1, 20))
// returns first page of 20 referenced entities that match filtering criteria in a custom order
referenceContent('products', filterBy(...), orderBy(...), entityFetchAll(), page(1, 20))
We still need to analyze how this proposal affects the internal structure of EntityDecorator
and the connected APIs. This change would also affect all the APIs at once and would cover all our requirements.
After recent discussion with FE team using evitaDB, there may be use case were we want to fetch entity that has existing referenced entities of some type. On top of that however, we want to fetch count of these referenced entities without actually fetching the entities. Something like that:
I think it could be solved also with facet summary, probably like this:
But that's quite cumbersome to use on FE. @novoj do you think it would be valid to support the first approach at the GraphQL API level? We could also reuse the
filterBy
clause from the reference fields. On the backend it could be translated to basicreferenceContent
.I think we could automatically provide the count attribute on
EntityDecorator
level. evitaDB internally always needs to compute reference primary keys to calculate the count, so we could always provide the array of these primary keys (since they have to be fetched anyway). But on the API level the primary keys can easily be thrown away and only the count could be provided to the external clients, thus saving some transport/networking costs.