Page History
...
DSpace 6 database schema (PostgreSQL). Right-click the image and choose "Save as" to save in full resolution. Instructions on updating this schema diagram are in How to update database schema diagram.
- DSpace uses FlywayDB to perform automated database initialization and upgrades. Flyway's role is to initialize the database tables (and default content) prior to Hibernate initialization.
- The
org.dspace.storage.rdbms.DatabaseUtils
class manages all Flyway API calls, and executes the SQL migrations under theorg.dspace.storage.rdbms.sqlmigration
package and the Java migrations under theorg.dspace.storage.rdbms.migration
package. - Once all database migrations have run, a series of Flyway Callbacks are triggered to initialize the (empty) database with required default content. For example, callbacks exist for adding default DSpace Groups (
GroupServiceInitializer
), default Metadata & Format Registries (DatabaseRegistryUpdater
), and the default Site object (SiteServiceInitializer
). All Callbacks are under theorg.dspace.storage.rdbms
package. - While Flyway is automatically initialized and executed during startup, various Database Utilities are also available on the command line. These utilities allow you to manually trigger database upgrades or check the status of your database.
- The
- DSpace uses Hibernate ORM as the object relational mapping layer between the DSpace database and the DSpace code.
- The main Hibernate configuration can be found at
[dspace]/config/hibernate.cfg.xml
- Hibernate initialization is triggered via Spring (beans) defined
[dspace]/config/spring/api/core-hibernate.xml
. This Spring configuration pulls in some settings from DSpace Configuration, namely all Database (db.*) settings defined there. - All DSpace Object Classes provide a DAO (Data Access Object) implementation class that extends a GenericDAO interface defined in
org.dspace.core.GenericDAO
class. The default (abstract) implementation is inorg.dspace.core.AbstractHibernateDAO
class. - The DSpace Context object (
org.dspace.core.Context
) provides access to the configuredorg.dspace.core.DBConnection
(Database Connection), which is HibernateDBConnection by default. Theorg.dspace.core.HibernateDBConnection
class provides access the the Hibernate Session interface (org.hibernate.Session) and its Transactions.- Each Hibernate Session opens a single database connection when it is created, and holds onto it until the Session is closed. A Session may consist of one or more Transactions. Sessions are NOT thread-safe (so individual objects cannot be shared between threads).
- Hibernate will intelligently cache objects in the current Hibernate Session (on object access), allowing for optimized performance.
- DSpace provides methods on the Context object to specifically remove (
Context.uncacheEntity()
) or reload (Context.reloadEntity()
) objects within Hibernate's Session cache. - DSpace also provides special Context object "modes" to optimize Hibernate performance for read-only access (
Mode.READ_ONLY
) or batch processing (Mode.BATCH_EDIT
). These modes can be specified when constructing a new Context object
- The main Hibernate configuration can be found at
[dspace]/config/hibernate.cfg.xml
- Hibernate initialization is triggered via Spring (beans) defined
[dspace]/config/spring/api/core-hibernate.xml
. This Spring configuration pulls in some settings from DSpace Configuration, namely all Database (db.*) settings defined there. - All DSpace Object Classes provide a DAO (Data Access Object) implementation class that extends a GenericDAO interface defined in
org.dspace.core.GenericDAO
class. The default (abstract) implementation is inorg.dspace.core.AbstractHibernateDAO
class. - The DSpace Context object (
org.dspace.core.Context
) provides access to the configuredorg.dspace.core.DBConnection
(Database Connection), which is HibernateDBConnection by default. Theorg.dspace.core.HibernateDBConnection
class provides access the the Hibernate Session interface (org.hibernate.Session) and its Transactions.- Each Hibernate Session opens a single database connection when it is created, and holds onto it until the Session is closed. A Session may consist of one or more Transactions. Sessions are NOT thread-safe (so individual objects cannot be shared between threads).
- Hibernate will intelligently cache objects in the current Hibernate Session (on object access), allowing for optimized performance.
- DSpace provides methods on the Context object to specifically remove (
Context.uncacheEntity()
) or reload (Context.reloadEntity()
) objects within Hibernate's Session cache. - DSpace also provides special Context object "modes" to optimize Hibernate performance for read-only access (
Mode.READ_ONLY
) or batch processing (Mode.BATCH_EDIT
). These modes can be specified when constructing a new Context object.
- The
org.dspace.storage.rdbms.DatabaseUtils
class manages all Flyway API calls, and executes the SQL migrations under theorg.dspace.storage.rdbms.sqlmigration
package and the Java migrations under theorg.dspace.storage.rdbms.migration
package. - Once all database migrations have run, a series of Flyway Callbacks are triggered to initialize the (empty) database with required default content. For example, callbacks exist for adding default DSpace Groups (
GroupServiceInitializer
), default Metadata & Format Registries (DatabaseRegistryUpdater
), and the default Site object (SiteServiceInitializer
). All Callbacks are under theorg.dspace.storage.rdbms
package. - While Flyway is automatically initialized and executed during startup, various Database Utilities are also available on the command line. These utilities allow you to manually trigger database upgrades or check the status of your database
- .
- The main Hibernate configuration can be found at
Most of the functionality that DSpace uses can be offered by any standard SQL database that supports transactions. However, at this time, DSpace only provides Flyway migration scripts for PostgreSQL and Oracle (and has only been tested with those database backends). Additional database backends should be possible, but would minimally require creating custom Flyway migration scripts for that database backend.
...