This forum is now just an archive. Use the new Q&A website
It is currently Fri Apr 25, 2014 5:30 am

All times are UTC + 2 hours




Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 28 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: OpenERP 6.0.1 to 6.1
PostPosted: Sat Jan 28, 2012 4:43 am 
Offline

Joined: Sun Aug 28, 2011 7:03 pm
Posts: 10
Location: Philippines
Hi.

Is it really that hard to upgrade from 6.0.1 to 6.1? I've been working with OpenERP for about 6 months only. My worries is if it will affect my existing database. I have some questions below.

1. Can I upgrade from 6.0.1 to 6.1 without upgrading from 6.0.1 to 6.0.2 and 6.0.3?
2. If the answer from number 1 is yes; I am using Ubuntu 10 server, how can I upgrade from 6.0.1 to 6.1? Is it a copy paste and just overwrite your existing openerp server files?
3. Are there any tutorials on how to do it.

Many thanks to you guys.


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Sat Jan 28, 2012 11:28 am 
Offline

Joined: Mon Aug 08, 2011 9:52 am
Posts: 273
Location: Reeuwijk Netherlands
At this moment there is only 6.1rc1. Nobody knows 6.1 already.
I have seen a lot of things that are not compatible between 6.x.x and 6.1rc1.
I do not expect 6.0x and 6.1 will be compatible.
Because of the business model of OpenERP, one of the income flows for the developers is to sell you migration from one version to the other.
The other way is to do the migration yourself by hand, a lot of work and not easy.
As an alternative you can try to make your own migration tool and share it with us, a lot of work and not easy.
You can also stay with your version and hope somebody else will make such a module are wait untill you are ready to pay for the migration services.
You can also try to find something else. When you are a small company you can also start all over again (you have only 6 months of administration).


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Wed Feb 15, 2012 3:49 am 
Offline

Joined: Thu Feb 09, 2012 9:31 am
Posts: 12
Location: What's the point of fields that store 0 characters?
I'm in the process of doing a test-migration of a 6.0.2 database across to 6.1rc1. I'm a complete newcomer to OpenERP, having only started developing on it about a fortnight ago, so this is something of a baptism of fire.

What follows are some notes that got something up and running on my local instance so I could explore OpenERP 6.1. It may or may not work for you, and of course, there is no warranty whatsoever.

1. Fix up the 'serioalization_field_id' KeyError bug:
Code:
   ALTER TABLE ir_model_fields ADD column serialization_field_id int references ir_model_fields on delete cascade;


Reference:
https://bugs.launchpad.net/openobject-s ... bug/908069

2. Drop some modules temporarily:

You might find you get duplicate certificate errors out of SQL; these were the specific offenders I came across, your list may be different. I am not certain that deleting them is the right answer here, but it at least gets past the blockage.

Code:
   DELETE FROM ir_module_module WHERE certificate='00899858104035139949';
   DELETE FROM ir_module_module WHERE certificate='001056784984222247309';
   DELETE FROM ir_module_module WHERE certificate='001278773815818292125';


3. Add new columns to ir_module_module:

Code:
   ALTER TABLE ir_module_module ADD COLUMN "sequence" integer;
   ALTER TABLE ir_module_module ALTER COLUMN "sequence" SET DEFAULT 100;
   ALTER TABLE ir_module_module ADD COLUMN complexity character varying(32);
   ALTER TABLE ir_module_module ADD COLUMN icon character varying(128);
   ALTER TABLE ir_module_module ADD COLUMN application boolean;
   ALTER TABLE ir_module_module ALTER COLUMN application SET DEFAULT false;


4. Add new columns to res_company:

These I think are part of account_voucher, but I found I could not do anything until I manually added them.

Code:
   ALTER TABLE res_company ADD COLUMN expense_currency_exchange_account_id integer;
   COMMENT ON COLUMN res_company.expense_currency_exchange_account_id IS 'Expense Currency Rate';
   ALTER TABLE res_company ADD COLUMN income_currency_exchange_account_id integer;
   COMMENT ON COLUMN res_company.income_currency_exchange_account_id IS 'Income Currency Rate';


