Open Seaiii opened 3 months ago
@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
@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
@Seaiii Upsert operations does not support collections with autoID enabled.
thought @smellthemoon is working on it
@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
thought @smellthemoon is working on it
pr has hang for a long time. related with https://github.com/milvus-io/milvus/pull/30342, reviewed by @czs007 . I will fix the conflict after review.
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
autoID
Ok, so when your PR is merged, autoID will be able to use upsert too right?
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
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
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?
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.
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.
action.Id
how did you know action.Id? did you store it some where else?
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
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Rotten issues close after 30d of inactivity. Reopen the issue with /reopen
.
@congqixia is this still issue?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Rotten issues close after 30d of inactivity. Reopen the issue with /reopen
.
@congqixia @ThreadDao was this fixed
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Rotten issues close after 30d of inactivity. Reopen the issue with /reopen
.
Is there an existing issue for this?
Environment
Current Behavior
There are three fields in the library collection. I am also passing three fields using the Upsert method. But it says "the number of fields is less than needed: invalid parameter[expected=3][actual=4]"
Expected Behavior
No response
Steps To Reproduce
No response
Milvus Log
No response
Anything else?
No response