Bug: Inserting an entity with a UUID PK which is defaulted to gen_random_uuid() fails to default when using Guids

[grofit]

We have a scenario where there is an entity with a UUID field which acts as the primary key:

 [Primary]
 [Map("some_pk_field")]
 public Guid SomePkField { get; set; }

We then have the field on the db side setup as a UUID with auto generation via default with not null:

some_pk_field uuid not null default gen_random_uuid()

When we try to insert into it we always get an empty guid as the PK, this is assumed to be due to Guid in C# being a value type so cannot be null, so its never triggering the default DB backed UUID generation.

Given this assumption we decided to make the Guid field nullable (Guid?) however when we try to insert with a null Guid RepoDb tells us that we need to provide an entry to the pk field.

We have also run the script to verify PKs for tables and this returns:

some_pk_field ,true,false,false,uuid // The 2nd field being true for it being primary key

Expected Behaviour

I expected that if a Guid was provided as the PK and it was an empty guid, it would use the DB default to create the PK and it would be returned by the Insert method. However if there is some legitimate reason why someone may need to insert an empty guid in which case the above expected behaviour could not be true, then a nullable guid with a null value should provoke the same behaviour.

This is based off a conversation had in gitter around the subject where @mikependon requested these issues be raised here

Library Version:

Example: RepoDb v1.12.8 and RepoDb.Postgres v1.1.4

[mikependon]

Though this is completely different from #1027, they are somewhat related in terms of changes. The changes to this is quite big and it is critical to push add given the fact that we have planned to make a stable release soon. With this, we have decided to have the fix for this be available on the next version release.

[mikependon]

We will never issue a fix to this. Please consider reading the updates to the issue #1027.

To rectify this problem, you have to explicitly do a round trip call to the database, and it is a little bit hack.