Closed DizzyDeveloper closed 7 months ago
Am I right in assuming that the migration in question was generated before the upgrade to EF 8.0, and started failing after upgrading to 8.0?
If so, this is probably due to us removing the option to map ValueTuple<IPAddress, int>
to PG cidr
in Npgsql 8.0 (breaking change note). As a result, EF just sees a general value tuple, which gets mapped to a PG "row value" via NpgsqlRowValueTypeMapping - a row value in SQL is e.g. WHERE (x, y) > (1, 2)
. That type mapping is (currently) very restricted in what it can do - it only supports some very specific scenarios. But in any case, that's not what you want - you're looking to have a cidr in the database.
To summarize, this is a result of the same breaking change in 8.0. The best solution here is probably for you to go over your migrations and replace new System.ValueTuple<System.Net.IPAddress, int>
(the old mapping type) with new NpgsqlCidr()
(the new mapping type).
Heya @roji,
Thanks mate that was spot on. Fixed my issues :)
We are in the process of upgrading from ef core 6 to ef core 8, and consequently the efcore.pg libraries (from now on when I refer to ef core X, I am also refering to the EF Core Npgsql packages) . However, since upgrading to ef core 8 we have started encountering the following exception during our migration tests:
Our migration tests where running fine on ef core 6, and as an additional test the same migration test are fine on ef core 7 as well. We have only encountered this issue since upgrading to ef core 8. After debugging the migrations a tad more I have worked out that the offending column that is leading to the above exception is:
This error occurs on the migration that adds the 'Address` column to the table, i.e. when its creating the ALTER TABLE statement for that column.
The corresponding Migration has this snippet in it:
Ef Core 8 does not seem to like the default value.
FYI Addendum:
For the sake of trying something I manually updated the snippet above to include the
defaultValueSql
as the code appears to take that if the it exists. So addeddefaultValueSql: "'0.0.0.0/0'"
, so above becomes:And then the migration tests all appear to happily start run again.