Further work on checksums

[mtbc]

To test, try importing and suchlike to make sure that imports and viewing still work as before, and watch the originalfile table in the database to ensure that its hash and hasher columns are properly populated.

[joshmoore]

Should hasher be set here as well?

[mtbc]

It doesn't actually have easily to hand a useful value it could set it with. With the codepaths as they are I think I satisfied myself that the PublicRepository file method accessing new files (probably?) wasn't a problem in this regard, and in RepositoryDaoImpl.createOriginalFile that does now have the relevant information so hasher gets set there instead.

If the story were less simple, though, then I'd be inclined toward a refactoring of CheckedPath and its clients that has it cache with which CheckedAlgorithm instance it was created; perhaps that is a direction we will go in anyway someday.

[joshmoore]

If it's happening later in processing, then no worries. Don't now if you want a TBD/TODO here to remind us, or if it will just happen naturally when we refactor. Up to you.

[mtbc]

I think it'll happen naturally: given what we'll have to look at, it'll be hard not to notice.

[joshmoore]

This certainly looks sounds:

omero=# select id, path, name, hasher, hash from originalfile order by id desc limit 1;
 id |               path                |           name           | hasher |                   hash
----+-----------------------------------+--------------------------+--------+------------------------------------------
 69 | user-1_8/2013-04/12/10-40-55.363/ | 1020.fake                |      6 | 0849a69d3e92fe43ef3d3bf48c0ba76cca6242cb
(1 row)

omero=# \q
omero@gretzky:~/OMERO-CURRENT$ shasum 1020.fake
0849a69d3e92fe43ef3d3bf48c0ba76cca6242cb  1020.fake

[joshmoore]

Attaching a file in the web client to 1020.fake above produced:

 id |               path                |           name           | hasher |                   hash
----+-----------------------------------+--------------------------+--------+------------------------------------------
 70 | test.xml                          | test.xml                 |        | pending

[mtbc]

Oooh, I didn't even know we could attach files in the web client. Fix that as a separate PR? (I assume this one doesn't actually change that behavior at all.)

[joshmoore]

So this is likely a hold over from your last round of fixes of "fake" hash values? If so, no real harm. The culprit is likely:

$ git grep -E "[\"\']pending" mark/trac-10338 -- components/tools/Omero{Py,Web}
mark/trac-10338:components/tools/OmeroPy/test/integration/delete.py:            oFile.setHash(omero.rtypes.rstring("pending"));
mark/trac-10338:components/tools/OmeroPy/test/integration/tickets3000.py:        oFile.setHash(rstring("pending"));
mark/trac-10338:components/tools/OmeroWeb/omeroweb/webclient/controller/container.py:        oFile.setHash(rstring("pending"));

/cc @bpindelski: these are the type of other upload code paths I was mentioning.

[mtbc]

Thanks for the pointer -- yes, I'd simply missed it before through not knowing of that upload path.

[joshmoore]

Couple of todos under 10338 and 2581, but generally sound. Merging so @bpindelski's next PR can be rebased on top.

[joshmoore]

--no-rebase