feat(temporal data): add time slice key to conflict clause

[sjvans]

• test
• changelog will happen automatically once merged

[nocin]

It would be great if this fix could make it in the next release. This would simplify my life a lot! Thanks!

[patricebender]

@sjvans Could you add a test which shows the effects of this change?

[nocin]

Hi all,

thanks for moving this topic forward! Am I right, that only one check is missing until it could be merged? That would be awesome!

BR, Nico

[johannes-vogel]

Hi all,

thanks for moving this topic forward! Am I right, that only one check is missing until it could be merged? That would be awesome!

BR, Nico

@nocin Is it an option for you to make @cds.valid.from element a key? That should already work today.

[nocin]

Hi all,
thanks for moving this topic forward! Am I right, that only one check is missing until it could be merged? That would be awesome!
BR, Nico

@nocin Is it an option for you to make @cds.valid.from element a key? That should already work today.

Hi @johannes-vogel,

thanks for the hint! I now spend some time thinking about this approach, but it would mean a lot of work in backend, frontend and another external program which pushes data in the application, as in our case it is the "main" table of the project. Therefore, I would prefer to stick to a single UUID as key and will wait for this feature, until I continue working on my feature request.

BR, Nico

[johannes-vogel]

Why is || !isUpdate && (element['@cds.valid.from'] ? '$valid.from' : element['@cds.valid.to'] ? '$valid.to' : null) required?

[sjvans]

otherwise you cannot insert/ upsert data without specifying both validFrom and validTo in the payload.
in other words:
coalesce(ISO(value->>'$."validFrom"'), session_context('$valid.from'))
instead of just
ISO(value->>'$."validFrom"').

[sjvans]

@BobdenOs @johannes-vogel
was the default validTo changed? i now get $now but i would have expected something like 9999-12-31T23:59:59.999Z. with $now this defaulting logic is not good.

[BobdenOs]

session_context('$now') will return the timestamp from the tx.timestamp. Or is the $now part of the entries || data ?

[sjvans]

cds-dbs/db-service/lib/common/session-context.js

Line 27 in 87208af

new Date().toISOString().replace(/(\dZ?)$/, d => parseInt(d[0]) + 1 + d[1] || ''))

defaults to $now (logically)

[BobdenOs]

I see what you mean. I don't know what the behavior used to be.
I am also not sure whether the max timestamp default is correct in the temporal context as I would expect that any new insert with the same key values should become the validTo of the last value.

await INSERT({ID: 1/*, validFrom: $now, validTo: timestamp_max */}).into(temporal)
await sleep(...)
await Promise.all([
  INSERT({ID:1/*, validFrom: $now, validTo: timestamp_max */}).into(temporal),
  UPDATE(temporal).data({validTo: $now}).where(`ID = ${1} and validTo = ${timestamp_max}`),
])

[johannes-vogel]

I think we did not support/document how to write temporal data so far.
For now I think it's fine that the input is required by the user → #344

[BobdenOs]

This does not look correct. If the session context contains the from and to it should be considered.