consistent "document" / "documents" fields for insert commands

[amorton]

Ensure we have a consistent and document use of "document" / "documents" for the insertOne and insertMany commands - and this matches what we use in the response document.

ensure same in:

• server code
• spec
• driver code
• postman

[ivansenic]

@amorton I am not sure I follow the actual task here, currently in the implementation:

• insertOne has a field document
• insertMany has a field documents

Is this how we want it to be or not? If so then I only need to double check the spec, driver and the postman, right?

[amorton]

the original idea was to have them both be the same, which i guess would be "documents". And it would be the same for the find and findOneX calls as well so we always have the same document or documents.

I think there are two outcomes:

1. It's the same everywhere, even if it does not make sense. i.e. insertOne uses documents.
2. It's different, but correct where it makes sense. e.g. insertOne is document. findOne returns document. findMany returns documents.

Can you chat with the team in the USA including @kathirsvn and work out what is the best approach. The main thing is we are doing things deliberately.

[ivansenic]

@kathirsvn Any chance we sync on this?

[kathirsvn]

Hi Ivan, Sure, we can catch up today. I'll ping you in slack. Here's the current API status with respect to this naming. insert -> document insertMany -> documents find -> docs findOne -> docs findOneAndUpdate -> docs (returned after upserting a doc as required) Thanks & Regards Kathiresan Selvaraj

…

On Mon, Apr 24, 2023 at 8:06 AM Ivan Senic ***@***.***> wrote: @kathirsvn <https://github.com/kathirsvn> Any chance we sync on this? — Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AW5DDBFAQBFFL5CYDARZVL3XCZUC5ANCNFSM6AAAAAAU5RTPUY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ivansenic]

@amorton We agreed to go for the option #2. So we will change the response data.

• In case there are multiple documents, we will return data.documents and data.nextPagingState
• In case there is a single document (findOneXXX), we will only return data.document

Kathir said we need to publish this in a release first and then he will do the driver updates.

@maheshrajamani OK with you?

[maheshrajamani]

@ivansenic That should be fine.

[ivansenic]

@maheshrajamani @kathirsvn What are we doing with the delete and update commands, they are also returning data? should deleteOne and updateOne also have data.document?

[maheshrajamani]

@ivansenic delete[One/Many] and update[One/Many] don't return any document in response. The document is returned for findOneAndUpdate, findOneAndReplace and findOneAndDelete. It will always be one document in response so has to be data.document.

[ivansenic]

@ivansenic delete[One/Many] and update[One/Many] don't return any document in response. The document is returned for findOneAndUpdate, findOneAndReplace and findOneAndDelete. It will always be one document in response so has to be data.document.

@maheshrajamani ok but operation does:

https://github.com/stargate/jsonapi/blob/6cff90ffc739ce96b74ef9da744130b0e694a40b/src/main/java/io/stargate/sgv2/jsonapi/service/operation/model/impl/DeleteOperationPage.java#L74-L84

https://github.com/stargate/jsonapi/blob/6cff90ffc739ce96b74ef9da744130b0e694a40b/src/main/java/io/stargate/sgv2/jsonapi/service/operation/model/impl/UpdateOperationPage.java#L65-L72

[maheshrajamani]

boolean returnDocument flag will come in as false in case of delete[One/Many] and update[One/Many]

[ivansenic]

boolean returnDocument flag will come in as false in case of delete[One/Many] and update[One/Many]

@maheshrajamani thanks.. so basically I can always assume that it's a single response in those delete and update op pages?

[maheshrajamani]

@ivansenic Yes it will be a single document.