SQL Generation via marten-patch finds difference in partitions

[DeJerre]

Registering a class via options.Schema.For<ClassName>.DatabaseSchemaName("customschema").SoftDeletedWithPartitioningAndIndex()
and running marten-patch via the oakton commands results in a SQL file being created with the following content:
CREATE TABLE customschema.mt_doc_class_name_deleted partition of customschema.mt_doc_class_name for values in (TRUE)

Applying these created scripts via Grate results in the tables and partition being created in PostgreSQL with the following partition expression FOR VALUES IN (true)

During a refresh of the table structure via marten-patch a difference in partition definition is found. The expected partition definition is FOR VALUES IN (TRUE) and the retrieved value is FOR VALUES IN (true)

In PartitionExtensions.cs:28 the FormatSqlValue<T> does an ToUpperInvariant() in the case of a bool value. In ListPartition.cs:32 the Parse() method reads the current value stored in the PostgreSQL instance containing the lower-case value. In ListPartitioning.cs:96 the IPartitionStrategy.CreateDelta() method checks if other._partitions.Any(x=> !partitions.Containx(x)) resulting in a Rebuild of the parition that does exist with a different casing on the parition values.

Tested via docker database with version postgres:16.3

[jeremydmiller]

@DeJerre It was technically correct to make this issue in Weasel, but I don't monitor Weasel's issue list nearly as closely as I do Marten, so I just saw this today. I think this has already been addressed by recent changes to Weasel & Marten, but I'll verify that soon.

Sorry for the delay here.

[jeremydmiller]

The soft deleted partition problem was fixed, but in testing this w/ Marten, I found an additional issue with foreign keys when using the partitioning

[jeremydmiller]

Weirder, this only fails in the command line. I would have sworn up and down there's no difference in functionality between the CLI and directly using IDocumentStore.Storage

[jeremydmiller]

Ugh, ugh, ugh. Weasel is "finding" the existing foreign key that's really attached to the partition table and thinking that exists on the parent table. That's the culprit. Ick, ick, ick.

[jeremydmiller]

Got it! It's going to take a Weasel upgrade to finish this off, but it's on the way.