1ianreads
Does it bother anyone else that when Edit History for a book gets Initialized, there isn't really a complete snapshot that gets made?
If you currently add a book, you get an entry in the history with all the fields you entered. If you later change or delete a field, you can go back to that initial record to restore it. If you make later changes, you can restore them from there.
However, for books that need their Edit History initialized, there is (needless?) potential for data loss. If you save an uninitialized book, say after deleting half of the comments field and deleting the other authors, the state of the fields before your edit is not saved. If you want the other authors or the previous version of your comment back, it's not there. If you edit the title a year later and change your mind, there is nothing to restore. If you edit the title a second time, however, you can get back your first edited version (and all subsequent versions). In effect, for uninitialized books, you always lose one version of each field (the oldest).
Is this clear enough? Has this been discussed before? Am I wrong? Is the data there, but is there a UI issue, making it not show up? Is this a bug or a feature request?
If you currently add a book, you get an entry in the history with all the fields you entered. If you later change or delete a field, you can go back to that initial record to restore it. If you make later changes, you can restore them from there.
However, for books that need their Edit History initialized, there is (needless?) potential for data loss. If you save an uninitialized book, say after deleting half of the comments field and deleting the other authors, the state of the fields before your edit is not saved. If you want the other authors or the previous version of your comment back, it's not there. If you edit the title a year later and change your mind, there is nothing to restore. If you edit the title a second time, however, you can get back your first edited version (and all subsequent versions). In effect, for uninitialized books, you always lose one version of each field (the oldest).
Is this clear enough? Has this been discussed before? Am I wrong? Is the data there, but is there a UI issue, making it not show up? Is this a bug or a feature request?
2keristars
The edit history only applies after you've created the record and saved it. That is the initialization.
It doesn't/can't save your data as you type. The web form doesn't work like a local db or Word document.
It doesn't/can't save your data as you type. The web form doesn't work like a local db or Word document.
3eclbates
>2 keristars: For books entered prior to the creation of the Edit History function last year, it works a bit differently than books imported and edited after the system rolled out. I'm currently playing around with some of my older books, trying to find some that haven't initialized, because I have not experienced this.
Found one! I see what you mean. I have a book that has not initialized, and not been edited since I entered it in 2012. If I make any changes to it, the edit history will initialize and snapshot the new changes only, not the existing data that was overwritten.
I think this is a 'request for improvement' rather than a bug, since the system is just recording changes, not the status of the entire record.
https://www.librarything.com/topic/373960 "In the near future we plan to add more ways to restore previous states from the edit history, including adding a way to restore deleted books and see all changes from the original source (e.g., the original Amazon or library record) for older books." Looks like it is a work in progress.
Found one! I see what you mean. I have a book that has not initialized, and not been edited since I entered it in 2012. If I make any changes to it, the edit history will initialize and snapshot the new changes only, not the existing data that was overwritten.
I think this is a 'request for improvement' rather than a bug, since the system is just recording changes, not the status of the entire record.
https://www.librarything.com/topic/373960 "In the near future we plan to add more ways to restore previous states from the edit history, including adding a way to restore deleted books and see all changes from the original source (e.g., the original Amazon or library record) for older books." Looks like it is a work in progress.
4ianreads
>3 eclbates: I think so too. Glad you get what I mean!
--
I think it just feels a little backwards to me. When you make a change it records the latest version (which you can just find in your current record) instead of the previous version.
There should be many ways to mitigate this. (1) If an edit is done to an "uninitialized field", which can happen long after the edit history itself was initialized, add an entry in the history with the previous value at the time of edit. Or (2) switch the version which gets saved in the history to the previous instead of the latest.
If edit history is powered by a sql trigger or something, it should have access to both versions of the fields at the time of saving. In any case, this is code, so anything should be possible!
Glad to see that it is still a work in progress. The feature feels like it has been around for much longer, but apparently I've only known about since about a month :-)
If I manage to write it up in a way that's makes my point more clearly, I should add it to that thread or post an RSI. @knerd.knitter, does that make sense? Thanks again for a pretty slick feature, btw!
--
I think it just feels a little backwards to me. When you make a change it records the latest version (which you can just find in your current record) instead of the previous version.
There should be many ways to mitigate this. (1) If an edit is done to an "uninitialized field", which can happen long after the edit history itself was initialized, add an entry in the history with the previous value at the time of edit. Or (2) switch the version which gets saved in the history to the previous instead of the latest.
If edit history is powered by a sql trigger or something, it should have access to both versions of the fields at the time of saving. In any case, this is code, so anything should be possible!
Glad to see that it is still a work in progress. The feature feels like it has been around for much longer, but apparently I've only known about since about a month :-)
If I manage to write it up in a way that's makes my point more clearly, I should add it to that thread or post an RSI. @knerd.knitter, does that make sense? Thanks again for a pretty slick feature, btw!
5knerd.knitter
>4 ianreads: I understand your question; I'd have to look back at the code to see why we did it the way we did it. It was a while ago!
