Unable to write multiple values to a cell at different timestamps atomically

[billyjacobson]

I was trying to write multiple values to a cell at different timestamps, but discovered I couldn't do this in a single atomic operation.

The code would look like this:

const rowsToInsert = [
      {
        key: 'phone#4c410523#20190501',
        data: {
          stats_summary: {
            connected_cell: {
              value: 1,
              timestamp: TIMESTAMP,
            },
            connected_wifi: {
              value: 1,
              timestamp: TIMESTAMP,
            },
            os_build: {
              value: 'PQ2A.190405.003',
              timestamp: TIMESTAMP,
            },
          },
          cell_plan: {
            data_plan_01gb: {
              value: 'true',
              timestamp: TIMESTAMP,
            },
            data_plan_01gb: {
              value: 'true',
              timestamp: TIMESTAMP_MINUS_HR,
            },
            data_plan_05gb: {
              value: 'true',
              timestamp: TIMESTAMP,
            },
          },
        },
      }, // .... (more rows here)

await table.insert(rowsToInsert);

But, under cell_plan, I can't have two object keys with the same name here ( data_plan_01gb.) To get this to work, I can add another row mutation which includes the value at the other timestamp, but then they will not be executed atomically. The documentation says this about mutate rows "Mutates multiple rows in a batch. Each individual row is mutated atomically as in MutateRow, but the entire batch is not executed atomically."

I think a good solution to might be to allow an array of value/timestamp objects to be passed in some way, but I am open to your ideas. Let me know if you need clarification on anything. Thanks

[meredithslota]

@kolea2 Is this something that is worth prioritizing (for parity across libraries or ...) in 2022?

[danieljbruce]

Maybe use timestamp: [TIMESTAMP, TIMESTAMP_MINUS_HR]?

[meredithslota]

I don't think this is a high-enough priority to keep open — we haven't seen any other requests like this in the interim. Closing as a "Won't Fix".