New data

This is an interesting problem, and it seems like there's a lot to talk about.

The conclusion I made was that bad data should not be saved. I'm paranoid about destructive tools when they're making guesses about how to interpret input. It wasn't clear enough to me what the client was expecting with the updates, since ISBNs must be different for each printing of a book and the IDs were changing. The new titles gave away the probable aim, but I don't trust making changes on arbitrary text like that.

My changes merged in from the editions-model branch are hypothetical, in that I would have loved to talk with the user, client, and/or teammates before proceeding with it. The migrations to the Edition model are pretty hefty and irreversible, the user experience in the admin changes a bit, and the expectation of data is maybe(?) a heck of a lot different. More exploratory than anything else.

I'd argue that editions should hold uniquely identifying data and have canonical book parents for relating to each other. So the XML would have to conform to some new rules based on agreements with client, product manager, devs, and so on. I provided a new update-4.xml to show how I envisioned a new edition working.

+ An edition will be updated if the ISBN-13 matches another (barring other conflicts)
+ An edition will be created if there is no ISBN-13 match, either creating a new book with it or attaching to one based on book_id matching
+ An edition will not be saved where there are unique data conflicts (and the user will be informed)
- No way to update ISBN-13 from the tool
- Needs more tests!
- Handles conflicts by not handling conflicts

Thanks! This was fun. I'd love to talk more about it.