Fix Oracle EF Core mapping test and run the Oracle suite in CI (#394)

[jeremydmiller]

Fixes #394. Two parts: the failing assertion, and the CI gap that let it stay failing.

1. The test asserted a casing the mapping never produced

Oracle.end_to_end.can_map_entity_to_table failed against a live Oracle instance:

Shouldly.ShouldAssertException : table.PrimaryKeyColumns
    should contain "id"
    but was actually ["Id"]

There is no product bug. MapToTable sets PreserveIdentifierCase = true deliberately, so column names carry EF Core's casing verbatim. Dumping the mapped table confirms it:

Id, BoolValue, CASCADE_VAL, DateOnlyValue, DT_OFFSET_VAL, DateTimeValue,
GuidValue, IntValue, NULL_*, StringValue, TimeOnlyValue

Columns take the name given to HasColumnName() where the model configures one, and the CLR property name otherwise. Nothing is lowercased. MyEntity.Id has no HasColumnName(), so PrimaryKeyColumns returning ["Id"] is correct.

My initial reading in #394 — that PrimaryKeyColumns was failing to lowercase along with the other columns — was mistaken, and I have corrected the issue.

Why it went unnoticed, and why this is not a one-character fix. Weasel.Oracle's Table compares names with OrdinalIgnoreCase, and HasColumn uses that comparison, so

table.HasColumn("intvalue").ShouldBeTrue();

succeeds against a column actually named "IntValue" — and would succeed for any casing whatsoever. The test held fourteen assertions that could not fail plus one case-sensitive assertion written against a convention the code never had. Flipping "id" to "Id" would leave it just as unable to catch a casing regression, so the HasColumn series is replaced with a single assertion on the full column-name set, and the // Oracle lowercases column names in Weasel comment is corrected.

2. CI could not see any of this

ci-build-efcore.yml ran with --filter "FullyQualifiedName!~Oracle" because the workflow had no Oracle service, so the Oracle/ folder never executed. Fixing the assertion without fixing that would leave the next Oracle EF regression equally invisible.

Oracle now comes up through docker compose rather than as a GitHub service container, matching ci-build-oracle.yml — the container needs docker/oracle mounted as init SQL to grant the weasel user its schema privileges, which a service container cannot do.

• Scoped to the net9.0 leg only. The Oracle EF provider has no net10.0 support, so the csproj already compiles that folder out of the net10.0 build; starting a database it cannot use would only add several minutes.
• The start step runs before the SDK install and the health wait after the build, so Oracle warms up during restore and build instead of blocking on its own.
• Job timeout raised to 45 minutes to match ci-build-oracle.yml, with docker compose down on if: always().
• The filter is dropped entirely rather than narrowed: with Oracle available on net9.0, and both the Oracle and MySql folders compiled out of net10.0, each framework runs everything it actually built.

Verification

Locally against Docker: EF Core Oracle tests 3 passed / 1 skipped — the skip is the pre-existing ORA-03048 one, untouched — and Weasel.Oracle.Tests 186 passed on both net9.0 and net10.0.

The CI wiring itself can only be verified in CI, since this is the first time these tests will run there. The EF Core net9.0 check on this PR is the real test of part 2.

🤖 Generated with Claude Code