Design restructured for easier use with 3rd party systems

The generation of the domain for searching for changes has moved to the connection classes. With this its easy possible to replace the standard domain scheme with an specialized format such as simple WHERE statements in strings. Thats usefull when implementing a connection class for a 3rd party system maybe DBMSs.

A simple example for implementing a connection to a MySQL database is available at: http://hg.holtzberg.de/synchronize_koleso

Its quite easy to implement synching capabilities  with WHERE statements as domains and a mapper dict for field transformation.

When a default value is defined on a relation field, the recursive dependent model is not synched. To get the MySQL example work with an own database, some fields have to be set to default to prevent synching the recursive dependent models:

• product.template.category => set to the id of the local desired product.category record.
• product.template.cost_price_method => fixed
• product.template.default_uom => 1 (should be the index of Unit by default)
• product.template.type => stockable

With the default values set, the only models for which data will be fetched through the MySQL-Connection object will be product.product and product.template.

Synchronize Product Module added

A new module for setting up the product models including the dependencies  for synching is now available at http://hg.holtzberg.de/synchronize_product

After installing the module it is needed to add a remote server in the admin menu. That server has to be set in the root entry of the added product models.

Push support added

The communication with the local and remote systems is now handled through connection objects that implement a common interface. This connection interface can be implemented also for other systems for which synching is desired.

The two connections to synch between are changed if synching in the other direction is wanted. The synchjob needs its own user to distinguish between real local changes and changes that result of a previous pull operation. The create_many method for speed improvement is deferred for now because of simplicity.

The user interface for configuration has also been changed to a more easy one.

The next thing is to create a module that adds the product model as a synching model. With this reviewers only have to install two modules and add a remote server before testing a synchronization.

Code cleaned and sqlite support added

Determining ids from a sequence with postgresql is not a problem but sqlite doesnt use such sequence objects, but for adding data into the database it is required to have the ids before insert. In sqlite the sequences are handled in a special system table sqlite_sequence which stores the last used value of each sequence. By manipulating this table it is possible to get unique sequence ids before inserting the records.

Another issue is that sqlite handles sorting of null fields the other way around than postgresql and does not support ORDER BY xxx DESC NULLS FIRST. Thats the reason why at the moment it isn't possible to synch with a sqlite based Tryton-server. (The slave can be sqlite based)

Updating of existing records is now possible. Furthermore a short screen cast is available on youtube to demonstrate the generic way of synching with Tryton servers. (http://www.youtube.com/watch?v=iAGP5fpdOAM)

Handling of function fields and default values is not implemented yet. Also MySQL has not been tested yet but there will also be the sequence issue.

For updating records prepared statements are not used but can be implemented if performance increase is needed. By now the write_many method only wraps the normal write method.