Task #5633 (closed)
Opened 13 years ago
Closed 13 years ago
Simple Silo implementation
| Reported by: | jamoore | Owned by: | jamoore |
|---|---|---|---|
| Priority: | minor | Milestone: | OMERO-Beta4.3.1 |
| Component: | General | Version: | n.a. |
| Keywords: | n.a. | Cc: | szwells, jrswedlow |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | 0.0d |
| Sprint: | 2011-07-07 (1) |
Description
As a first implementation of the service described in #4652, a subclass of the omero.tables.Tables service should be written in Python which access several OmeroTables.
- A single OriginalFile (possibly with the mimetype "OMERO.silo") will be the root of tree of OriginalFile. This file will store all configuration and ACL information about the silo itself.
- Other OriginalFile instances with the mimetype "OMERO.tables" will be attached to the silo as StructuredAnnotations.
- There will be one such OriginalFile per data type (schema) in the imported data.
- There will also be at least one extra audit OriginalFile attached, which will be written to and read from only by the silo itself (it will permanently hold the lock on the file)
This is intended as a first approximation and does not provide all the security requirements specified under #4652.
Change History (4)
comment:1 Changed 13 years ago by jmoore
- Owner set to jmoore
comment:2 Changed 13 years ago by jburel
- Sprint changed from 2011-06-02 (13) to 2011-06-16 (14)
comment:3 Changed 13 years ago by jburel
- Milestone changed from OMERO-Beta4.3 to OMERO-Beta4.3.1
- Sprint changed from 2011-06-16 (14) to 2011-06-30 (1)
Moved from sprint 2011-06-16 (14)
comment:4 Changed 13 years ago by jmoore
- Remaining Time changed from 1.5 to 0
- Resolution set to fixed
- Status changed from new to closed
With the state of the current team/josh/hic branch, this can be considered done. The command-line plugin has been refactored to use theSiloApi "interface" object which needs only a client object to function properly. Most methods take an offset and limit so that paging is always obvious (might should be optional):
In [1]: from omero.plugins.silo import SiloApi In [2]: silo = SiloApi(client) In [6]: silo.list(0, 100) Out[6]: [[2512L, '/Silos', 'Demo', 37L], [2509L, '/Silos', 'Demo', 37L], [2506L, '/Silos', 'Demo', 37L], [2504L, '/Silos', 'Demo', 37L], [2502L, '/Silos', 'Demo', 37L], [2500L, '/Silos', 'Demo', 37L], [2499L, '/Silos', 'Demo', 37L], [2498L, '/Silos', 'Demo', 37L], [2497L, '/Silos', 'Demo', 37L], [2496L, '/Silos', 'Demo', 37L], [2495L, '/Silos', 'Demo', 37L], [2494L, '/Silos', 'Demo', 37L], [2493L, '/Silos', 'Demo', 37L]] In [8]: silo.tables(2493, 0, 100)
NB: This is all taking place client-side, which will need to get addressed once we move to a Repository-based silo.
Moved from sprint 2011-06-02 (13)