RFC: Add support for namespacing partitions about electrodb HOT 7 CLOSED

Worked on this this afternoon, made a PR. Let me know if you prefer any changes to your accreditation, this RFC was great and I wish I had been able to complete the work sooner.

from electrodb.

Hey @sam3d!

This is definitely the most thorough proposal I've gotten, thank you for the time you took to put this together!

This feature makes a lot of sense and would be a great add to the library. In the near term, this might be a heavier lift than I can manage right at the moment. There are a few areas that this would impact that would add more complexity, namely typing, that I believe will be a large effort.

I don't know exactly when, but I will keep this in mind when I next have more bandwidth. I have another feature (adding auto-sharding) that will likely hit similar places of complexity and I'll likely try to do both.

Let me know if I can help further, and definitely don't let this dissuade you from creating more tickets; my bandwidth is low at the moment, but I'm still actively maintaining it 👍

from electrodb.

Good news, I slept on this (I read somewhere sleep helps...) an realized the typing won't be an issue here.

From a collections perspective, namespace is a property that can/must be verified at Service instantiation to match across all members. Since it impacts the pk key there is no reason to allow a collection with mixed namespaces.

So as far as my mental model is concerned I think this goes back to an easy add 🎉

from electrodb.

Whoa that's so exciting! Thank you so much for finding the time to work on this! 🚀

(p.s. really appreciate the accreditation, even though you did literally all of the heavy lifting)

from electrodb.

Heya! 👋

That's absolutely no worries, I'm super grateful for the consideration nonetheless 😊

I hope you don't mind me asking – my understanding of the typing amendments required would be a fairly trivial update to the props on an entity index to include the namespace?: string | string[] | undefined in a standard way (i.e. not a type parameter). Simply treated as a static prefix that's prepended to the partition key.

It sounds like you're talking about going down a similar route to collections, where a partition namespace can actually refine the typescript typing of which entities a query may produce. Which would be very very cool! But a lot more work than what I was thinking of in my proposal, I imagine.

Thanks again for the awesome library! (p.s. very excited for auto-sharding)

from electrodb.

Yay! That makes sense, and is also pretty much what I had in mind too. Please let me know if there's anything I can do to support 🛟

from electrodb.

Thanks a lot @sam3d and @tywalch, this looks promising 🚀🥇

from electrodb.