10-22-2017, 06:53 PM
(10-21-2017, 02:11 AM)Zuberman Wrote: So I looked at the code, and if you just replace the file on the file system, it will not update the page order. There are a couple of reasons why this is so:Hi Mike,
1) I no longer have access to the previous version of the file, so I don't know if the full range of pages was being used (I don't save that information currently).
2) If you had a page order of 1-3 in a 5 page file, and that was intentional, and then you update to a 6 page file, you probably don't want the application resetting your page order just because an extra page was added to the file
The only time I will update the page order is if the previous page order references a page greater than the maximum page of the new file. In that case, I have to reset the page order because it's invalid at that point. So if you want the page order to be correctly updated when swapping in a new version of a file where the number of pages has changed, you'll have to use the swap file feature. The other option would be for me to start adding additional information in the database about the properties of the file such as the maximum number of pages so that I can access this information even if the file no longer exists. I'm not opposed to that, but the problem is if I add that field to the database, I then need to populate it, which is only possible by opening every single file in the library. I'm not sure I want to do that as part of the database upgrade phase, as some people have huge libraries and that could take a long time. That means I would have to populate it the next time a song is loaded and I detect that information about the file is missing in the database. If you replaced files you hadn't loaded recently, then I wouldn't be able to properly handle those. This new database field also would only make sense for PDFs, as text/chord pro files have dynamic content with no fixed number of pages and image files are always just one page.
Kind regards,
Mike
I gave this a few thoughts and I mostly agree with you on this.
I also agree that probably adding a field PageCount (or however you'll name it) would be a good idea.
However I don't see that adding such a field would require to access each and every file. As I see it a good estimate of its value would be to just copy the upper bound of PageOrder. In all cases where this has not been adjusted manually this already holds the correct value. In all other cases (presumably a small number anyway) the value being too low will not cause any harm. And when this filke is updated the next time it will be corrected "automagically".
Therefor I'd propose to add a column PageCount and populate it with the current maximum page as of PageOrder. That should be possible with 2 SQL stmts and would not involve scanning all the files.
Am I overlooking something?
Kind regards,
Michael