Help for working in migration 6.1 -> 7.0
Hi,
I'm working on the OpenERP project since one year. Last year I realized a migration between 5.0 to 6.1 version on my own.
I have the project to realize the migration 6.1 to 7.0 and interested to get involved in the OpenUpgrade project.
I'm searching some people to help to understand this project and work together.
Thanks for your attention.
Sylvain. (FR)
Question information
- Language:
- English Edit question
- Status:
- Answered
- Assignee:
- No assignee Edit question
- Last query:
- Last reply:
Revision history for this message
![]() |
#1 |
Hi Sylvain,
thanks for your interest! I assume you already read http://
So the general idea is to provide migrations scripts for every addon in its migrations/
You will find a file named "openupgrade_
Then you can start coding: Do as much as you can in post-migration.py, resort to pre-migration.py when necessary. As the names indicate, the first is run after the migration, the second before. Before migration, you can assume the database to be unchanged (OpenERP has not yet created new fields and deleted old ones) but you have no access to the ORM, so you need to work directly on the database. After the migration, the ORM is available but old columns are dropped and field types changed for example. So it depends a lot on the module you're working on where the good place to do the work is. In your migration scripts, you can import openerp.openupgrade which provides some helper functions like renaming columns.
So to start working in a nutshell:
bzr branch lp:openupgrade-server
bzr branch lp:openupgrade-addons
[hack hack hack]
openupgrade-
It is crucial to point to openupgrade's addons path and not the original ones. This will take a while, you need to inspect your logfile closely and if everything went right, you have a database usable with 7.0 (of course, only the parts for which migrations scripts exist)
Please don't forget to share your results, propose a merge on openupgrade-addons then.
Revision history for this message
![]() |
#2 |
Hi
Thanks for your complete response. Yes I took a look in the readthedocs website. By the way, there is a page "module coverage 6.0 -> 6.1" but no page about "6.1 to 7.0".
First I have a question. The website & your response indicate two modules. (openupgrade-server for openobject-server and openupgrade-addons for openobject-addons). I use a third official module openerp-web. There is a openupgrade-web module too or it's not necessary ? (I don't know if my question is relevant...)
Another question I have : Is there "base" module complete ? for example in 6.1 there is no "logo_web" field in res.company and in 7.0 yes.
I saw nothing in openupgrade-
Of course, i'll propose merge about my work.
+++
Revision history for this message
![]() |
#3 |
ad 0: Yes, this page has to be added. Currently it would only read 'base done, everything else tbd'. The docs are generated from http://
ad 1: The web modules (up to now) don't mess with the database. They don't declare any models and given that changes in the models is all the openupgrade server cares about, we don't need to do anything with them
ad 2: Completely new fields are handled by the server already, you don't have to create them yourself.
You would have to do something for example if logo_web should contain some default derived from existing field(s)
Revision history for this message
![]() |
#4 |
Hi Sylvian,
Im also at the beginning of my path in implementing migration scripts for version 7.0 so Im also working on understanding the project and the opoenerp structure right now.
Revision history for this message
![]() |
#5 |
About the 'base' module: it has not been extensively tested for lack of other module migration scripts. In our experience, it will mature quickly with the first production migrations.
Also, it was written when the impact of the new partner/contact model was not clear to me yet. So do I expect some changes in the logic that handles the migration from addresses to contacts etc.
Revision history for this message
![]() |
#6 |
I want to use these scripts, I even watched a talk on how to use it on youtube. But I think I need some basics (and maybe too obvious) situations.
I did a bzr checkout but I see that scripts/ also have a whole openerp instance. So first question pops up:
- Do I need to use only the openerp from the openupgrade-server pull?
The documentation instructions on how to use openupgrade are a bit confusing regarding that:
"Edit the configuration files and command line parameters to point to the database you are going to upgrade. The parameters will probably be the same as you use on your live server, except they point to the OpenUpgrade addons source code, point to the database you want to upgrade, and add the –update all –stop-after-init flags. "
I would like to see some examples regarding where it needed to be addressed.
Revision history for this message
![]() |
#7 |
Hi.
Yes to "openupgrade" a database, you have to use the openupgrade project that is like a "fork" of openobject addons & server project with script in each addons and some script in openupgrade folders. (basically).
If you want to upgrade from version X to version Y, you have to use the Y version of openupgrade.
why there is the whole instance of openerp in openupgrade ?
-> that is usefull to have the whole framework when we write scripts migrations ;
-> openerp automatically add new fields and datas and remove obsolete fields and datas ; So the most important work is avoided.
after checking out openupgrade project, you have to run openupgrade like that :
python openupgrade_
the --stop-after-init is not mandatory. if you don't use it, you can test the result by tiping http://
Revision history for this message
![]() |
#8 |
To simply run a migration, you can use this script: http://
Revision history for this message
![]() |
#9 |
Thanks Holger, can you let me know the steps to make it work, should I just drop it on the legacy OE, the new OE, is there a config argument I should also include.
ATM I have something like this:
/home/user/
/home/user/
/home/user/
/home/user/
I have the default database (sample database) with 6 common standard modules (crm, sales, purchase, projects, hr, accounting).
I download the script, I tried to run it as the following:
python migrate.py -C openerp6/
had to add the db_name=name to the openerp-server.conf on 6.x
As it ran it connect to the bzr repo and re-download the openerp-web/7.0
Hope I could have gone about this different, or is this good enough?
Revision history for this message
![]() |
#10 |
I ran the script and got the following errors on the stout:
http://
OpenERP 7 seemed to have adopted the new database (it now has the one one on 6) but when I tried to login I got the following error:
http://
OpenERP Server Error
Client Traceback (most recent call last):
File "/home/
response[
File "/home/
req.
File "/home/
if uid: self.get_context()
File "/home/
self.context = self.model(
File "/home/
result = self.proxy.
File "/home/
result = self.session.
File "/home/
raise xmlrpclib.
Server Traceback (most recent call last):
File "/home/
return openerp.
File "/home/
result = ExportService.
File "/home/
res = fn(db, uid, *params)
File "/home/
return self.execute(db, uid, obj, method, *args, **kw or {})
File "/home/
return f(self, dbname, *args, **kwargs)
File "/home/
res = self.execute_cr(cr, uid, obj, method, *args, **kw)
File "/home/
return getattr(object, method)(cr, uid, *args, **kw)
File "/home/
r = self.lookup(self2, cr, *args)
File "/home/
value = d[key] = self.method(self2, cr, *args)
File "/home/
res = getattr(user,k) or False
File "/home/
return self[name]
File "/home/
field_values = self._table.
File "/home/
res = super(users_view, self).read(cr, uid, ids, fields, context=context, load=load)
File "/home/
result = super(res_users, self).read(cr, uid, ids, fields=fields, context=context, load=load)
File "/home/
result = self._read_flat(cr, user, select, fields, context, load)
File "/home/
cr.
File "/home/
return f(self, *args, **kwargs)
File "/home/
res = self._obj.
ProgrammingError: column res_users.alias_id does not exist
LINE 1: SELECT res_users.
Revision history for this message
![]() |
#11 |
Hi Alexandro,
please post your own question instead of hijacking this thread. I will post my ideas about your problem there.
Cheers,
Stefan.
Revision history for this message
![]() |
#12 |
Sorry Stefan,
done, +question/240731
Can you help with this problem?
Provide an answer of your own, or ask Sylvain LE GAL (GRAP) for more information if necessary.