A Collection should store its UUID about chroma

[HammadB]

In this, would you propose updating the api routes from collection_name to collection_uuid? I agree it is cumbersome to do again and again, and with good local clients - not necessary.

Yes I think so. We can also keep the old routes and wrap the logic somehow, creating new ones for uuid.

Solution space includes

1. What we discussed above
2. just cache it locally.
3. Change our reads to filter on the name. Since we don't have an index currently on collection_uuid we could just change it. I don't think we should do that as we will want that soon.

[levand]

So an observation: the current user-facing API doesn't expose the notion of an collection UUID at all, users interact with it solely in terms of its name.

In the (first version) of the refactored architecture, collections are associated 1:1 with Pulsar topics, which are namespaced by tenant, and have a string name (with similar but more flexible naming conventions to what topics have now.)

So IMO we can keep using the user-provided name as the primary key for now, and do away with the complexity of having an separate unique ID for a collection.

Regardless, I don't think this is urgent enough to address before the refactor lands (at which point the approach will change anyway).

[jeffchuber]

In this, would you propose updating the api routes from collection_name to collection_uuid? I agree it is cumbersome to do again and again, and with good local clients - not necessary.

[atroyn]

Saves a DB roundtrip, too

[HammadB]

Saves a DB roundtrip, too

Yep

[jeffchuber]

@levand correct me if im wrong, but the refactor should not affect this, since this is mostly about the plumbing between the backend and the frontend?

[jeffchuber]

Thanks for the feedback! Let's close this for now and re-open it if/when the need arises.