5. Update all modules

Code:
   openerp-server --db_host=localhost --log-level=debug -r openerp -d development --update=all


Finger's crossed, you should at least be able to log in and do things. I find that much of the data survived, and now it's a matter of getting views and custom modules going.


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Wed Feb 15, 2012 10:03 am 
Offline

Joined: Sun Dec 28, 2008 1:03 pm
Posts: 200
Location: Genoa
Relevant threads:
post46371.html#p46371
post90298.html#p90298
post81769.html#p81769

_________________
Lorenzo Battistini
http://planet.domsense.com/en/author/elbati/
http://www.agilebg.com/


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Fri Feb 17, 2012 8:46 pm 
Offline

Joined: Fri Feb 17, 2012 6:32 am
Posts: 3
Redhatter wrote:
I'm in the process of doing a test-migration of a 6.0.2 database across to 6.1rc1. I'm a complete newcomer to OpenERP, having only started developing on it about a fortnight ago, so this is something of a baptism of fire.

What follows are some notes that got something up and running on my local instance so I could explore OpenERP 6.1. It may or may not work for you, and of course, there is no warranty whatsoever.

Thank-you so much for the suggestions. I figured out how to run your code, but it took a little bit of playing around. For the benefit of others, and additional assistance, I'll report my results here. Code inside asterisks needs replaced with user-specific values.

I first logged into my postgres database using this command:
Code:
psql -h localhost *nameofopenerpdatabase* openerp

Once logged in, I was able to run the database commands you specified:
Code:
   ALTER TABLE ir_model_fields ADD column serialization_field_id int references ir_model_fields on delete cascade;
   DELETE FROM ir_module_module WHERE certificate='00899858104035139949';
   DELETE FROM ir_module_module WHERE certificate='001056784984222247309';
   DELETE FROM ir_module_module WHERE certificate='001278773815818292125';
   ALTER TABLE ir_module_module ADD COLUMN "sequence" integer;
   ALTER TABLE ir_module_module ALTER COLUMN "sequence" SET DEFAULT 100;
   ALTER TABLE ir_module_module ADD COLUMN complexity character varying(32);
   ALTER TABLE ir_module_module ADD COLUMN icon character varying(128);
   ALTER TABLE ir_module_module ADD COLUMN application boolean;
   ALTER TABLE ir_module_module ALTER COLUMN application SET DEFAULT false;
   ALTER TABLE res_company ADD COLUMN expense_currency_exchange_account_id integer;
   COMMENT ON COLUMN res_company.expense_currency_exchange_account_id IS 'Expense Currency Rate';
   ALTER TABLE res_company ADD COLUMN income_currency_exchange_account_id integer;
   COMMENT ON COLUMN res_company.income_currency_exchange_account_id IS 'Income Currency Rate';

From there, I could exit the postgres client (/q), stop openerp (/etc/init.d/openerp stop) and run your final command in the console. I had to modify it a bit to make it work, since I have a password on my database. Here's the command I got to work:
Code:
openerp-server --db_host=localhost --db_password=*databasepassword* --log-level=debug -r openerp -d *nameofopenerpdatabase* --update=all

Once that completed, I exited the command (CTRL+X), and restarted the openerp server (/etc/init.d/openerp start).

This allowed me to use my 6.0 database in 6.1! I've only found one error so far. When I hit the settings tab I get this message:
Quote:
Uncaught TypeError: Cannot read property 'view_mode' of undefined
http://localhost:8069/web/webclient/js? ... stock:5490

Is this something to be scared about? Can it be fixed?


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Fri Feb 17, 2012 8:55 pm 
Offline

Joined: Wed Feb 16, 2005 12:26 pm
Posts: 2746
Location: Annecy & Toulon,France
batonac wrote:
Is this something to be scared about?
yes
batonac wrote:
Can it be fixed?
you have to migrate the database format. This is not trivial.
regards

