View Single Post
Old 05-19-2015, 02:32 AM   #17
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 12,476
Karma: 8025702
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Quote:
Originally Posted by kovidgoyal View Post
@chaley: If you are worried about the non-atomic part, you can change the code to generate a new uuid and only set the old uuid for the moved record after deletion of the exisiting record completes.
I am not worried enough about it to get into that level of change. Book matching (and content server fetching by UUID) will work acceptably as long as the UUID is unique within a library. If the same UUID exists in two libraries then it is possible to have books on the device get new metadata on connect, but this is already made possible by title/author matching.

One possible problem: as far as I can tell nothing checks that the UUID is in fact unique in a given library. There isn't a constraint on the table and set_uuid seems not to check. I think that the only way this "hole" could be exploited is via DB recovery, which unconditionally sets the UUID to the one in the metadata.inf. Perhaps recovery should check, and if the UUID is already there create a new one. I will look at it.
chaley is offline   Reply With Quote