Glad to hear that the situation is more constrained than first appeared.

At that point the one suggestion I'd make is to try to structure things such that you will upgrade
the slaves prior to or in conjunction with the master. That is, have no slave at a lower rev level
than the master. That allows you to structure the views such that the higher rev levels can
successfully read from views that are missing new columns, but the master isn't constrained to write
backward-compatible changes.

As far as a messaging framework is concerned, unless you have other needs for it, I think that slony
will be an easier path for you, even with the extra views. You'll be able to structure the system
just in database terms, without too much focus on the underlying messaging.

Good luck,
Michael

On 6/1/10 7:21 AM, Lorenzo Bolzani wrote:
> 
> 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
>