speed up migrationPage

[Kathrin-Huber]

fixes #4384

[matthias-ronge]

This makes method processOwnsYearXML(Process process) in FileService dead code and you could delete it. Alternative suggestion: You combine the two methods processOwnsYearXML(Process process) and processOwnsYearXML(Process process, boolean forIndexingAll) in FileService (line 589−603) to this one method:

public boolean processOwnsYearXML(Process process) throws IOException {
    URI yearFile = createYearFile(getMetadataFilePath(process, false, true));
    return fileExist(yearFile);
}

That should have the same effect.

[Kathrin-Huber]

Thats a pretty good idea! That way I also found that processOwnsAnchorXML was dead.

[henning-gerhardt]

Your changes did not solve the issues mentioned in #4384 as your changes are inside the migration itself and not on displaying the newspaper batches. So you may rename the pull request title and remove the "fixes #4384".

[henning-gerhardt]

I must partial revert my last comment as I got confused by the changes which including some refactoring. On a new migrated database the values for processBaseUri did not get updated any more and this is a big improvement for migration speed. But this pull request (or at least the current version of it) did not solve the slow page displaying at all as the check for the year.xml files are still executed and this takes still a lot of time (even less then storing the changed value in processBaseUri to the database and maybe index).

So far as I know the database and its entries there is a type field in batch table which is holding the information about what kind of batch is stored. Is this not enough to decide the displayed batches on the newspaper migration page?

[matthias-ronge]

Slow file system access is a different issue (#3300) which also needs to be taken looked after, but I think this pull request fixes the database updates, and this is what talks are about in #4384

Using the batch.type field should be the best solution to find newspaper batches, I agree to this.