milvus-io / milvus

A cloud-native vector database, storage for next generation AI applications
https://milvus.io
Apache License 2.0
29.79k stars 2.86k forks source link

[Bug]: go-sdk can't use upsert. #33835

Open Seaiii opened 3 months ago

Seaiii commented 3 months ago

Is there an existing issue for this?

Environment

- Milvus version:
- Deployment mode(standalone or cluster):
- MQ type(rocksmq, pulsar or kafka):    
- SDK version(e.g. pymilvus v2.0.0rc2):
- OS(Ubuntu or CentOS): 
- CPU/Memory: 
- GPU: 
- Others:

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

yanliang567 commented 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 commented 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.

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

image
sunby commented 3 months ago

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

xiaofan-luan commented 3 months ago

thought @smellthemoon is working on it

Seaiii commented 3 months ago

@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

smellthemoon commented 3 months ago

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.

smellthemoon commented 3 months ago

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

Seaiii commented 3 months ago

autoID

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

yanliang567 commented 3 months ago

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

Seaiii commented 3 months ago

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

yanliang567 commented 3 months ago

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?

Seaiii commented 3 months ago

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.

yanliang567 commented 3 months ago

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.

xiaofan-luan commented 3 months ago

action.Id

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

Seaiii commented 3 months ago

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

stale[bot] commented 2 months ago

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.

xiaofan-luan commented 2 months ago

@congqixia is this still issue?

stale[bot] commented 1 month ago

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.

yanliang567 commented 1 month ago

@congqixia @ThreadDao was this fixed

stale[bot] commented 2 weeks ago

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.