Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

Task #11697 (closed)

Opened 10 years ago

Closed 10 years ago

BUG: Tables warning group is None

Reported by: spli Owned by: spli
Priority: minor Milestone: 5.0.0-rc1
Component: General Version: 5.0.0-beta1
Keywords: n.a. Cc: mtbcarroll, analysis@…
Resources: n.a. Referenced By: n.a.
References: n.a. Remaining Time: 0.0d
Sprint: n.a.


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
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"})

Change History (8)

comment:1 Changed 10 years ago by 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).

comment:2 Changed 10 years ago by spli

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

comment:3 Changed 10 years ago by spli

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

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

comment:4 Changed 10 years ago by spli

  • Remaining Time set to 2
  • Status changed from new to accepted

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?

comment:5 Changed 10 years ago by jamoore

  • Cc mtbcarroll added
  • Milestone changed from OMERO-4.4.10 to 5.0.0-beta2
  • Version changed from 4.4.9 to 5.0.0-beta1

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.

comment:6 Changed 10 years ago by 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.

comment:8 Changed 10 years ago by spli

  • Remaining Time changed from 2 to 0
  • Resolution set to fixed
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.69334 sec.)

We're Hiring!