[db] Feature Request: Support for Parameters in QueryBuilder.search().elements().query()

[pinghe]

I would like to request a new feature that allows for parameter support within the QueryBuilder.search().elements().query() method. Currently, I am looking for a way to specify whether the query should return values or not, similar to how SQL queries can be parameterized.

Feature Description:
It would be beneficial if we could pass a parameter to the QueryBuilder.search().elements() method to indicate whether the values should be included in the results. For example, the method signature could be modified to:

QueryBuilder.search().elements(boolean includedValues).query()
This would allow developers to control the output of the query more flexibly.

Use Case:
In some scenarios, we only need the structure of the query results without the actual values. By providing a parameter to control the inclusion of values, it would simplify the code and potentially improve performance by reducing the amount of data being processed and transferred.

Current Workaround:
Currently, I am using a workaround by manually filtering the results after the query execution, but this is not as efficient as having a built-in parameter.

Expected Behavior:
If the includedValues parameter is set to true, the query should return the values as part of the results. If set to false, the query should return only the structure without the values.

I believe this feature would greatly enhance the flexibility and usability of our QueryBuilder.

Thank you for considering this feature request.

Best regards,
pinghe

[michaelvlach]

Hi, this feature is already included! The new QueryBuilder.search().elements() is the search query and like all search queries it returns only a list of ids. If you wish to select data you simply combine it with the select query:

QueryBuilder.select()
            .ids(QueryBuilder.search().elements().query())
            .query();

It is done this way because it is more flexible than having a parameter on the search queries directly. Select queries allow you to do much more like selecting only certain keys, selecting only keys without values etc.

As a side not be cautious when using search().elements() as it is a brute force query that will be very slow and not really usable for most use cases. As mentioned in the documentation it is for edge cases where you cannot or do not want to traversse the graph (e.g. not knowing the structure at all). This query examines everything in linear order - O(n) over the entire database - so depending on your data set it can take a very long time to complete. Consider combining it with limit() to put a limit on the potential runtime of the query.

[michaelvlach]

Let me know if this fulfils your use case. Thanks.

[pinghe]

Thank you for your answer, this meets my use case.

[pinghe]

If I want to clear the entire database, can there be a command similar to db_empty or db_clear?

What is the difference between db_remove and db_delete?

[michaelvlach]

That might be a bit dangerous. If you don't care about history (audit) you can simply delete the db and re-create it with the same name. Otherwise it would require some consideration. Perhaps forcing a backup before clearing.

[pinghe]

Yes, this operation is quite risky, so it is controlled through strict access permissions.
In my scenario, I want to import data from Environment A to Environment B, while retaining the historical data from Environment B. A backup will be executed before the clearance.

[michaelvlach]

This is now done in: #1132

The new api is: /{owner}/{db}/clear?resource=db but obviously it is best to call it using the TS api rather than manually.

Resource options:

all //clears db, audit and backup
audit //clears only audit log
db //clears only db keeping audit and backup
backup //clears only backup

[pinghe]

thks!