Related ewoksxas issue: https://gitlab.esrf.fr/workflow/ewoksapps/ewoksxas/-/work_items/39
Where
ewoksorange.gui.widgets.data_viewer.DataViewer
(ewoksorange/gui/widgets/data_viewer.py), method updateFile.
Verified against the installed ewoksorange==5.0.1:
def updateFile(self, filename):
if not os.path.exists(filename):
return
h5file = self.__getFileObject(filename)
if h5file is not None:
self.__refreshAction.trigger()
return
self.closeFile(filename)
model = self.__treeview.findHdf5TreeModel()
h5file = h5py.File(filename, mode="a") # <-- hardcoded
...
mode="a" is hardcoded with no way for a project using DataViewer to override
it, and no locking= argument is passed either, so the default (locking
enabled) always applies.
Problem
Projects embedding DataViewer for read-only browsing (e.g. inspecting an
HDF5 file that may be actively written by another process) have no way to:
- Open the file read-only instead of append/read-write.
- Disable HDF5 file locking to avoid contending with another process's lock
on the same file.
Proposed change
Add configurability at construction time, with the current behaviour kept as
the default so nothing else in ewoksorange/downstream breaks:
class DataViewer(qt.QWidget):
def __init__(self, parent, open_mode: str = "a", locking: bool = True):
...
self.open_mode = open_mode
self.locking = locking
And use it in updateFile:
h5file = h5py.File(filename, mode=self.open_mode, locking=self.locking)
Notes for implementation
- Default values (
open_mode="a", locking=True) preserve current behaviour
for existing callers.
- Setting
open_mode="r" together with locking=False is the case we need
downstream (ewoksxas), to browse a file without contending with another
process's write lock.
Acceptance criteria
DataViewer(parent) behaves exactly as it does today (append mode, locking
enabled).
DataViewer(parent, open_mode="r", locking=False) opens files read-only
without taking an HDF5 file lock, and can browse a file already open
(read or write) in another process.
self.open_mode / self.locking are read by updateFile (and any other
call site currently hardcoding mode="a", if more exist) rather than the
literal being duplicated.
Related
ewoksxasissue: https://gitlab.esrf.fr/workflow/ewoksapps/ewoksxas/-/work_items/39Where
ewoksorange.gui.widgets.data_viewer.DataViewer(
ewoksorange/gui/widgets/data_viewer.py), methodupdateFile.Verified against the installed
ewoksorange==5.0.1:mode="a"is hardcoded with no way for a project usingDataViewerto overrideit, and no
locking=argument is passed either, so the default (lockingenabled) always applies.
Problem
Projects embedding
DataViewerfor read-only browsing (e.g. inspecting anHDF5 file that may be actively written by another process) have no way to:
on the same file.
Proposed change
Add configurability at construction time, with the current behaviour kept as
the default so nothing else in
ewoksorange/downstream breaks:And use it in
updateFile:Notes for implementation
open_mode="a",locking=True) preserve current behaviourfor existing callers.
open_mode="r"together withlocking=Falseis the case we needdownstream (
ewoksxas), to browse a file without contending with anotherprocess's write lock.
Acceptance criteria
DataViewer(parent)behaves exactly as it does today (append mode, lockingenabled).
DataViewer(parent, open_mode="r", locking=False)opens files read-onlywithout taking an HDF5 file lock, and can browse a file already open
(read or write) in another process.
self.open_mode/self.lockingare read byupdateFile(and any othercall site currently hardcoding
mode="a", if more exist) rather than theliteral being duplicated.