Get sort vector fix - DRAFT

[sl-at-ibm]

This PR attempts to fix the missing result in GetSortVector for collections (and presumably table) finds.

As highlighted by working on astra-vector-docs/modules/api-reference/examples/collections-find-many-sort-vector/example.go, the GetSortVector prints <nil> even though the response gives the sort vector. The reason is that the Go client looks for it under data.sortVector in the response, but it should look for it under response.sortVector.

This is a Bob-aided attempt at fixing it. Now a simple script similar in spirit to the docs-example script returns indeed the sort vector, but in this form (not sure if it is the desired wrapping):

&{[-0.06364043 -0.026595363 ... 0.015331947]  false}

Here is a(n abridged) example response from the API:

{
    "data": {
        "documents": [
            {
                "_id": "028cc6a3-2b28-486f-8cc6-a32b28e86f29"
            }
        ],
        "nextPageState": null
    },
    "status": {
        "sortVector": [
            -0.06364043,
            ...,
            0.015331947
        ]
    }
}

And here is the silly script that incarnates the docs-example as a full runnable similar to the other /examples here: ([attachment).

getsortvectorer.go.txt

Note the go.mod/go.sum changes were by Bob helping me run the test script with the changed local code (it seems the v2 otherwise gets in the way and insists on using the codebase from github).

[toptobes]

@sl-at-ibm Did you base this PR off an old version of the client? There's no other reason why your go.mod should have the pre-v2 module github.com/datastax/astra-db-go

[sl-at-ibm]

@toptobes You are very right - apologies.
I rebased to latest main, however the cursor inner mechanics is changed enough that this became a different fix.

The simple mistake (sort vector sought in the wrong json path) was still there and this PR corrects it. But there's more, which is "fundamental" enough to warrant a closer look.

I got to a working fix. I can get the sort vector if there are no results, if the cursor is closed (arguably useful), before any .Next(ctx) call, after one or more Next calls, etc.
But the interplay with the cursor states, the page fetching and the buffer consuming by Next seems a little ad hoc and may be a fragile way to handle things.

• Closing the cursor erases the fetched page, so a separate cached sort vector is added (not erased by closing)
• I initially had the bug that calling GSV before any Next (=before fetching the page) resulted in the subsequent Next skipping the first document. That's because Next was not prepared to the possibility that the page be there but nothing consumed yet, a case that however seems useful for the sort vector.
• (related) The cursor can now be idle but with the first page fetched. Hmm. Not sure if this is really intuitive, but it might be this is how it plays with the Go cursor implementation. Do we rather want the cursor to jump to started right away when the page is fetched? (probably. This would require some changes around the checks when consuming from the buffer, I suppose).

I am not sure I have a good-enough grasp of the Go find cursor yet to do this autonomously, but let's talk!

Incidentally, I did not commit a fix that Bob suggested to make sure I run my testing examples with the local code, i.e. adding replace github.com/datastax/astra-db-go/v2 => ./ to the go.mod. I am not sure this is the best way though (but without that line, the script kept using the library from github rather than my local changes).

[sl-at-ibm]

Also an updated script
getsortvectorer.go.txt