BUG: Tables warning group is None

[spli]

2013-11-14 03:49:35,515 INFO  [                            omero.remote] (Dummy-
3   )  Meth: TableI.close
2013-11-14 03:49:35,515 INFO  [                 omero.tables.HdfStorage] (Dummy-
3   ) Size: 1 - Detaching Table-331928F1-F1DD-4C4C-A84C-AEED74F98C31 from /OMERO
/Files/Dir-009/9755
2013-11-14 03:49:35,516 INFO  [                 omero.tables.HdfStorage] (Dummy-
3   ) Cleaning storage: /OMERO/Files/Dir-009/9755
2013-11-14 03:49:35,518 INFO  [                     omero.tables.TableI] (Dummy-
3   ) Closed Table-331928F1-F1DD-4C4C-A84C-AEED74F98C31
2013-11-14 03:49:35,519 WARNI [                     omero.tables.TableI] (Dummy-3   ) Cannot update file object 9755 since group is none

On ome-ci-c6-07 and other servers. Might be related to OMERO.searecher, though given the timestamp it's probablty something else.

Josh's comment:
this may have been fixed, in which case you could try removing that clause. If not, you could do another query to load the group: iquery.projection("select f.details.group.id from OriginalFile? f where f.id = :id", {"omero.group":"-1"})

[spli]

I've tried creating a table in the default and different group, closing, closing the session, reopening the table in a new session, haven't reproduced this yet. However it does regularly occur when doing a search with OMERO seearcher (even though the search shouldn't require writing to the table).

[spli]

Also tried creating the table as one user in a read-only group and reading it as a different user- again no warnings.

[spli]

This occurs when the file object supplied to openTable is unloaded, e.g.

t = sess.sharedResources().openTable(omero.model.OriginalFileI(301), opts)

[spli]

Whilst investigating this I've come across another problem (on develop):

2013-11-19 18:01:15,003 WARNI [                     omero.tables.TableI] (Dummy-3   ) Failed to update file object 302
Traceback (most recent call last):
  File "/Users/simon/work/openmicroscopy.dev/dist/lib/python/omero/tables.py", line 601, in close
    self.file_obj.id.val, file_obj.hash.val, file_obj.size.val)
AttributeError: 'NoneType' object has no attribute 'val'

from a logging statement ​tables.py:600 close()

file_obj.hash is null so reading file_obj.hash.val causes the above exception. Does this mean the hasher/hash should've been created (in ​SharedResourcesI.java:289 newTable()? Or should the log statement be modified to allow a null hash?

[jamoore]

I would definitely think being null-friendly for logging would be a good idea (from omero.rtypes import unwrap as _; _(file.hash), ...) but most likely this does count as a bug. Adding Mark for discussion.

[mtbcarroll]

If the hash is null it might be nice to have the hasher null too, but it presumably is. When files are written with the raw file store, and hasher is set on those files, then the RFS will calculate hash upon save. If other code also writes files and it does make sense to keep a hash of them (i.e. it's not an enormous table where the occasional cell will frequently change) then, yes, probably that code should also be writing non-null hash, but also it absolutely makes sense for logging to be null-safe.

Generally we should probably be on the look-out for non-directory entries appearing in the original file table without an accompanying hash.

Code that does write hashes should probably notice the omero.checksum.supported server configuration property and the manner of its use by ManagedRepositoryI.suggestChecksumAlgorithm: the import process allows the client to choose a hash algorithm. Jean-Marie suspects that we might want to use different algorithms (slow, fast, etc.) for different kinds of upload.

[spli]

In develop: ​https://github.com/openmicroscopy/openmicroscopy/pull/1807