Closed thorhj closed 1 year ago
This sounds like https://github.com/tywalch/electrodb/issues/290
@sam3d is correct here, this is the same need she described in her RFC. I added a PR this afternoon that will address this, and I'm hoping to merge it as soon as tomorrow morning 👍
My table is modelling a schedule linking a user to a specific date. I have the following access patterns:
Since I am never looking to fetch a singular schedule, I am simply adding all the schedule items to the same partition using
"schedule"
as the partition key and composing the sort key by date and user ID (only there to ensure uniqueness). For example:I can model this with the following entity:
Notice I am composing the
pk
from nothing and using a template to set a fixed value instead. This means I can query the data like so:This approach has a few downsides though:
template
for the partition key, meaning that I have to manually manage namespacing (which I haven't done in my example).Schedule.query.byTemplate({}).begins({ date: "2023" })
. This is of course a small thing, but it would be nicer to just doSchedule.query.byTemplate().begins(...)
when the partition key for the entity is "fixed".If this is indeed the best way to model a single-partition entity (please let me know if there is a better way), then I would like to suggest a more convenient definition to the key schema type for fixed-partition entities:
Here I am using
value
to say I want the value in the partition key to always be"schedule"
. You shouldn't be able to usevalue
andcomposite
together of course.With this key definition the library would then be able to set a fixed partition key for the entity while still managing the namespacing. The typing could potentially be adjusted to allow
undefined
for the query key object (but this is potentially difficult to implement compared to the benefit).What do you think?