Note: As of August 2009, the code this refers to is located at http://scm.dspace.org/trac/dspace/browser/dspace/branches/dspace-dao-prototype, but is unlikely to be released from there. A version called "1.6" that is based on the /dspace_1_5_x branch will be released. – Stuart Lewis, August 20, 2009
Note: As of April 2009, the code this refers to is located at the repository /trunk, but is unlikely to be released from there. A version called "1.6" that is based on the /dspace_1_5_x branch will be released, and may incorporate some of these changes. – Bradley McLean, April 13, 2009
*Author: James Rutherford
*Version: 2007-11-05
- See also: DAO Prototype, PersistentIdentifiers (both slightly out of date), Google+Summer+of+Code+2007 Versioning
NOTE: this page is a work in progress.
This page exists to document the new (as of Q4 2007) features introduced into DSpace post 1.5. This is intended for developers, mostly as a guide for how to migrate from coding against the 'old' API to working with the new features as they exist in DSpace+1.6+. The three main features that I will outline in this page are DAOs, identifiers, and versioning. Note that these aren't the only new things that will appear in 1.6.
TODO
I'll start by outlining what still needs to be fixed / refactored / tested more thoroughly, so you have an idea of what's missing before you start.
Consistency
There are several areas that need to be aligned to make the application more consistent. A lot of work has already been done here, but there is much left to do:
- logging
- level, detail, etc
- Events
- authorization
- use of
org.dspace.core.Context
cache
API
The API has already changed considerably (see below), but there are still a few things that I need to straighten out:
- use of
org.dspace.content.uri.ObjectIdentifier
instead ofint
orString
"identifiers". - pre- and post-hooks for all DAO operations (or at least the basic CRUD).
- resolve API conflicts such as
item.getBundles()
vs.bundleDAO.getBundles(item)
(the former asks the in-memoryItem
, the latter queries the data store – results will not necessarily be the same).
URLs
To ease migration away from the dependency on Handles, the 'new' URL form is basically the same as it was (site_url/resource/identifier/extras
). While this basically, works, there are bugs waiting to creep in (mostly relating to identifiers that contain unescaped slashes), and it may be worth moving towards a more parameterized URL scheme.
Constructors
Classes that have corresponding DAOs (Item
etc) typically had package-private constructors which, among other things, prevented them from being subclassed (which was irritating); these constructors (usually) took a TableRow
and a Context
. In order to maintain some degree of consistency with the old API, such constructors now take an int
ID, and a Context
. It is important to note that these constructors are only really for use by the DAOs – all creates and retrieves go via DAOs so there should never be a need to directly instantiate one of these objects directly.
In the near future, I will probably remove these constructors and replace them with constructors that take no arguments (the Context
is only required to support deprecated methods anyway) to avoid confusion.
Things that are broken
org.dspace.app.itemimport.ItemImport
is broken (because of the previous dependency on Handles as identifiers). I'm in the process of fixing this, but for now it just doesn't work.
DAOs
Example: ItemDAO
Sample code to follow.
org.dspace.content.proxy
This section will provide an overview of the new ItemProxy
class.
Identifiers
It used to be the case that DSpace used a mix of int
and String
representations of Handles to identify objects. As much as possible, I've swapped all of these out in favour of using the new ObjectIdentifier
class. The idea behind this identifier was driven by one of the reasons for using DAOs: n