[Clas_online] JInventory

[David Lawrence]

Hi Sergey,

   Perhaps this has already been discussed, but I have a couple of 
questions/
comments on the proposed cabling schema:

1.) I'm not sure I understand the need for the red CONNECTION
table. It seems that the "board_connector_id" column could be
placed directly in the cable CONNECTOR table. The connected/
disconnected state seems implicit by virtue of having an entry
in the cable CONNECTOR table or no entry that points to the item
CONNECTOR table.

2.) How is the location in the cable CONNECTOR table different
from that in the ITEM table? (It seems all the information regarding
board and connector on board is already in the ITEM and item
CONNECTOR tables.)

3.) You might consider adding a something like a "protocol" column
to the CABLE table to hold something like "NIM", "Single-ended ECL",
etc. ... This would allow you to search cables based on that.

Otherwise, it looks pretty good. It seems flexible enough to
handle the bizarre hybrid cables the DAQ system sometimes
requires.

Regards,
-David

On 3/17/12 12:08 AM, boiarino at jlab.org wrote:
> Dear colleagues,
> attached is the proposal how cables can be presented in the inventory system,
> based on our previous discussions.
>
> Some comments:
> * ITEMs are exists in the system already, they will stay untouched; if
> some of them
> (like boards, crates, devices etc) have connectors, those CONNECTORS will
> be kept
> in the separate table, and every connector will have reference to the host
> board,
> as well as unique id, type, name and any other necessary information;
> connectors
> will NOT have a location, since they are associated already with ITEMs -
> see blue
> frame
> * new object called CABLE will used; similarly to the ITEM-CONNECTOR
> relation,
> every CABLE may have several CONNECTORS kept in separate table, and every
> connector will have reference to the host cable; main difference from the
> ITEM-CONNECTOR is that location will be associated with the CONNECTOR,
> not CABLE, it will allows to describe cable ends locations which we are
> really
> interested in; another difference from ITEM-CONECTOR is object called WIRE,
> which will be kept in separate table and describe wiring between
> particular pins
> in specified connectors - see green frame
> * CONNECTIONS is another new class; it will describe connection between
> ITEM_CONNECTOR and CABLE_CONNECTOR, which can have status 'connected'
> or 'disconnected' - see red frame
>
> Following operations can be anticipated:
> 1. ITEM (board, crate, device) record creation: as soon as item type is
> specified,
> script suppose to check if that particular type have any connectors, and
> if so,
> make corresponding entries in CONNECTOR table; those connectors will
> have a reference to the ITEM unique id and will exist as long as ITEM
> exist, and
> must be deleted if corresponding  ITEM is deleted
> 2. CABLE creation: when cable type is selected, script suppose to offer
> corresponding
> GUI to fill necessary fields, and after all info is typed in, make all
> necessary entries
> in 3 tables: CABLE, CONNECTOR and WIRE; it should be mentioned that for
> most of
> cables GUI will be rather simple: whoever will make a cable, will be asked
> to enter
> cable id, label, type and 2 connectors; connectors location are not filled
> at that
> time
> 3. CONNECTION creation: can be done during actual connection, or in advance
> setting status to 'disconnected'
> 4. Installation: by the time technicians have to install ITEMs and CABLEs,
> all those objects must be
> in the database; after installing ITEM, technician will enter its
> location; after running
> cable, he will enter its connectors locations; and finally after
> connecting cable to the
> ITEM, he will make CONNECTION entry (or change its status to 'connected'
> if connection
> is in the database already)
>
> This is the scenario I have for now, hope it will be good starting point
> for discussion.
>
> Regards, Sergey