I know that similar questions have popped up here before, but I'd like to know if what I'm planning on doing is okay (or can, with slight adjustments, be made okay). So, according to the API terms, 1.B.3, you shouldn't hold onto the data indefinitely. It seems, based on other questions I've seen in these forums, that the reasons are to 1) get more up to data information if the database changes, 2) acknowledge that I don't own the data (and must show the user of the app that the data came from TMDb), and 3) provide a way to revoke access (though other posts have said that this had never happened up to this point).
So here's what my app will do. It's purpose is to help organize your DVD / Blu-Ray collection. Part of that is getting rid of the jacket that the disc(s) came with. So, I'm offering the ability to take a snapshot of the jacket plus enter information about cast / crew, categories, year, length, etc. It would be great to get most (or maybe even all) of that information from a service like this (with the user having the option to pick and choose which pieces of information they want to get from the service and which parts they want to enter themselves). The problem though is that I would like to persist that information indefinitely for a couple of reasons. First, the user might be trashing / recycling the cover jacket from the movie, so I really don't want the information disappearing on them in the future. Second, I want the user to have the ability to edit the entries (either for corrections or just edited according to personal taste). Once an entry is altered, it would be difficult to figure out how to merge that in with the updated data. For example, if they added a cast member (maybe it was someone who had an uncredited role), I wouldn't want it to be deleted after an update. If they changed the spelling of something (or maybe listed two different characters played by the same actor), I wouldn't want that edit to be overwritten. And if they delete something (maybe they have a thing against Johnny Depp, for example, and want to erase all references to him), I wouldn't want it to pop back up again. Even after an edit, though, I would always have the entry marked so that I know that some information came from TMDb (and could display the logo, etc.).
So, does my app seem incompatible with the intended usage of the API?
Thanks.
Can't find a movie or TV show? Login to create it.
Ĉu volas taksi aŭ aldoni ĉi tiun elementon al listo?
Ĉu ne estas membro?
Respondo de Travis Bell
je Septembro 1 2016 je 6:10 PM
Hi Jason,
Your reasons are correct but keeping a cached copy of the data is generally ok. From TMDb's point of view, all that needs to happen if we asked is the removal of the data that came from us.
The way I would build this if I was wanting to merge locally edited data like that would be to create 2 tables. One that contains all of the TMDb data, and the other than contained any local overrides. This way the data is kept separate and can be easily purged, replaced or updated without touching your local user edits. Then on render time, if a override existed for the piece of data in question you simply show it instead.
Does that make sense?
Respondo de Jason Bertschi (Jaded Bucket, LLC)
je Septembro 1 2016 je 7:12 PM
Thanks for the reply.
While I understand that having two tables might work some of the time (maybe even most of the time), that doesn't always work (having used diff / patch for a few decades, I know that problems of intent can occur quite often). I'd much rather have a way for the user to manually choose the updated information (with maybe an alert when something changes, and a list of all the entries that have changed). I could even go further and have an easy auto-update option for entries that they didn't alter (though I'd rather have that be a preference that the user could choose). It's just those edited entries that I'd really rather not try to mess with... Is that okay (just giving them the option and not forcing an update)?
By the way, if it makes any difference, I wasn't planning on storing the information on some server that I own or control. The information would be stored on the users' devices.