Hi!
It keeps coming back to the fact that to really have replication work
and correctly resolve in most cases we really need two things.
We need a rowid, and we need a timestamp. The rowid makes it so that
we are updating the right field and the timestamp allows us to handle
some large class of conflict resolutions (far from all, but that is a
different topic).
We keep circling around the issue of primary key and using that as
this rowid. The problem is, that not all tables have such a key, and
in many cases it would be suboptimal to use this key as the primary key.
What if instead we create two hidden fields that we do not normally
display? Sure, we can make them available if they are asked for, but
otherwise we just keep them from visual site. We can drop the fields
if a user makes a table as "do not replicate" but otherwise we will
insert them.
Thoughts?
One thing... skipping rowids is always going to keep a replication
design pretty much half assed, and is going to lead to all of the
problems we tend to see crop up today. The other DBs have solved this
by keeping some sort of public or private key, we have to find a solid
solution for this problem going forward.
Worse case? I predict we need twenty-four bytes per row (16 for the
rowid, and 8 for the timestamp).
Cheers,
-Brian
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
_______________________________________________________
You can't grep a dead tree.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
