BASE Development information An overview of the database schema and data layer API Array LIMS - Plates

Array LIMS - Plates

NOTE! This document is outdated and has been replaced with newer documentation. See The database schema and the Data Layer API

This document covers the plate part of the Array LIMS section.

See also

Last updated: $Date: 2009-04-06 14:52:39 +0200 (må, 06 apr 2009) $


Plates

PlateData [API] is the main class holding information about a single plate. However it all starts with the PlateGeometryData [API] which defines how many rows and columns there are on a plate. Since this information is used to create wells, and various other checks it is not possible to change the number of rows or columns once a geometry has been created. Actually, it would have been safe to change it as long as no plate mapping or plate using that geometry exists.

All plates must have a PlateTypeData [API] which defines the geometry and a set of event types (see below).

If the destroyed flag of a plate is set it is not allowed to use the plate for a plate mapping or to create array designs. However, it is possible to change the flag to not destroyed.

The barcode is intended to be used as an external identifier of the plate. But, the core doesn't care about the value or if it is unique or not.

PlateMapping

A plate can be created either from scratch or by a PlateMappingData [API]. In the first case it is possible to specify a reporter for each well on the plate. In the second case the mapping code creates all the wells and links them to the parent wells on the parent plates. Once the plate has been saved to the database, the wells cannot be modified (because they are used downstream for various validation, etc.) Again, it would have been safe to allow a well to be modified as long as no other wells are referencing it or no downstream items are using it.

Plate events

The plate type defines a set of PlateEventTypeData [API] objects. For a plate of a certain type, it is possible to attach exactly one event of each event type. The event type defines an optional protocol type, which can be used by client applications to filter a list of protocols for the event. The core doesn't check that the selected protocol for an event is of the same protocol type as defined by the event type.

The ordinal value can be used as a hint to client applications in which order the events actually are performed in the lab. The core doesn't care about this value or if several event types have the same value.