Question: Should all properties of class be updated when using fields?

[Swoorup]

I have table like

[<CLIMutable>]
type commandentity =
  { id: int64
    eventid: Guid
    aggregateid: Guid
    commandid: Guid
    causationid: Guid
    correlationid: Guid
    commandpayload: string
    payloadtype: string
    queuename: string
    expectedversion: int64
    processid: obj
    ``Timestamp Utc``: DateTime }

And insert using

  let createNewCmd () =
    counter <- counter + 1
    let cstr = string counter

    { commandentity.id = -1L
      aggregateid = Guid.NewGuid()
      eventid = Guid.NewGuid()
      commandid = Guid.NewGuid()
      causationid = Guid.NewGuid()
      correlationid = Guid.NewGuid()
      commandpayload = cstr
      payloadtype = cstr
      queuename = cstr
      expectedversion = 1L
      processid = null
      ``Timestamp Utc`` = DateTime.UtcNow }

    let a = [| createNewCmd ();  |]
    // ctx.DeleteAll<CommandEntity>() |> ignore

    let fieldsToWrite =
      Field.From(
        "eventid",
        "aggregateid",
        "commandid",
        "causationid",
        "correlationid",
        "commandpayload",
        "payloadtype",
        "queuename",
        "expectedversion",
        "processid")
                                        
    let ret = ctx.InsertAll(entities=a, fields=fieldsToWrite)
    printfn "ctx.InsertedAll %A" a
    printfn "ctx.InsertedAll = %d" ret

However the a or the entities isn't updated.

ctx.InsertedAll [|{ id = -1L
    eventid = cedace2e-1686-4b79-a3fa-fdf168e59088
    aggregateid = c262825d-5419-4e75-a94c-0529e4500d6e
    commandid = 7ea4beb7-09a7-4a78-b535-9e979efb883e
    causationid = 3856515a-67bc-4b73-b1cd-6e57086e7d09
    correlationid = fb7622c5-9150-4ac6-902d-0a13614bb737
    commandpayload = "1"
    payloadtype = "1"
    queuename = "1"
    expectedversion = 1L
    processid = null
    Timestamp Utc = 16/09/2020 17:06:27 }|]
ctx.InsertedAll = 1

Querying it using a select functions, gives the id as 1 which is expected. Should repodb update all columns to latest?

V: RepoDb 1.12.0-beta3

[mikependon]

You are doing a targeted insert, only the affected fields written in the fields argument will be a part of the insertion. The data is not refreshed after the operation.

It seems I may misunderstand this, and if yes, can you please help me understand your scenario further?

[Swoorup]

I think I didn't read the docs properly now. Only the identity/primary key will be updated back when doing a bulk insert right? In here eventId is the primary key. The schema is setup as:

CREATE TABLE IF NOT EXISTS CommandEntity(
  Id bigserial ,
  EventId UUID primary key,
  AggregateId varchar(500) NOT NULL,
  CommandId varchar(500) NOT NULL,
  CausationId varchar(500) NOT NULL,
  CorrelationId VARCHAR(500) not NULL,
  CommandPayload TEXT,
  PayloadType TEXT,
  QueueName TEXT,
  ExpectedVersion INTEGER,
  ProcessId VARCHAR(500),
  "Timestamp Utc" TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

I was expecting to get the Id which is autoincremented back in the model. I probably have to use ExecuteQuery in this case. This was more of a question, hope i didn't ring any bells 👍

[mikependon]

It is okay. Anyway, the precedence is always like PRIMARY KEY > IDENTITY KEY > 'ID' > 'CLASS+ID' > 'MAPNAME+ID'. So in this case, only the EventId will be set back. Does this means that this is working as expected?

FYI: There is a request to update the model back completely, but RepoDB has choose the other use-case instead.

[mikependon]

Furthermore, but since the PRIMARY KEY is not an identity, then nothing happens. It might be the reason that have confused you right away. This is a good enhancement actually if we are to support your use-case.

[Swoorup]

Sure that change would be welcomed perhaps as extra parameter flag to toggle it on? I do realize this might an expensive operation, so it is at your discretion. 👍

Since I am doing event sourcing, it is handy for my use-case.

[mikependon]

We will assess this. It is completely fair to have a separate primary key and identity key, and both exists on the same table. But I would say, it is on a 5-10% of the scenarios (or maybe less).

[mikependon]

The original request will not be fixed.