Community mailing list archives

community@mail.odoo.com

Re: Migrate :: Persist from pre- to post-

by
DevCO Colombia , David Arnold
- 06/19/2016 02:29:56
Not quite true. It will only give you postgres foreign keys. Need to think about translations, properties, xml reference and possibly functional fields. Also sequences. Anygrate was a csv based migration tool I worked a lot on, solving this is not a simple sql statement.  

I was aware of property fields and xml_ids, the latter being imo rather simple to handle. The first, I haven't looked at it yet. As to translations would it not just be enough to ignore and update translations after update? Or do you think about custom defined translations, that could get lost?

About functional fields, this might be an issue, at all, only when store true, right? What are the complications you are thinking about? 

Context: I'm trying to integrate some of this stuff into OpenUpgradlib and handle as much as possible through the ORM, so, gladly, there, some things might be abstracted away...

El dom., 19 jun. 2016 a las 1:22, Graeme Gellatly (<gdgellatly@gmail.com>) escribió:

Not quite true. It will only give you postgres foreign keys. Need to think about translations, properties, xml reference and possibly functional fields. Also sequences. Anygrate was a csv based migration tool I worked a lot on, solving this is not a simple sql statement.


On Sun, 19 Jun 2016 2:52 PM David Arnold <dar@devco.co> wrote:
This is the famous query to fish out all places relating to model. The first building block for the mentioned problem. For that it's worth sharing...

El jue., 16 jun. 2016 a las 18:41, David Arnold (<dar@devco.co>) escribió:
Hi

I want to write an updating algorithm taking advantage of the new company dependent external ids created for accounts (1_account_2530).

Basically what I want to accomplish is a check weather there was a change in the templates across module updating.

Of course I would be able to simply create a temporary database table, BUT this would not automatically fetch present (and potentially future) many2many relationships as they are stored in separate (unkown at the time of coding) tables.

Can you give me any advice on how to access/save pre-migration state across the data loding porcess?

Thanks in advance!

Best, David

_______________________________________________

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe