Fix EZP-21585: set correct col. length for oracle

[gggeek]

I detail: properly declare all oracle columns lengths using CHAR semantics, to allow for UTF8.
While at it, set the length for all BLOBS we shorten to 4k instead of arbitrary 3000 or 3100

Meant to replace both #18 and ezsystems/ezpublish-legacy#811

[gggeek]

Note: now when we use ColumnTypeTranslation in dbschema.ini.append.php, the max length for varchar cols has to be set to 1000.
Affected known extensions: ezsurvey.
Maybe a BC note would also be good.

[bdunogier]

In ref to the other issues with the "hack".

To be clear, @gggeek, your fix is clearly better. A bit of a shame it came
after the merge, but still better.

What bothers me a bit is that ezoracle is no longer actively developped. It
is supposed to be maintained, that's all.

And while it is better from a technical pov, I'm not sure of what to think
from a support pespective. We could have it in master, of course, but it
wouldn't do our customers any good.

[gggeek]

Indeed it poses a bit of a challenge:

• more change for existing customers (risk)
• but less chances of extra bugs in the future from new customers (f.e. when they could complain that in russian or japanese they can not really go all the way up to 255 chars for the title) (benefit)

[dpobel]

The update SQL script is missing otherwise the upgrade check won't like it.

[gggeek]

Well, my idea was that customers could actually use the upgrade-check exactly to get the sql generated for them which would set the schema to the new version.
But if this workflow is not considered acceptable, I can provide a script, of course (NB: it is going to be a php script, not an SQL one, as it has to iterate over all tables, including the ones coming from extensions)

[dpobel]

you can not just send the customers to the upgrade check to get the SQL, if for instance they have a custom table, it will suggest to remove it.
The usual practice is to have either a SQL or php script to update the database schema (nothing new here...). IMHO, the SQL would be better, the tables to change are known.

[gggeek]

Nitpick: suggestion for custom tables to be removed only happens if extensions do not implement the proper .dba table definition as per the standard. I know that a lot of user-extensions (and sadly even some eZ-ones) do not respect that standard, so I agree that we can not just uphold it blindly.

As for table list: no it is not known, as this change applies to all tables, including ones from extensions - the only way to do the change in pure sql would be via a PL-SQL program

[dpobel]

The tables from our extensions that need to be fixed should be identified and the corresponding setting should then be added to dbschema.ini.append.php otherwise the upgrade check will report a warning.

[gggeek]

Added update script - as PLSQL procedure.

As for other extensions, I used an advanced search on github (https://github.com/search?q=ColumnTypeTranslation+%40ezsystems+extension%3Aphp&type=Code&ref=advsearch&l=PHP)
and found only ezsurvey