_________________
SISalp's free openerp hosting http://sisalp.fr/openerp-serveur-gratuit.html


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Fri Feb 24, 2012 5:48 am 
Offline

Joined: Thu Feb 09, 2012 9:31 am
Posts: 12
Location: What's the point of fields that store 0 characters?
batonac wrote:
This allowed me to use my 6.0 database in 6.1! I've only found one error so far. When I hit the settings tab I get this message:
Quote:
Uncaught TypeError: Cannot read property 'view_mode' of undefined
http://localhost:8069/web/webclient/js? ... stock:5490

Is this something to be scared about? Can it be fixed?


Well, it's good to know those steps at least partially worked for someone else. I didn't strike your issue… the first thing I'd be looking at is any custom modules which you may have. To be honest, I have no idea, there's a lot of voodoo within OpenERP and I'm only just scratching the surface.

For completeness, the following is currently being used in a shell script to "automatically" migrate our production 6.0 instance over for a development 6.1 instance.

Code:
        echo '******************************************************'
        echo '** PLEASE NOTE: This is for migrating 6.0->6.1 only **'
        echo '******************************************************'
        psql --username=openerp --host=localhost ${dst_db} << END_PSQL
        -- Delete troublesome module certificates --
        DELETE FROM ir_module_module WHERE certificate='00899858104035139949';
        DELETE FROM ir_module_module WHERE certificate='001056784984222247309';
        DELETE FROM ir_module_module WHERE certificate='001278773815818292125';
        -- Add in new module fields --
        ALTER TABLE ir_module_module ADD COLUMN "sequence" integer;
        ALTER TABLE ir_module_module ALTER COLUMN "sequence" SET DEFAULT 100;
        ALTER TABLE ir_module_module ADD COLUMN complexity character varying(32);
        ALTER TABLE ir_module_module ADD COLUMN icon character varying(128);
        ALTER TABLE ir_module_module ADD COLUMN application boolean;
        ALTER TABLE ir_module_module ALTER COLUMN application SET DEFAULT false;
        -- Add in company resource fields --
        ALTER TABLE res_company ADD COLUMN expense_currency_exchange_account_id integer;
        COMMENT ON COLUMN res_company.expense_currency_exchange_account_id IS 'Expense Currency Rate';
        ALTER TABLE res_company ADD COLUMN income_currency_exchange_account_id integer;
        COMMENT ON COLUMN res_company.income_currency_exchange_account_id IS 'Income Currency Rate';
        -- Add in new model fields --
        ALTER TABLE ir_model_fields ADD column serialization_field_id int
                references ir_model_fields on delete cascade;
        -- Uninstall Thunderbird module --
        ALTER TABLE ONLY public.thunderbird_installer DROP CONSTRAINT thunderbird_installer_write_uid_fkey;
        ALTER TABLE ONLY public.thunderbird_installer DROP CONSTRAINT thunderbird_installer_create_uid_fkey;
        ALTER TABLE ONLY public.thunderbird_installer DROP CONSTRAINT thunderbird_installer_pkey;
        ALTER TABLE public.thunderbird_installer ALTER COLUMN id DROP DEFAULT;
        DROP SEQUENCE public.thunderbird_installer_id_seq;
        DROP TABLE public.thunderbird_installer;
        DELETE FROM ir_act_window WHERE name='Install Thunderbird Plug-In';
        DELETE FROM ir_act_window WHERE name='Thunderbird Plug-In Configuration';
        DELETE FROM ir_model_fields WHERE model LIKE 'thunderbird.%';
        DELETE FROM ir_model_fields WHERE name='thunderbird';
        DELETE FROM ir_model_access WHERE name='ir.actions.todo.thunderbird.installer';
        DELETE FROM ir_model_data WHERE module='thunderbird';
        DELETE FROM ir_model_data WHERE name LIKE '%thunderbird%';
        DELETE FROM ir_model WHERE model LIKE 'thunderbird.%';
        DELETE FROM ir_ui_menu WHERE name LIKE 'Thunderbird%';
        DELETE FROM ir_ui_view WHERE model LIKE 'thunderbird.%';
        DELETE FROM ir_ui_view WHERE name LIKE 'thunderbird.%';
        DELETE FROM ir_module_module WHERE name='thunderbird';
        DELETE FROM ir_translation WHERE name LIKE 'thunderbird%';
