Andrii Savytskyi

> this line of reasoning seems intuitive to me and I was about to merge this thinking this is good-to-go. I've briefly tested this PR and it breaks with opening...

Full example: ```go type Parent struct { ID int `db:",primary"` Childs []*Child `ref:"id" fk:"parent_id" autosave:"true" autoload:"true"` } type Child struct { ID int `db:",primary"` ParentID int Name string } func(repo...

**Append** - no panic, but generate queries: ```sql DELETE FROM "children" WHERE "children"."parent_id"=$1; INSERT INTO "children" ("parent_id","id","name") VALUES ($1,DEFAULT,DEFAULT),($2,DEFAULT,DEFAULT),($3,$4,$5) RETURNING "id" ``` **Update** - no panic, but generate queries: ```sql...

I will do a PR with fix today

> because REL can't determine the operation correctly Can you show an example? I see only one case - ID is not serial + no changeset.

This fix my issue: https://github.com/qRoC/rel/commit/45adbeb9589f0e28bb89b4b74e7c21ec64f521ca I don't create a PR because it changes the default behavior.

Must be `numeric`, because `bigint` is unsafe.

bigint is like int64 (-9223372036854775808 .. 9223372036854775807) but uint64 in range 0 .. 18446744073709551615. So for safe usage you must: 1) use bitcast (but select queries will be broken) 2)...

Why are you using uint64 when you want int64? If I set uint64 then I need this range. The client should mirror the model in the database, and not distort...

@frederikhors bigint is "lower", "numeric" is "bigger". (see https://github.com/uptrace/bun/issues/359#issuecomment-994751260) And my proposal - use `numeric` instead `bigint` for uint64.