Hi @Talljoe 👋

You're right about hitting the case described in #366. You could take several directions here, but here's some background about what you see. There is a runtime validation for indexes with a condition callback that all composite attributes must be updated together, but that's only part of the issue in this case. The other challenge is that relatedEntryId (the first composite slot) is undefined, but createdAt (the second composite slot) is defined. This scenario prevents ElectroDB from being able to format the sort key value with the values provided (e.g., $tasks_1#relatedentryid_123#createdat_1728237814343). Electro uses some runtime constraints to prevent keys from getting out of sync with their underlying attributes because the circumstances of the operation itself and the side effects of user-defined attribute callbacks are relevant to evaluating the constraint. Ultimately, there is a lot that Electro can't assume or know, so it optimizes to protect data integrity.

The simplest solution here is to provide some value for relatedEntryId, like an empty string or a constant that is out of band for your type of id. This will satisfy the index constraints. Checkout this playground to see how I used a get callback and default value on relatedEntryId to accomplish this without requiring additional work to your application code.

I hope this helps! If you'd like, I can discuss the constraints in more detail or offer additional approaches, just let me know 👍

Thank you for the writeup. I had added the condition because of the issue with null slots of composite keys and I understand the reasoning behind 366. The link to the playground doesn't work for me, but I can guess at the gist of it.

I do believe that supplying undefined explicitly in the query should be enough to satisfy the runtime constraint. I think it would be possible to notice that a value was supplied to the update/patch query, even if it is undefined, such as these two examples. I tried to put together a pull request by using Object.hasOwn or similar but wasn't completely successful. I was able to get the composite side to work pass tests but the set side is filtering out the undefineds at some point that I couldn't quite determine. And who knows what else I might have broken. :)

Alternatively, perhaps ElectroDB could use a Symbol here to indicate "value undefined is supplied." I admit that the DX ergonomics on this wouldn't be great as this is kind of the only place it would be used, but it would be less work than needing to build out a version of it using set/get and magic values.

If it truly isn't possible to use a nullable attribute in a composite key then it's probably worth flagging that at "compile time" by stripping attributes with required: false from the candidates allowed in the composite section.

Cheers and thanks again for such great support.