END_PSQL
        su openerp -c 'openerp-server \
                -c /etc/openerp/openerp-server.conf \
                --db_host=localhost \
                --log-level=debug \
                -r openerp \
                -d development \
                --update=all \
                --stop-after-init'
        # Run it again to make sure!
        su openerp -c 'openerp-server \
                -c /etc/openerp/openerp-server.conf \
                --db_host=localhost \
                --log-level=debug \
                -r openerp \
                -d development \
                --update=all \
                --stop-after-init'
        psql --username=openerp --host=localhost ${dst_db} << END_PSQL
        -- Having updated schemas, migrate contact last names --
        UPDATE res_partner_contact SET last_name=name;
        UPDATE res_partner_contact SET name=last_name||' '||first_name WHERE first_name IS NOT NULL;
        UPDATE res_partner_contact SET name=last_name WHERE first_name IS NULL;
        UPDATE res_partner_address SET contact_id=res_partner_job.contact_id FROM res_partner_job WHERE res_partner_job.address_id=res_partner_address.id AND res_partner_address.contact_id IS NULL;
        UPDATE res_partner_address SET function=res_partner_job.function FROM res_partner_job WHERE res_partner_job.address_id=res_partner_address.id AND res_partner_address.function IS NULL;
        UPDATE res_partner_address SET email=res_partner_job.email FROM res_partner_job WHERE res_partner_job.address_id=res_partner_address.id AND res_partner_address.email IS NULL;
        -- Fix action for scheduling --
        UPDATE ir_act_window SET context='{}' WHERE name like 'Schedule %' AND
                res_model like 'project.compute.%';
END_PSQL
        # Run once more
        su openerp -c 'openerp-server \
                -c /etc/openerp/openerp-server.conf \
                --db_host=localhost \
                --log-level=debug \
                -r openerp \
                -d development \
                --update=all \
                --stop-after-init'


This gets our particular instance about 90% there. Still some niggling issues, but it mostly works okay. The big issue being that the new base_contact module now looks for some information in res.partner.address instead of res.partner.job; so I've had to massage the database somewhat to get that data over.

I'm also looking at the project management stuff, Faces integration is lacking, I have some patches to fix some of this, but I'm also discovering that Faces has some rather critical omissions and is very difficult code to follow, and so I'm also looking at other options including integration of resourcelevel (written in Ruby) and/or going the DIY route.


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Sun Feb 26, 2012 1:15 am 
Offline

Joined: Sun Nov 14, 2010 2:00 am
Posts: 9
Hi Everybody,

The change in base_contact makes trouble in migrating but is the good approach. However, before migrating please check my work to try to complete the new approach in
https://code.launchpad.net/~openerp-com ... inalise6.1
and contribute.

For the structure please check that the name should remain the last_name. For references i added the field full_name


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Sun Feb 26, 2012 10:00 pm 
Offline

Joined: Mon Feb 23, 2009 2:20 pm
Posts: 5
After you update database you must to run:

Code:
update ir_sequence set implementation = 'no_gap';


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Tue Feb 28, 2012 5:49 pm 
Offline

Joined: Fri Feb 17, 2012 6:32 am
Posts: 3
I'm so glad people are working on this... do you think this info could/should be compiled in a community wiki somewhere?


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Wed Feb 29, 2012 6:15 am 
Offline

Joined: Thu Feb 09, 2012 9:31 am
Posts: 12
Location: What's the point of fields that store 0 characters?
Okay, I had a closer look at what was happening in base_contact this morning, and below, is an updated migration script for that part:

