Steve, thanks for the pointer, I have the book but never found the time to
actually read it beyond the first chapters. i'll check it for ideas.


Michael, the scenario is simpler than the one you described.

There are three isolated installations located in three different cities.
Each one is upgraded when possible, strictly one at a time.
Each upgrade, as usual, could imply a data migration step from the old to
the new version.

The new requirement is to centralize part of the data, like the plant
personnel data, the vehicles data and the products catalogue (petroleum
materials). The rest of the data is unique for each installation.

All the editing on these items will be done connecting remotely to the
master installation. The changes should be replicated in almost real time to
the other plants (even to the same one where the changes are made from). We
expect very little activity on these items, something like a dozen of edits
per day on about 10 tables.

Slave plants have to be autonomous in case of network failure so all the
data has to be available locally.

There is not the requirement to change the plant that acts as the master.

Up to this point I would think slony is the ideal tool.


As you said, every time you upgrade any installation you need to test all
the new scenarios and this IS hard. The only thing mitigating this is the
expectation (hope?) for these tables to be typically quite stable. And the
schema differences checks could be automated with a simple script.


Accepting this, the only remaining issue are the differences in the schemas
that maybe could be fixed with a view/trigger "hack" as proposed. I do not
like this, but the option of a message based solution looks worse and
presents most of the same problems. BTW I do not now of any lightweight Java
data integration message framework.


Bye


Lorenzo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20100601/a5d7cece/attachment.htm