The root class. It overrides the equals(), hashCode() and toString() methods from the Object class. It also defines the id and version properties. All data layer classes must inherit from this class or one of it's subclasses.

Extends the BasicData class and adds an owner property. The owner is a required link to a UserData object, representing the user that is the owner of the item.

Extends the OwnedData class and adds properties (itemKey and projectKey) that holds access permission information for an item. Access permissions are held in ItemKeyData and/or ProjectKeyData objects. These objects only exists if the item has been shared.

This is a convenience class for items that extends the SharedData class and implements the NameableData and RemoveableData interfaces. This is one of the most common situations.

This is a convenience class for items that can be annotated. Annotations are held in AnnotationSetData objects. The annotation set only exists if annotations has been created for the item.

All items are identifiable, which means that they have a unique id. The id is unique for all items of a specific type (ie. class). The id is number that is automatically generated by the database and has no other meaning outside of the application. The version property is used for detecting and preventing concurrent modifications to an item.

An ownable item is an item which has an owner. The owner is represented as a required link to a UserData object.

A shareable item is an item which can be shared to other users, groups or projects. Access permissions are held in ItemKeyData and/or ProjectKeyData objects.

A nameable item is an item that has a name (required) and a description (optional). The name doesn't have to be unique, except in a few special cases (for example, the name of a file).

A removable item is an item that can be flagged as removed. This doesn't remove the information about the item from the database, but can be used by client applications to hide items that the user is not interested in. A trashcan function can be used to either restore or permanently remove items that has the flag set.

A system item is an item which has an additional id in the form of string. A system id is required when we need to make sure that we can get a specific item without knowing the numeric id. Example of such items are the root user and the everyone group. A system id is generally constructed like: net.sf.basedb.core.User.ROOT. The system id:s are defined in the core layer by each item class.

This interface is used by items which occupies a lot of disk space and should be part of the quota system, for example files. The required DiskUsageData contains information about the size, location, owner etc. of the item.

This interface is used by items which can be annotated. Annotations are name/value pairs that are attached as extra information to an item. All annotations are contained in an AnnotationSetData object.

This interface is used by items which can have extra administrator-defined columns. The functionality is similar to annotations. It is not as flexible, since it is a global configuration, but has better performance. BASE will generate extra database columns to store the data in the tables for items that can be extended.

This interface is a tagging interface which is used by items that needs batch functionality in the core.

This interface is used by items which registered the date they were created in the database. The registration date is set at creation time and can't be modified later. Since this didn't exist prior to BASE 2.10, null values are allowed on all pre-existing items. Note! For backwards compatibility reasons with existing code in BioMaterialEventData the method name is getEntryDate().

This is a tagging interface that indicates that the DbLogManagerFactory logging implementation should log changes made to items that implements it.

This interface is implemented by all items that can have files with related data attached to them. The file types that can be used for a specific item are usually determined by the main type, the subtype or platform.

This interface should be implemented by all items that can be subtyped. Unless otherwise noted the subtype is always an optional link to a ItemSubtypeData. item. In the simplest form, the subtype is a kind of an annotation, but for items that also implements the FileStoreEnabledData interface, the subtype can be used to specify the file types that are applicable for each item.