Backport of DSpace 2 Storage Services API for DSpace 1.x
Student: Andrius Blažinskas
Mentor: Mark Diggory
Abstract
DSpace 2.0 storage mechanism provides convenient way to store DSpace contents in various storage solutions. It is based on set of interfaces for which various implementations are possible and some beta releases already exist (Jackrabbit, Fedora, etc). DSpace 2.0 is in its early stages of development and DSpace 1.x releases yet can not take advantage of this new mechanism. To fix this, it is necessary to port DSpace 2.0 storage interfaces to 1.x. I propose implementing this backport. – Andrius Blažinskas
Relevant modules
Module name |
Description/Comments |
Source code |
---|---|---|
dspace-api |
DSpace API |
|
dspace-xmlui |
XMLUI (Manakin) |
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-xmlui![]() |
storage-api |
Yet non existant module. Will constitute of DSpace 2 storage interfaces. Will be referenced from dspace-api (dspace-xmlui?). Depending on backporting strategy used, this module may also include additional storage related classes. |
Currently parts of it (interfaces) located at http://scm.dspace.org/svn/repo/dspace2/core/trunk/api/src/main/java/org/dspace/services![]() (/mixins) |
storage-default |
Yet non existant module. Module will implement storage-api interfaces. Will probably contain classes from dspace-api, such as: DatabaseManager, TableRow, TableRowIterator, BitstreamStorageManager and other code. |
Some of the affected classes located at http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api/src/main/java/org/dspace/storage![]() |
Development plan
Initial plan. Will change.
- Analysis of dspace-services module (http://scm.dspace.org/svn/repo/modules/dspace-services/trunk
)
- Analysis of current situation in dspace-api (identifying storage related Java classes and references to them)
- Iterated code refactoring and development:
- Identify code fragments which potentialy constitute particular storage-service method in dspace-api
- Move these code fragments to storage-default module under particular storage-service interface method name
- Retain the relation of dspace-api with storage-default from newly created method perspective through use of storage-api interfaces and perform all neccesary tasks to ensure separated code interoperability
- Thorough testing of separation, whether the system work the same way it worked before backport (unit tests could be helpfull here)
- dspace-xmlui relation to storage-service interfaces
- ...
List of storage-api classes/methods
Classes and methods to be ported. List will evolve.
Interface/Class name |
Method name |
Description/Comments |
---|---|---|
boolean exists(String entityId) |
– |
|
|
StorageEntity getEntity(String entityId) |
– |
|
List<StorageEntity> getEntities(String location) |
– |
|
List<String> getEntityLocations(String entityId) |
– |
String createEntity(StorageEntity storageEntity) |
– |
|
|
boolean deleteEntity(String entityId) |
– |
|
void saveMetaProperties(String entityId, StorageProperty... properties) |
– |
|
void removeMetaProperties(String entityId, String... names) |
– |
|
boolean addEntityLocation(String entityId, String location) |
– |
|
void removeEntityLocation(String entityId, String location) |
– |
List<StorageVersion> getVersions(String reference) |
– |
|
|
StorageEntity getVersion(String reference, String versionName) |
– |
String copyEntity(String reference, String path, boolean recursive, String newName) |
– |
|
StorageEntity restoreVersion(String reference, String versionName, String label) |
– |
|
|
void setVersionLabel(String reference, String versionName, String label) |
– |
– |
Is this one needed? |
|
– |
Is this one needed? |
|
Any others? |
|
|
References
GSOC 2010 proposal: Backport of DSpace 2 Storage Services API for DSpace 1.x, http://ab.labt.lt/gsoc/2010/dspace/proposal1.html