Modified Volume Date

I'm looking to streamline my process further and also reduce the query load on the API even more by using the date_last_updated in the volume resource. What I need to know is if this date gets updated only when the actual volume information is modified or if it also gets updated when issues are added to the volume. I seem to remember the latter being the case the last time I looked at this field. If it does not get modified when issues are added could I request a new field, say something like "date_last_issue_added"? With this information, I estimate I could reduce my query load another 50%, or more, by ignoring volumes that haven't been updated or had an issue added in, say, a year.

In a previous incarnation, I was getting this information by querying every issue and storing the date of the most recent added, which realistically is not necessarily the "last" issue. This was more due to limitations within ComicRack that have now been resolved. This generated massive amounts of queries. Now I'm no longer querying every issue and looking for another means to get this data.

Thanks.

No answer from the devs? This is a pretty simple question. Does adding an issue to a volume change the date_last_updated for the volume?

Hey,

We had this weekend off this week, which is why there was no reply on Saturday.

The date_last_updated gets updated only when the actual volume gets an update. A lot of the time people will go and update the volume manually after updating an issue, but not always.

I can look at adding that field for you, seems like a nice to have. I need to look and see what other needs there are to know if we can do a more generic field that's usable outside of volumes.

I'll get back to you on this one, along with other API stuff later this week.

Sounds great, thanks!!

Thanks. After rereading this, I've realized that for my purposes, it has to be part of the volume. The volume resource is the only item I'm querying now since the ComicVine Scraper is grabbing the other information I need. The information is already part of the issue resource, which is really where it should be in a properly normalized database and I was querying every issue to get this information, but that is no longer feasible. If the intent is to keep tight query limitations, even going forward to the new servers, then some clever data denormalization might help reduce query loads, which you already have a bit of with things like first_issue and last_issue. Using my original method, a large library could easily generate 50000+ queries in just a few hours. Now, I'd estimate less than 5% of the original query load, but I no longer have the date mentioned above and have lost the ability to detect when issues have been removed from ComicVine. With the date added I could probably reduce my load perhaps another 2-3 percent if a sufficiently long time is selected and some clever coding based on the date can detect anomalies when issues are added and removed. I realize this is not a very easy thing to do since not only would the field need to be created, every volume would have to be updated.

I could modify the Scraper to pull this information and store it in the custom area, and would actually make my sorting much easier, much like how it does for volume ID now, but this is not my script and is actively developed by Cory Banack, so I'd rather not touch it. This option would also require anyone using my script, who wants to use date specific options to rescrape their entire libraries to pull in this information...again, not really a feasible option for many people.

I understand. It's certainly a bit tricky from our side, so I'm trying to figure out a good solution. We share some code between CV and GB, so I was hoping to make my solution generic enough that it could be re-used for other API needs, as opposed to building a one-off for volumes.

Will get back to you shortly on this after I have some time. I'm going to have to do this over the weekend since I'm not allotted time for this during the normal work week.