use $schemaClosure in migration

[notEvil]

fixes #2980

Please note that I'm not particularly familiar with php and the codebase in general. The solution is a proposal.

[dartcafe]

Thanks. But should it not be enough to return the schema, used by the migration method?

[notEvil]

No, because in the context of convert-type it is has to operate on a different database. During migration, the class gets instantiated only once, remembering the source schema (say SQLite) in the process. However, it then needs to create the tables on the target schema (say Postgres) using the target connection. So it needs to delegate the actual execution to Nextcloud.

[dartcafe]

Sorry, my time is again limited, but now I had the time to look over it and check the aftermath of it. And find out there should none, since createTables is the only method called inside the migration atm, this should work and not break the commands.

It wasn't a good idea anyways to build this up with separate schemas for the tableManager and the indexManager, but I have this on my to do list for later.

New migrations according to the app version are preferred over changing migration methods, but in this particular situation I am sure it is ok.

TLDNR: LGTM

[dartcafe]

Thanks for contribution!!

[dartcafe]

Please note that I'm not particularly familiar with php and the codebase in general.

Fun fact. I am not even a programmer and had no clue of PHP or JS when I started contributing here .

[notEvil]

Interesting :)

Regarding the failed check:
https://github.com/nextcloud/server/blob/e9ac0287f2b7d4da856bec416a282c8fc4c7feab/lib/private/DB/MigrationService.php#L444C3-L444C3
passes a OC\DB\SchemaWrapper but declares it as OCP\DB\ISchemaWrapper. And my quick and dirty solution was to not care about the type. This is where someone with more experience immediately knows what to do about it, closing the circle.

[dartcafe]

Erks. I think, we need another approach. I will come back to it later. Currently I'm rather busy.

[dartcafe]

Superseded by #3024