Deprecate renaming index to an auto-generated name

[morozov]

Renaming an index to an auto-generated value (the one that you don't control) has little sense. The method can accept null only because internally it drops and re-adds the index, and the underlying Table#addIndex() and Table#addUniqueIndex() accept null and can auto-generate the name.

The method was introduced in #473, which doesn't any mention any requirements that would warrant such a method signature.

The $oldName variable has been renamed to $normalizedOldName just for symmetry with $normalizedNewName and to reflect the actual meaning of its value. This rename doesn't introduce any changes in the logic.

[derrabus]

Renaming an index to an auto-generated value (the one that you don't control) has little sense.

I'd rather understand this as: I don't care about the name of the index. Which impact does this change have on the ORM? Are we relying on names generated by DBAL there? If so, should we force ORM users to explicitly assign names to all of their indexes? Or should we just move the name generation downstream?

[morozov]

I'd rather understand this as: I don't care about the name of the index.

Yes. Or, more specifically, I no longer care about the name of the index. In this case, why are you changing the name? This is what makes little sense to me.

Which impact does this change have on the ORM?

The ORM doesn't use this method, so none.

Are we relying on names generated by DBAL there?

I don't think ORM relies on specific values of generated names. If it did, it would be a bug because as you said, not providing a name means "I don't care".

If so, should we force ORM users to explicitly assign names to all of their indexes?

Not yet. This PR only deprecates renaming to an auto-generated value. DBAL still generates names for user-provided indexes w/o a name and the ones that it generates automatically.

Or should we just move the name generation downstream?

Not yet, but eventually yes. DBAL itself uses auto-generated names for auto-generated (implicit) indexes, which is a can of worms and is a poor design decision. I documented this in #6881. The ORM defines the database schema based on the data model and access patterns. That includes indexes.

[derrabus]

I'd rather understand this as: I don't care about the name of the index.

Yes. Or, more specifically, I no longer care about the name of the index. In this case, why are you changing the name? This is what makes little sense to me.

Well, as long as the DBAL supports managing the index name for the application, it makes sense to me to allow the transition from an explicitly named index to a generated name and vice versa.

I understood this PR as if wanted to remove generated index names entirely, not just renaming. And correct me if I'm wrong, but that seems to be your plan, doesn't it.

If I really don't care about the name of an index and don't want to go through the struggle of finding a unique name that fits the naming constraints of all the DBMS that I want to support, why shouldn't the DBAL offer generating a name for my index?

Or should we just move the name generation downstream?

Not yet, but eventually yes.

We can do that, but tbh I believe that the DBAL is the right library for that feature.

DBAL itself uses auto-generated names for auto-generated (implicit) indexes, which is a can of worms and is a poor design decision. I documented this in #6881.

Okay, but that's kind of a different feature. Even if we removed implicit indexes, generating index names would still be a valid feature on its own imho.

[morozov]

Well, as long as the DBAL supports managing the index name for the application, it makes sense to me to allow the transition from an explicitly named index to a generated name and vice versa.

Alright. If it makes sense, let's leave it in place. I'll make sure it's properly supported and tested.