[IMP] queue_job: OpenUpgrade migration script from 9.0#24
Conversation
| if not version: | ||
| return | ||
| # In order to migrate connector from v. 9.0 to v. 10.0, we need to set | ||
| # connector module state to 'to upgrade' |
There was a problem hiding this comment.
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.'
|
Thanks Pedro. Can you remove the trailing whitespace to make pylint happy? |
| SET state='to upgrade' | ||
| WHERE name='connector' | ||
| """) | ||
| from openupgradelib import openupgrade |
There was a problem hiding this comment.
isn't this going to fail if you don't have openupgradelib in your python env?
There was a problem hiding this comment.
Of course, but it's a requirement for OpenUpgrade
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
My explanation continues the same that in that moment. The script is not going to be executed if you are not migrating.
There was a problem hiding this comment.
@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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
FWIW I personally think that
- using openupgradelib in migration scripts is tremendously helpful
- 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
There was a problem hiding this comment.
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.
1 similar comment
1 similar comment
|
thanks btw, if that's not clear from the discussion above 😉 |
|
Thanks all. I'm happy we reached a common agreement and that we learned more about openupgrade in the process. |
Sorry you see it like that. |
7 participants
Same as #20 with a renaming complement.