[IMP] queue_job: OpenUpgrade migration script from 9.0

[pedrobaeza]

Same as #20 with a renaming complement.

[sbidoul]

I suggest adding, 'If this is not done, all connector.* xmlids are removed due to the module renaming done by OpenUpgrade. In the future the approach sketched in #23 (comment) may provide a more generic solution.'

[coveralls]

Coverage remained the same at 77.94% when pulling ad09595 on Tecnativa:10.0-queue_ou into 6c9d7b7 on OCA:10.0.

[sbidoul]

Thanks Pedro. Can you remove the trailing whitespace to make pylint happy?

[simahawk]

isn't this going to fail if you don't have openupgradelib in your python env?

[pedrobaeza]

Of course, but it's a requirement for OpenUpgrade

[simahawk]

I'd say we should not assume that ppl are going to use it to do the migration. Can't we wrap it in a try/except ImportError and log the error?

[hbrunn]

finally somebody who agrees with me

[pedrobaeza]

My explanation continues the same that in that moment. The script is not going to be executed if you are not migrating.

[pedrobaeza]

@hbrunn the problem is then you are requiring that library for the normal fresh installation of the module where most people are not going to migrate in life (bad for them).

[hbrunn]

true. But I envision a world where basically any OCA module depends on openupgradelib, then we can harness its full power when radically changing the database layout somewhere in the lifecycle of a release. Actually, I sometimes find myself avoiding big changes just because I'd hate the idea to write a script like that without openupgradelib.

[pedrobaeza]

Yeah, me too, but I don't want to modify the external dependencies of this module as it has been a total pain and they will put problems for that. I won't contribute anymore to this repository.

[sbidoul]

FWIW I personally think that

1. using openupgradelib in migration scripts is tremendously helpful
2. it's a lightweight dependency, I see no issue to depend on it explicitly and we must put it in external dependencies when we use it

[sbidoul]

I won't contribute anymore to this repository.

@pedrobaeza I really don't understand why you react like that. This repo is one of the best managed OCA repos. And the debate was nothing else than people (not exactly newbies btw) trying to get a deep understanding of a complex issue. And a good idea emerged of the discussion.

[coveralls]

Coverage remained the same at 77.94% when pulling 6c2d675 on Tecnativa:10.0-queue_ou into 6c9d7b7 on OCA:10.0.

[coveralls]

Coverage remained the same at 77.94% when pulling 6c2d675 on Tecnativa:10.0-queue_ou into 6c9d7b7 on OCA:10.0.

[coveralls]

Coverage remained the same at 77.94% when pulling f642f25 on Tecnativa:10.0-queue_ou into 6c9d7b7 on OCA:10.0.

[coveralls]

Coverage remained the same at 77.94% when pulling f642f25 on Tecnativa:10.0-queue_ou into 6c9d7b7 on OCA:10.0.

[hbrunn]

thanks btw, if that's not clear from the discussion above 😉

[guewen]

Thanks all. I'm happy we reached a common agreement and that we learned more about openupgrade in the process.

[guewen]

Yeah, me too, but I don't want to modify the external dependencies of this module as it has been a total pain and they will put problems for that. I won't contribute anymore to this repository.

Sorry you see it like that.