DB records "out of sync"

I am working on migrating from 3.4 to 5.0. The database successfully updates to 5.0, and runs (with some bug still being ironed out). I notice in Administration > Models > Models > Data that almost all records are “Out of Sync” (about 6,000 out of sync, from about 7,000 total). Most of these are records I would not have changed.

When I try to sync the records through the GTK, it generally has no effect. Whether I sync them individually, or as a group, the sync operation seems to complete, but most of the models still show as out of sync.

Any advice? Thank you, in advance, for your help.

For me it is related to Issue 7761: ModelData records are considered out of sync after migration to 5.0 - Tryton issue tracker

@ced I agree that this looks like the same as Issue 7761, but I am not seeing advice on a recommended solution for when the sync button doesn’t work.

It is working it is just that the system keep thinking it is not.

@ced So should I ignore the continued display that the records are out of sync?

I have noticed that, upon db update, I am getting warnings that some records are not being updated because they have been changed (including a record that I need to update). I assumed this has to do with the out-of-sync issue.

As long as you do not have any other issues.

when i have this kind of issue, i use this workaround Upgrade to 5.2 : ir_rule_group is null - #2 by semarie

i can’t remember when tryton-console was introduced, but it should work with the python console too

I think I am having other problems because, in doing db update, I get many warnings of the form “X not updated (id: Y), because it has changed since the last update.” I assumed these arose from the sync issue. Is that a wrong assumption?

You assumption is right. Any record that is not outdated will be shown as out of sync latter so the user can sync them latter.

Does anyone have a suggestion for how to fix these objects so they will update?

And please help me understand @ced 's comment that “It is working, it is just that the system keeps thinking it is not.” If that is so, then why are the objects skipped in db update?

It seems that there are some syncing fixes applied to 5.2 that can address this issue. (I am reluctant to move to 5.2, because it is no longer supported.) Would the devs entertain backporting these patches[1][2] to 5.0?

[1] trytond/ir/model.py - Issue 45971002: trytond: Improve sync of data - Code Review
[2] trytond: 70904e384bd0

depending the exact objects (could you extract the list of module/model of the records out of sync ?), it might need to do others steps before being able to sync. for example, if the records are part of the chart of accounts, you need to update your chart of account and next resync again.

when updating (I am following the mercurial head, so I am doing that about once a month), my steps are:

  • do a backup of the database (using pg_dump)
  • update the modules (trytond-admin -v -c config.conf -d DATABASE --all)
  • update the modules list (trytond-admin -v -c config.conf -d DATABASE --update-modules-list)
  • synchronize out-of-sync records
  • update the chart of accounts

and loop the whole procedure while there are out-of-sync records.

did you have tested that these particulars patches solves your problem ?

@semarie, thank you so much for sharing your procedure! As to whether the patches solve my issues, the answer is that most records can now sync. There remain about 30 that won’t.

Most of these give the error, The value of the field 'View Type' on 'View' is not valid according to its domain. These are not from official Tryton modules.

For the models of the type ir.property, the sync button does nothing.

In addition to these records that list as not synced, when I do DB update, there XML records (not listed) that yield warnings of the form WARNING trytond.convert Field XX of YY not updated (id: ZZ), because it has changed since the last update.

I am still working though these issues.

It is probably wrong data in those module.

ir.property does not exist anymore. Normally there should be an update SQL query to remove them.

it may or may not be a problem. But we need more information.