Add Oracle-specific workaround for changing a column type

[VicDeo]

Ref owncloud/core#16812

"6.0.4 to 7.0.5 upgrade with Oracle as backend database"

[nickvergessen]

\OC::$server->getDatabaseConnection()

[VicDeo]

@nickvergessen it should reach stable7 ;)

[nickvergessen]

Well then change it in the patch that is for stable7, but on master we are not going start using private and deprecated APIs

[nickvergessen]

Am I right, that this would need backporting all the way to stable7?

[VicDeo]

@nickvergessen I think so
cc @DeepDiver1975

[nickvergessen]

\OC::$server->getLogger()->warn()

[VicDeo]

\OCP\Util::writeLog is not deprecated in master

[DeepDiver1975]

Am I right, that this would need backporting all the way to stable7?

we have to as we need to fix migration on oracle for oc6 -> oc7

[nickvergessen]

Okay, I will try to take this over from here on then

[nickvergessen]

Okay, I will try to take this over from here on then

Anyway, feel free to continue @VicDeo

[DeepDiver1975]

Anyway, feel free to continue @VicDeo

yes please @VicDeo - your task 🙊

[nickvergessen]

should be a comparison "if lower than", not equals... Otherwise 1.1.1 will not run this update, but it should

[nickvergessen]

Actually we don't need this file in stable8 and master?
Updating from 6 to 8 is not allowed?

[VicDeo]

@nickvergessen updated in accordance with your comments

[VicDeo]

@nickvergessen

Updating from 6 to 8 is not allowed?

Right.
But disabling Activity, updating 6 -> 7 -> 8 -> xxx and enabling Activity is allowed.

[DeepDiver1975]

But disabling Activity, updating 6 -> 7 -> 8 -> xxx and enabling Activity is allowed.

ouch - so true ... do we want to support such a scenario?

@karlitschek

[nickvergessen]

Well okay, the let's say the activity app does not support a major version jump:
1.1.x > 1.2.x > 2.0.x
So that should work as well?

[DeepDiver1975]

Well okay, the let's say the activity app does not support a major version jump:
1.1.x > 1.2.x > 2.0.x
So that should work as well?

well - the main problem here is that app upgrade are not triggered if they are not active - which is okay.
But this can result in the behavior as explained by @VicDeo in #308 (comment)

Until we find a better mechanism to handle migrations more seemless (pssst owncloud/core#14851 🙊 ) we might simply add the migration to every release branch - even if they are never executed?

[nickvergessen]

So we also have to bring back the update.php which was dropped because of the normally unsupported update-way?
24ab014

I mean if someone encounters the problem, we can still say, hey please upload the files of 1.2.x (oC 8.0) first then update to that version and then update to 2.0 (oC 8.1)?

[DeepDiver1975]

So we also have to bring back the update.php which was dropped because of the normally unsupported update-way?
24ab014

I mean if someone encounters the problem, we can still say, hey please upload the files of 1.2.x (oC 8.0) first then update to that version and then update to 2.0 (oC 8.1)?

valid point as well ....

[VicDeo]

I never argue for a long time (and don't use Oracle anyway).
Let those unsupported migrators die if it looks correct from your standpoint.

[nickvergessen]

Yeah, lets just fix this in 6>7 then