Kristian Nielsen wrote:
I don't think using an engine internal ROWID is a solution for replication. Such an internal id is just that - internal. And the strong point about replication is that it is external; it gives freedom to replicate data without being restricted by engine internals. The rowid you typically have in non-clustered engines such as MyISAM, Falcon, Oracle, ... is little more than a pointer to an offset into a datafile/tablespace. Now you cannot replicate between different engines, probably also not replicate between different version of the same engine (row size change?), cannot replicate between different setups of table space/storage on master and slave ... most of the benefits of MySQL-style replication seem lost.
Falcon uses a record number as a row id. But you are right -- it is internal. It is stable for the lifetime of the record, but there is absolutely no guarantee that a replicated record will have the same record number as the original database/table.
The rest of what you surmise is all correct. Record numbers in a volatile table are assigned in a non-deterministic manner -- when record stub becomes fully mature (meaning no active transaction can see it), the record is garbage collected and its record number is available for reuse. Load, concurrent transactions, phase of the moon, relative humidity, and the price of Sun stock can all have an effect.
-- Jim Starkey President, NimbusDB, Inc. 978 526-1376 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