Code:
        -- res_partner_address is now res_partner_location --
        UPDATE  res_partner_location
        SET     create_uid=1,
                create_date=now(),
                write_uid=1,
                write_date=now(),
                city=a.city,
                zip=a.zip,
                street2=a.street2,
                country_id=a.country_id,
                company_id=a.company_id,
                street=a.street,
                state_id=a.state_id
        FROM    res_partner_address AS a
        WHERE   a.location_id=res_partner_location.id;
        -- Having copied the data over, we remove it from the old place --
        UPDATE  res_partner_address
        SET     city=NULL,
                zip=NULL,
                street2=NULL,
                country_id=NULL,
                company_id=NULL,
                street=NULL,
                state_id=NULL
        WHERE   location_id IS NOT NULL;
        -- res_partner_job is now res_partner_address.  Copy over the data --
        UPDATE  res_partner_address
        SET     contact_id=res_partner_job.contact_id,
                function=res_partner_job.function,
                email=res_partner_job.email,
                phone=res_partner_job.phone,
                fax=res_partner_job.fax
        FROM    res_partner_job
        WHERE   res_partner_job.address_id=res_partner_address.id;
        -- Remember that there is a many-to-one relationship between      --
        -- jobs and addresses.  So we delete the records that are done so --
        -- we don't double up.                                            --
        DELETE FROM res_partner_job
        USING   res_partner_address
        WHERE   res_partner_job.address_id=res_partner_address.id
        AND     res_partner_job.contact_id=res_partner_address.contact_id
        AND     res_partner_job.function=res_partner_address.function
        AND     res_partner_job.email=res_partner_address.email
        AND     res_partner_job.phone=res_partner_address.phone
        AND     res_partner_job.fax=res_partner_address.fax;
        -- This leaves us with the left-overs --
        INSERT INTO res_partner_address (
                create_uid, create_date, write_date, write_uid, fax, street2,
                phone, street, active, partner_id, city, "name", zip, title,
                country_id, company_id, birthdate, state_id, "type", email,
                "function", color, location_id, contact_id
        )
        SELECT  1,              -- create_uid
                NOW(),          -- create_date
                NOW(),          -- write_date
                1,              -- write_uid
                j.fax,          -- fax
                NULL,           -- street2
                j.phone,        -- phone
                NULL,           -- street
                'T',            -- active
                a.partner_id,   -- partner_id
                NULL,           -- city
                NULL,           -- name
                NULL,           -- zip
                NULL,           -- title
                NULL,           -- country_id
                a.company_id,   -- company_id
                NULL,           -- birthdate
                NULL,           -- state_id
                a.type,         -- type
                j.email,        -- email
                j.function,     -- function
                NULL,           -- color
                a.location_id,  -- location_id
                j.contact_id    -- contact_id
        FROM    res_partner_address as a,
                res_partner_job as j
        WHERE   j.address_id=a.id;
        -- We can now drop res_partner_job --
        DROP TABLE res_partner_job;


This seems to catch most of the corner cases quite well. It is safe to run this after running my earlier-submitted script. Naturally this version can only be run once as it deletes res_partner_job at the end.


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Thu Mar 01, 2012 11:27 am 
Offline

Joined: Tue Jan 19, 2010 12:24 pm
Posts: 141
Location: Amsterdam
Hi,

you are of course very welcome to exchange large chunks of SQL, but you may find the OpenUpgrade project easier to share your efforts. See https://launchpad.net/openupgrade-server. This software also comes with a log tool that should make it relatively easy to compare differences in database layouts of different versions of the OpenERP server with the same set of modules installed.

Here is a matrix with the modules covered for migration between 6.0 and 6.1:

http://readthedocs.org/docs/openupgrade-server/en/latest/modules60-61.html

Cheers,
Stefan.

_________________
http://therp.nl - OpenERP implementaties, Amsterdam, Nederland.


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Fri Mar 02, 2012 12:58 am 
Offline

Joined: Mon Nov 07, 2011 6:30 pm
Posts: 15
Location: Netherlands
Is there a tutorial available to to preform a update?

