Secondary index keys not updated when using composite attributes from table's primary index about electrodb HOT 13 CLOSED

I have opened this PR (nearly ready to merge) that adds support for add, subtract, and append operations on upsert: #296 🎉

I will merge soon, likely tomorrow

from electrodb.

@misterjoshua Thanks! This hasn't been published yet, the fact this commit made it to master was a mistake in a local script 👎. When this is ready to be published there will be additional tests and I will ensure this missing paren gets added.

from electrodb.

I also would love to hear @sam3d weigh in on this too btw

from electrodb.

@misterjoshua

Small update: I am rethinking this approach because it unfortunately conflicts with some of the goals associated with .composite(). I think the solution here must be adding the mutation methods to upsert.

from electrodb.

Just merged, here's a playground showing its use, let me know if you experience any issues!

from electrodb.

I updated to ElectroDB 2.9.1 and I tried the .composite() method on an update, thinking maybe that would include the secondary index keys. But unfortunately, it appears the condition expression constraint prevents the item from being created.

Here's a playground to show what I mean: Playground

from electrodb.

Hi @misterjoshua 👋

It sounds like you're intentionally using "update" to create an item. To better understand your need, can you checkout the "upsert" method (https://electrodb.dev/en/mutations/upsert/) and let me know if that is capable of doing what you need?

The "composite" function on update is for cases where a composite attribute can't be set, e.g. because the property is readOnly.

from electrodb.

@tywalch Hi. Thanks for responding.

Yes, I am intentionally using update to create the item if it doesn't exist - but if it does exist, then the write operation should add a numeric value to a numeric item attribute. The DynamoDB ADD keyword lets you do this blindly and you can combine with SET to write a complete record if you know the rest of the item attributes at the time of write, which I do.

No, unfortunately, the upsert method can't do what I'm after, as it requires I know what value the attribute should be after the ADD operation, but I don't because I'm trying to avoid the unnecessary overhead of reading the record I'm updating, as reading the item increases both the cost and latency of the operation.

from electrodb.

Gotcha, this makes sense. In the short term, I'm thinking it might be worth updating the composite condition to be something like (${name} = ${value} or attribute_not_exists(${name}). In the long term, I am hoping to add support for methods like add to be used with upsert since you're not the first to ask for this. Would this address your need?

from electrodb.

@tywalch Yes, conditions looking like (${name} = ${value} or attribute_not_exists(${name}) would work nicely in the interim, and I like your longer-term idea as well. Thank you.

from electrodb.

I took a peek at aec1f57 and had a comment about the condition expression. My comment is inline here: aec1f57#r125880163

from electrodb.

@misterjoshua

Small update: I am rethinking this approach because it unfortunately conflicts with some of the goals associated with .composite(). I think the solution here must be adding the mutation methods to upsert.

Sounds good to me. The mutation methods on upsert could work well for my use case.

How do you think this would look, btw? Something like this?

entity.upsert(allAttributesExceptThoseInTheAdd)
  .add({ attribute: 1 })
  .go();

from electrodb.

Thank you for all the work you've put into this so far!

from electrodb.