Re: [Modeling-users] Future directions: replication and auto-increments

[Sebastien B. <sbi...@us...>]

        Hi Erny,

  This particular point can be easily solevd if you could plug-in your
own algorithm to generate PK values --then they would be generated the
appropriate way. Are you going this way and would you test it if it is
implemented?

-- S=E9bastien.




PS: Oh, BTW, TemporaryGlobalIDs are identified by host, ip and time :)

Ernesto Revilla <er...@si...> wrote:
> Hi,
>=20
> when talking with some Python people, I heard about future requirements
> about multi-master replication. This is what you need if you have data sp=
lit
> over several offices and you have no 100% uptime links. Multi-master
> replication is available in mysql, but Postgresql still is lacking this
> feature. I think Oracle as it also.
>=20
> The problems you can have with multi-master replication are the update
> collisions. But these may not be very usual in real scenarios, depending =
how
> data is organized.
>=20
> The first problem of all is that we can't use auto-increment (serial)
> fields. So we have to use our own function to produce this. For this to
> work, the original autoincremen field is defined as large integer, someth=
ing
> like 64 bits, where a part is reserved as a local counter and the other p=
art
> as station identifier which created the object, e.g. 16 bit station
> identifier + 48 bit counter. There are other, more complicated, algorithm=
s,
> like those which create a global unique id (GUID) bases on the Ethernet
> address and time, and distributed scenarios, where there is a process whi=
ch
> gives new hi-numbers to stations (which in turn can fragment the bits use=
d,
> say 16 into 8+8 and give their own low part hi number to other stations,
> producing a hierarchical system).
>=20
> Concluding, IDs should not be created by database systems, but by the
> middleware in a nuclear operation.
>=20
> With best regards, Erny