Add simple query API

[grzesiekjaczewski]

I propose a very light, simple query API that can execute ad-hoc queries and return only a very basic statistics.

[rossmills99]

Hey, thanks for submitting a PR! It would be great to hear what's the motivation behind a separate QueryApi, what can this do that is not already available using the CursorApiClient that already exists?

[grzesiekjaczewski]

Hey, thanks for submitting a PR! It would be great to hear what's the motivation behind a separate QueryApi, what can this do that is not already available using the CursorApiClient that already exists?

My primary motivation for submitting the PR for QueryApi was to provide a lightweight and simplified method for handling insert, update, or delete requests that return only essential statistics. Although this functionality can be achieved using a cursor with a specifically crafted return query, my goal was to offer an API that operates this way by default.

[rossmills99]

Hey, thanks for submitting a PR! It would be great to hear what's the motivation behind a separate QueryApi, what can this do that is not already available using the CursorApiClient that already exists?

My primary motivation for submitting the PR for QueryApi was to provide a lightweight and simplified method for handling insert, update, or delete requests that return only essential statistics. Although this functionality can be achieved using a cursor with a specifically crafted return query, my goal was to offer an API that operates this way by default.

Thanks for the clarification! So I think that the models already exist to get the query info that you're looking for - we don't need to replicate all of that. What about if we instead:

• create a non-generic overload of PostCursorAsync which can return a response of type CursorResponseBase, which does not have the Result property
• split out properties Error, Count, Extra etc and put them in the non-generic base class (CursorResponseBase) and have CursorResponse<T> extend it, with the additional generic Result property.

Then you'd be able to use it something like:

CursorResponseBase response = _cursorApiClient.PostCursorAsync(myQuery, myBindVars);
long numWrites = response.Extra.Stats.WritesExecuted;

[grzesiekjaczewski]

Hey, thanks for submitting a PR! It would be great to hear what's the motivation behind a separate QueryApi, what can this do that is not already available using the CursorApiClient that already exists?

My primary motivation for submitting the PR for QueryApi was to provide a lightweight and simplified method for handling insert, update, or delete requests that return only essential statistics. Although this functionality can be achieved using a cursor with a specifically crafted return query, my goal was to offer an API that operates this way by default.

Thanks for the clarification! So I think that the models already exist to get the query info that you're looking for - we don't need to replicate all of that. What about if we instead:

• create a non-generic overload of PostCursorAsync which can return a response of type CursorResponseBase, which does not have the Result property
• split out properties Error, Count, Extra etc and put them in the non-generic base class (CursorResponseBase) and have CursorResponse<T> extend it, with the additional generic Result property.

Then you'd be able to use it something like:

CursorResponseBase response = _cursorApiClient.PostCursorAsync(myQuery, myBindVars);
long numWrites = response.Extra.Stats.WritesExecuted;

Thanks for the explanation! I wasn't aware of that; it's a very useful feature of the cursor. Anyway, I'm glad I had the opportunity to take a closer look at the ArangoDB-NET-Standard code. I hope that my contribution will be more productive next time.

[rossmills99]

I'll close out the PR for now but if you have any interest in implementing what I've suggested above, I think it would be a good approach and provide a convenient way to do what you have with the simple query API - it would just leverage what's already there.

I also think that "Cursor" is not a great name for what is the API for submitting queries - how would you guess that?! But we are just following the naming used by ArangoDB itself which is the part of the philosophy of this project (minimal abstractions on top of the existing REST API).

[grzesiekjaczewski]

I'll close out the PR for now but if you have any interest in implementing what I've suggested above, I think it would be a good approach and provide a convenient way to do what you have with the simple query API - it would just leverage what's already there.

I also think that "Cursor" is not a great name for what is the API for submitting queries - how would you guess that?! But we are just following the naming used by ArangoDB itself which is the part of the philosophy of this project (minimal abstractions on top of the existing REST API).

Yes, I will implement that in the separate PR

[DiscoPYF]

Ross' suggestion is a good one for your use case.

Still, I just want to note that it's possible to do this already, but you have to specify a "dummy" type.

Example:

CursorResponse<object> response = await _cursorApi.PostCursorAsync<object>(myQuery, myBindVars);
long numWrites = response.Extra.Stats.WritesExecuted;

I'm mentioning as it's not super obvious.