Shareable Collections should support PartitionKey about cosmonaut HOT 6 CLOSED

Enhancement added!
61bbd0d

Shared collections will no longer default to id as a partition key.

Thanks for the suggestion.

from cosmonaut.

Hello Ryan,

You are totally right, I actually wanted to remove this limitation.

Still haven’t figured out what would be the best way to tackle it from a coding standpoint (how the consumer will set this partition key even if the two objects don’t have the same interface), but I will come up with something.

Thanks for the feedback.

from cosmonaut.

I can take a look and submit a PR and we can go from there, if you like

from cosmonaut.

Currently the way to specify the partition key on the dto level is to use the [CosmosPartitionKey] attribute. This makes Cosmonaut to do all the partition key stuff automatically. It would be nice if the solution is something along those lines.

Of course if you can think of something better I’d be more than happy to hear it (or even see it with a PR)

from cosmonaut.

Ok after I had a coffee I think I have a plan of attack.

1. Remove the SharedCollection default to /id partition key logic.
2. Honor the [CosmosPartitionKey] attribute in entities that are part of shared collections.
3. Let the user deal with the errors when they have PartitionKey inconsistencies between two different entities that are sharing a collection but also make the right way to do it really clear in the documentation.

I still have one unanswered question though.
In the CollectionCreator's logic, if they don't specify the [CosmosPartitionKey] do I default it to /id or do I just create it without a partition key at all, limiting them in 10 GB?

I'm leaning towards the second one because it gives more control to the user. What do you think?

from cosmonaut.

Very cool!

from cosmonaut.