Secondary index keys not updated when using composite attributes from table's primary index

[misterjoshua]

Describe the bug
When I use the update mutation to create an item, the secondary index keys are not included in the update even though all the attributes used in the secondary index are part of the primary index.

ElectroDB Version
2.8.2

ElectroDB Playground Link
Playground Link

Entity/Service Definitions
See the playground link: Playground Link

Expected behavior
I expected the update mutation to generate the secondary index keys.

Errors
I didn't receive any error message, but the result is that the update causes an incomplete record to be written when it should have been possible to write a complete record.

Additional context
Maybe I've misinterpreted the docs, but I was going off of this section:

In the event that a secondary index includes composite values from the table’s primary index, ElectroDB will draw from the values supplied for the update key to address index gaps in the secondary index.

Source: https://electrodb.dev/en/mutations/update/#updating-composite-attributes

I'm a fairly new ElectroDB user, so forgive me if I've missed something obvious. Thanks for your help.

[misterjoshua]

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

[tywalch]

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.

[misterjoshua]

@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.

[tywalch]

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?

[misterjoshua]

@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.

[misterjoshua]

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

[tywalch]

@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.

[tywalch]

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

[tywalch]

@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.

[misterjoshua]

@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();