Almost all classes in the CDM implement ICdmBase, an interface that specifies common attributes which are:
package eu.etaxonomy.cdm.model.common; public interface ICdmBase { /** * Returns local unique identifier for the concrete subclass * @return */ public int getId(); /** * Assigns a unique local ID to this object. * Because of the EJB3 @Id and @GeneratedValue annotation this id will be * set automatically by the persistence framework when object is saved. * @param id */ public void setId(int id); public UUID getUuid(); public void setUuid(UUID uuid); public DateTime getCreated(); /** * Sets the timestamp this object was created. * * @param created */ public void setCreated(DateTime created); public User getCreatedBy(); public void setCreatedBy(User createdBy); }
Although all instances have a primary key (id
)
that is used by any database software, this should not be used to refer to
the entity in an application. Instead, a surrogate key
(uuid
) is used to identify entities. Both values are
auto-generated, uuid
when the object is created,
id
at the point the object is persisted (through a call
to save
or
saveOrUpdate
).
Throughout the CDM, temporal data is represented using the Joda Time API rather than
the standard java Calender implementation. All CdmBase classes have a
property that gives their time of creation (created
,
populated automatically), and the User
that created
the object. The user is retrieved from the security context automatically
by the persistence layer (for more on security in the CDM, authentication
and authorization, see the section on security). For those applications that do not
wish to use the security infrastructure, the User can also be set
explicitly by the application.