Deprecate more AbstractPlatform methods

[morozov]

Q	A
Type	deprecation
BC Break	no

1. AbstractPlatform::getSQLResultCasing() is not used anywhere and is a blatant lie per se. On the platforms like Oracle, the column case depends on whether it's quoted or not, not on the actual column name.
2. AbstractPlatform::prefersSequences() is not used anywhere and defines a poor abstraction. A platform shouldn't “prefer” anything, it should “do” something in terms of its abstraction (e.g. create an autoincrement column).
3. AbstractPlatform::supportsForeignKeyOnUpdate() is only overridden in OraclePlatform and is used only in AbstractPlatform::getAdvancedForeignKeyOptionsSQL(). But this method is also overridden in OraclePlatform, and the overridden implementation doesn't call it.

[acasademont]

Hi @morozov, I'm starting to work on making ORM compatible with DBAL 3. Right now the ORM relies on the prefersSequences method (https://github.com/doctrine/orm/blob/2.8.x/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L627). What would be the correct upgrade path here? I don't really understand why prefersSequences was removed but prefersIdentityColumns not. Thank you!!

[morozov]

@acasademont, neither the DBAL itself nor the platforms it represents don't have any notion of a preference that the prefers*() methods would express, so there's no way to tell what they should be replaced with. They were just methods that would return some values.

For the ORM, the proper replacement would probably be supportsSequences() and supportsIdentityColumns().

I don't really understand why prefersSequences was removed but prefersIdentityColumns not.

At the time of deprecation, I didn't see the prefersIdentityColumns() method existed. Otherwise, it would be deprecated as well.

[acasademont]

@morozov thanks! I agree that the notion of "preference" is a bit absurd. But unfortunately we must deal with it on the ORM, the "auto" setting (which is the default setting) when declaring an Id relies on those functions to choose the way of generating such ID, be it sequences, or auto_increments. I don't see any way around them right now without causing a quite a BC-break

The problem with methods you propose is that, for example, in Postgres, both supportsSequences and supportsIdentityColumns return true, but the "preferred" method is a sequence. On the other side, SqlServer2012 also supports both sequences and identity columns, but the "preferred" method is an identity column.

I'll open a draft PR on the ORM repo to continue the discussion there, maybe we'll need to hardcode those preferences for Postgres and SqlServer2012 on the ORM for now...

[morozov]

@acasademont what's the reason why the ORM, given multiple options, prefers one method over the other depending on the platform? Let's continue the discussion there.

[acasademont]

It gets weirded than that...

Postgres says it supports identity columns but that's not true, there's this other method usesSequenceEmulatedIdentityColumns which tells the ORM to use sequences even if the user chooses Identity as the generation strategy for the Ids instead of throwing an exception so the user can properly fix it (to increase portability of the schemas between RDBMSs?).

Oh god, this is going to be hard :p I'll keep working on the PR.

[morozov]

This is the result of the DBAL being considered "a supporting library" for ORM: tight coupling and pointless APIs.