On Wed, Nov 16, 2016 at 7:59 AM, Keith Medcalf <kmedc...@dessus.com> wrote:
> Using the systemid sequence and the recordid sequence directly however, > has a 0% probability of collision, so any rational person would use that > directly and forgo entirely the introduction of uncertainty and bugs using > "UUID" type crappola will cause. > As Dominique said, the issue here is decentralization... and i would add, particularly in a disconnected environment and/or one with no central authority. The method you describe does not handle device rollbacks or cloning. For example, one of your systems is a mobile device with it's own unique system id. Periodically, this device broadcasts its inserted data to other devices. Also, the user backs up the device to their PC every now and then. At some point the mobile device gets lost or damaged. When they restore from backup, the last few sequential ids from that system id get reused and collide. It is also possible to restore from backup to a different device, even if the original is still alive and well, at which point you have two different devices with the same system id broadcasting colliding keys. Theoretically a new, unique system id should be generated any time a system is backed up or copied anywhere. But when the backup/copying logic is completely independent and unknowing of your systemid, you are left with needing to detect if the physical device has changed. This may be unreliable or impossible on some platforms. And i don't think it would be possible to detect the case where a rollback happened on the same physical device. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
