You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be an amazing feature to be able to send queries to the repository, have it perform them efficiently on the database, and get back a result.
For example, I need to check how many nodes of a given type have a certain reference set to null and how many have it set to something different than null.
To do that:
I first use one of the additional APIs that give me back the map classifier -> node IDs
I then retrieve all the nodes through their node IDs (with depth 1)
I do the counting on the client side
This takes ~5 minutes because I have 2,666 nodes of that type, and they have a very big string property. I think the query executed on the repository could be orders of magnitude faster.
I think we do not want these queries to be expressed directly in SQL, as it would mean exposing the schema to the client. Also, it may be risky and error-prone. So we would probably need to use or define a query language that is then translated into SQL, getting the result, and then translating it into a format convenient to the client (and independent from the current database schema).
This would probably be a very useful feature but also require quite some effort.
The text was updated successfully, but these errors were encountered:
I think it would be an amazing feature to be able to send queries to the repository, have it perform them efficiently on the database, and get back a result.
For example, I need to check how many nodes of a given type have a certain reference set to null and how many have it set to something different than null.
To do that:
This takes ~5 minutes because I have 2,666 nodes of that type, and they have a very big string property. I think the query executed on the repository could be orders of magnitude faster.
I think we do not want these queries to be expressed directly in SQL, as it would mean exposing the schema to the client. Also, it may be risky and error-prone. So we would probably need to use or define a query language that is then translated into SQL, getting the result, and then translating it into a format convenient to the client (and independent from the current database schema).
This would probably be a very useful feature but also require quite some effort.
The text was updated successfully, but these errors were encountered: