[1] Entity History Rework #310
Conversation
| { | ||
| "current": s.flatten(currentHistoryFieldsSchema), | ||
| "previous": s.flatten(previousHistoryFieldsSchema), | ||
| "entityData": s.flatten(entitySchema), | ||
| } |
There was a problem hiding this comment.
Using flatten here with a transform below to the actual record was the best way I could think of creating this schema.
| sql->Postgres.unsafe(`SELECT * FROM "public"."${mockEntityHistory.table.tableName}"`) | ||
|
|
||
| describe("Entity history serde", () => { | ||
| it("serializes and deserializes correctly", () => { |
There was a problem hiding this comment.
This test explains the desired effect/approach of using the schema for an entity
| }) | ||
|
|
||
| describe("Entity History Codegen", () => { | ||
| it("Creates an insert function", () => { |
There was a problem hiding this comment.
This one just illustrates the insert function that gets generated
| Assert.equal(expected, mockEntityHistory.createInsertFnQuery) | ||
| }) | ||
|
|
||
| Async.it("Creating tables and functions works", async () => { |
There was a problem hiding this comment.
This one demonstrates the function and how it will be called. Although each entity will have an actual function it can call in the next PR
| { | ||
| "current": s.flatten(currentHistoryFieldsSchema), | ||
| "previous": s.flatten(previousHistoryFieldsSchema), | ||
| "entityData": s.flatten(entitySchema), |
There was a problem hiding this comment.
It probably won't happen, but it might break if the entity has fields entity_history_log_index etc
|
|
||
| let createInsertFnQuery = { | ||
| let insertFnName = `"insert_${table.tableName}"` | ||
| let historRowArg = "history_row" |
There was a problem hiding this comment.
| let historRowArg = "history_row" | |
| let historyRowArg = "history_row" |
| ORDER BY ${currentChangeFieldNames | ||
| ->Belt.Array.map(fieldName => fieldName ++ " DESC") | ||
| ->Js.Array2.joinWith(", ")} |
There was a problem hiding this comment.
I think it should take the previous one even without the ORDER BY
There was a problem hiding this comment.
Postgres doesn't guarentee ordering say by insertion. So what we should probably do is have a serial field that increments and we can order by that instead. What do you think?
Reckon we will need that for the suggested unordered multichain implementation as well.
There was a problem hiding this comment.
Postgres doesn't guarentee ordering say by insertion.
Didn't know that.
So what we should probably do is have a serial field that increments and we can order by that instead. What do you think?
This sounds good, but the current approach also works
There was a problem hiding this comment.
It works for ordered multichain 😬
JonoPrest
force-pushed
the
jp/entity_history
branch
from
8643d95
to
63b4a28
Compare
JonoPrest
force-pushed
the
jp/entity_history
branch
2 times, most recently
from
f500b14
to
3ae5772
Compare
Next PR will apply the insert function on writes.