Closed roji closed 5 years ago
@roji We are planning to remove anything that is marked as Obsolete in 3.0. There should already be a way to replace any of these calls with other, non-obsolete code that achieves the same objective. For example, code that is using the old type mapping API should move to using the new API.
We already did this for 2.0, so there should not be any obsolete APIs that remain from pre-2.0 days, unless we missed some. Also, we tend to create issues like some of these for specific cases where we need to do cleanup and just searching for Obsolete is not sufficient to find the case.
Keeping this open as a work item to track doing this work.
Great!
When we remove FallbackTypeMappingSource
, we should consider updating CoreTypeMappingSource
to map value types, string
, and byte[]
.
In addition to obsolete methods, we should collapse overloads that were added to prevent breaks around parameter defaults. (They couldn't be marked obsolete)
Remaining work here that is not tracked by other issues is:
In addition to obsolete methods, we should collapse overloads that were added to prevent breaks around parameter defaults. (They couldn't be marked obsolete)
There are several obsolete APIs that have been accumulated over the versions, and still exist in order to maintain backwards compatibility. I'm hoping it's planned to remove these for version 3.0, to keep the codebase clean and lean.
This could be a matter of going over everything tagged with
[Obsolete]
, but it may be worth listing and tracking in an issue.ITypeMapper
and derived,FallbackTypeMappingSource
).MigrationsSqlGenerator.ColumnDefinition
that doesn't acceptFixedLength
DefaultQuerySqlGenerator.GenerateBinaryOperator(ExpressionType)
(there are obviously many more).
Some of these could be a bit tricky, as they'd require potentially considerable effort to port to the newer APIs (I'm thinking about the old type mapping for example). It may make sense to carefully evaluate, API by API, whether it's worth it to remove or not.