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 #5633 (closed)

Opened 9 years ago

Closed 9 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 9 years ago by jmoore

  • Owner set to jmoore

comment:2 Changed 9 years ago by jburel

  • Sprint changed from 2011-06-02 (13) to 2011-06-16 (14)

Moved from sprint 2011-06-02 (13)

comment:3 Changed 9 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 9 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.

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.107877 sec.)

We're Hiring!