[Bug]: go-sdk can't use upsert. about milvus HOT 15 OPEN

@Seaiii could you please share your collection schema and code snippet of upsert? Also share the versions of milvus and go sdks would be helpful.

/assign @Seaiii
/unassign

from milvus.

@Seaiii could you please share your collection schema and code snippet of upsert? Also share the versions of milvus and go sdks would be helpful.

embeddings := entity.NewColumnFloatVector("embedding", 1024, [][]float32{embedding})
contents := entity.NewColumnVarChar("content", []string{action.Content})
id := entity.NewColumnInt64("id", []int64{action.Id})
_, err := MilvusClient.milvus.Upsert(context.Background(), collectionName, "", id, embeddings, contents)

embeddings are vectorised values.
content is the varchar content
id is the self-incremented primary key id

milvus version:2.4.1
milvus-sdk-go/v2 v2.4.0

from milvus.

@Seaiii Upsert operations does not support collections with autoID enabled.

from milvus.

thought @smellthemoon is working on it

from milvus.

@Seaiii Upsert operations does not support collections with autoID enabled.

Is this one for sure? In that case I still need to maintain a self-incrementing id myself.
But the error message that milvus replied to me was not due to autoID

from milvus.

thought @smellthemoon is working on it

pr has hang for a long time. related with #30342, reviewed by @czs007 . I will fix the conflict after review.

from milvus.

Is this one for sure? In that case I still need to maintain a self-incrementing id myself.
But the error message that milvus replied to me was not due to autoID

yes, I will make the error msg more clear.
/assign

from milvus.

autoID

Ok, so when your PR is merged, autoID will be able to use upsert too right?

from milvus.

autoID

Ok, so when your PR is merged, autoID will be able to use upsert too right?

As you already set autoid for primary key, could you please share more info about why do you still need upsert to keep the same primary key? The pr will not be merged until it is determined that upsert for autoid is really meaningful to user scenarios. @Seaiii

from milvus.

autoID

We need the primary key id to self-increment to determine uniqueness. Also we need to update each piece of information. That's all.
If we don't set the primary key id to increment, we need to maintain our own

from milvus.

autoID

We need the primary key id to self-increment to determine uniqueness. Also we need to update each piece of information. That's all. If we don't set the primary key id to increment, we need to maintain our own

so in your case to keep the order of entities, you want the same primary key after doing upsert？is it acceptable for you if we set a new primary key(a new incremented or a bigger id) for the updated entity after doing upsert?

from milvus.

so in your case to keep the order of entities, you want the same primary key after doing upsert？is it acceptable for you if we set a new primary key(a new incremented or a bigger id) for the updated entity after doing upsert?

If a new primary key is added cutting larger values is not necessary.
This is because without the upsert interface, we would delete and then create for "updates". It's also a bigger primary key, and the sorting will be messed up.
The effect we want to see is that the primary key remains the same after the update.

from milvus.

okay, thank you for your feedbacks. We will rethink our design of support for upsert with autoid.
I'd close this issue as the following up support will be trakced in pr above.

from milvus.

action.Id

how did you know action.Id? did you store it some where else?

from milvus.

how did you know action.Id? did you store it some where else?

Get all the action.Id for display via the query method.
If I want to modify any of them, I do know what this action.Id is

from milvus.