I started with version 6.0.3 but I find it hard to get hold on to an update/upgrade tool or documentation to preform the upgrade to the 6.1 version.


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Fri Mar 02, 2012 11:52 am 
Offline

Joined: Fri Mar 02, 2012 11:01 am
Posts: 3
Location: Switzerland
This is a very useful thread. Thank Redhatter very much for your scripts. It saved me many hours to figure out the errors by ourselves. I managed to make V6.1 code run with our V6.0.3 database successfully in one day. Though we have not done any functional test yet, it's already a good start.

How to migrate to latest version really depends on your database version and size, customization etc... Here is some experience I would like to share with community:

FYR, we have an implementation of 50 users, multi companies, multi currencies, since 2009, full installation of all major addons modules plus 30 extra-addons modules heavily customized by us, some tables contain +100K lines of records.

If you migrate from V5 to V6, I suggest checking out the addons and server of V6 directly.
If you migrate from V6.0.3 to V6.1.1, I suggest checking out the addons and server of V6, and then do a bzr merge with your V6.0.3, resolve the conflicts (usually migration from the minor version changes, not so many conflicts). The reason is some bugs fixed by you/community in V6.0.3 are not always accepted in V6.1.1. This is a safe approach.

After you prepare the source code, here are the steps for database:
1. Make a copy of existing db, disable all the customized modules including yours and ones from community
2. Run pre-SQL scripts to fix all the known errors
3. Start server with --database=dbName --update=all
4. Install your customized modules or extra-addons from community one by one, or all in once with --database=M1 --init=m1,m2,m3...
5. Run post-SQL scripts to fix all the errors introduced by your customized modules
6. Start server with --database=dbName --update=all
7. Manual configuration if necessary
8. Full user acceptance testing

You may have to repeat the steps 1-7 several times to fully prepare for the pre-SQL and post-SQL scripts.


Top
 Profile  
 
 Post subject: Re: OpenERP 6.0.1 to 6.1
PostPosted: Fri Mar 02, 2012 12:04 pm 
Offline

Joined: Mon Nov 07, 2011 6:30 pm
Posts: 15
Location: Netherlands
fwang wrote:
This is a very useful thread. Thank Redhatter very much for your scripts. It saved me many hours to figure out the errors by ourselves. I managed to make V6.1 code run with our V6.0.3 database successfully in one day. Though we have not done any functional test yet, it's already a good start.

How to migrate to latest version really depends on your database version and size, customization etc... Here is some experience I would like to share with community:

FYR, we have an implementation of 50 users, multi companies, multi currencies, since 2009, full installation of all major addons modules plus 30 extra-addons modules heavily customized by us, some tables contain +100K lines of records.

If you migrate from V5 to V6, I suggest checking out the addons and server of V6 directly.
If you migrate from V6.0.3 to V6.1.1, I suggest checking out the addons and server of V6, and then do a bzr merge with your V6.0.3, resolve the conflicts (usually migration from the minor version changes, not so many conflicts). The reason is some bugs fixed by you/community in V6.0.3 are not always accepted in V6.1.1. This is a safe approach.

After you prepare the source code, here are the steps for database:
1. Make a copy of existing db, disable all the customized modules including yours and ones from community
2. Run pre-SQL scripts to fix all the known errors
3. Start server with --database=dbName --update=all
4. Install your customized modules or extra-addons from community one by one, or all in once with --database=M1 --init=m1,m2,m3...
5. Run post-SQL scripts to fix all the errors introduced by your customized modules
6. Start server with --database=dbName --update=all
7. Manual configuration if necessary
8. Full user acceptance testing

You may have to repeat the steps 1-7 several times to fully prepare for the pre-SQL and post-SQL scripts.


In item 2 you mention pre-SQL scripts and item 7 post-SQL scripts.
Which are those scripts?


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 28 posts ]  Go to page 1, 2  Next

All times are UTC + 2 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:

Protected by Anti-Spam ACP