Page History
...
Code Block |
---|
/** Start versioning a new item. */ function startVersionItem() { var itemID = cocoon.request.get("itemID"); // verify we can create a new version assertVersionItem(itemID); // creates a new versioin in the submission workflow. var newItemID = new DSpace().getServiceManager()....doVersionItem(itemID); //restart editing new item as if it were part of the submission workflow. var newItem = Item.find(getDSContext(),itemID); cocoon.redirectTo(cocoon.request.getContextPath()+"/submit/"+newItem.getHandle(),true); getDSContext().complete(); item = null; cocoon.exit(); } |
Code approach in GSoC Versioning project
from In ArchiveManager (Possible methods for VersioningService)
...
the following code will create a new Version of our Item and Place it into the Submission Workflow
- Separate New Versions of an Item May be started
- Can only one new version be started, until it has been finalized?
- Should the new version of the data package, data files, and bitstreams be processed in the submission and/or reviewing workflow?
- Should information about the revision be hidden until approved?
- Should the handle of a replaced item automatically point to the latest version?
Code Block /** * Creates a Item in the database that maintains all the same * attributes and metadata as the Item it supplants with a new * revision number and a link to the given Item as the previousRevision * a new bitstream is not created * * This Item is ready to be put into the Workspace or a Workflow * * @param item The Item to create a new version of */ public static Item newVersionOfItem(Context context, Item originalItem) { try { ArchiveManager am = new ArchiveManager(); ItemDAO itemDAO = ItemDAOFactory.getInstance(context); WorkspaceItemDAO wsiDAO = WorkspaceItemDAOFactory.getInstance(context); Item item = itemDAO.create(); Item head = itemDAO.getHeadRevision(originalItem.getOriginalItemID()); item.setArchived(false); item.setWithdrawn(originalItem.isWithdrawn()); // Done by ItemDAO.update ... item.setLastModified(); item.setOriginalItemID(originalItem.getOriginalItemID()); item.setRevision(head.getRevision()+1); item.setPreviousItemID(head.getID()); //System.out.println("Head: " + head.toString()); item.setOwningCollectionId(originalItem.getOwningCollection().getID()); item.setSubmitter(originalItem.getSubmitter().getID()); item.setMetadata(originalItem.getMetadata()); // Add uri as identifier.uri DC value item.clearMetadata("dc", "identifier", "uri", null); for (Bundle bundle : originalItem.getBundles()) { item.addBundle(am.dupeBundle(context, bundle)); } itemDAO.update(item); wsiDAO.create(item); return item; } catch (Exception e) { throw new RuntimeException(e); } } /** * Takes in a bundle and makes a deep copy of it. * Without duping bitstreams. * * @param bundle */ private Bundle dupeBundle (Context context, Bundle bundle) throws AuthorizeException { BundleDAO bdao = BundleDAOFactory.getInstance(context); Bundle dupe = bdao.create(); Bitstream[] bitstreams = null; int primary = bundle.getPrimaryBitstreamID(); bitstreams = bundle.getBitstreams(); for (Bitstream b : bitstreams) { dupe.addBitstream(b); if (primary == b.getID()) { dupe.setPrimaryBitstreamID(b.getID()); } } dupe.setName(bundle.getName()); return dupe; } }
Will Create a New Item and Place it into the Submission Workflow
- Separate New Versions of an Item May be started
- Can only one new version be started, until it has been finalized?
- Should the new version of the data package, data files, and bitstreams be processed in the submission and/or reviewing workflow?
- Should information about the revision be hidden until approved?
- Should the handle of a replaced item automatically point to the latest version?
Versioning of item metadata
The metadata for either a datapackage or a data file can be altered.
- Should all items receive a new version number at once?
Versioning of files
- If no files are altered, preferable reference to same bitstream without duplication
- If a new file is being uploaded, or a file is replaced by a URL, the new data file will no longer reference to the file
- Should URL's for files remain the same if the file didn't change?
Two User Stories
Simple Item Versioning Case
The first example is most basic and involves providing a means to request a new version of an Item. When request in the API
Versioning of item metadata
- Given this is logical versioning (or editioning). Both tThe metadata and bitstream contents for any Item Version in a VersionHistory can be altered.
Versioning of files
- If no files are altered, preferable reference to same bitstream without duplication
- If a new file is being uploaded, or a file is replaced by a URL, the new data file will no longer reference to the file
- Should URL's for files remain the same if the file didn't change?
Two User Stories
Simple Item Versioning Case
The first example is most basic and involves providing a means to request a new version of an Item. When request in the API
Code Block | ||
---|---|---|
| ||
public interface VersioningService | ||
Code Block | ||
| ||
public interface VersioningService
{
public Version<T> getPropertyAsType(T original);
} |
...
In the simplest Usecase, a new Version of an item will be created, it will have the following characteristics:
New version relationships
Field | Value (Relationship) |
---|---|
dc.identifer.uri | <new-handle> |
dc.relation.isVersionOf | <original-handle> |
dc.relation.replaces | <previous item> (identifier of previous version) |
...
Both DOI and Handle usecases require that a persistent id be created that represents the latest version of the Item. Ideally, this would be both calculated and serialized int he metadata in a manner to reduce having to update previous items when new items are added. this means that a VersionHistory identifier may not actually be "unique" in our metadata, but that calculating which version to return would always return the most recent.
For Item doi:10.651/dryad.154
|
|
|
|
---|---|---|---|
dc.identifier | doi:10.651/dryad.154.2 | For the next version |
|
dc.relation.isVersionOf | doi:10.651/dryad.154 | should be present in all Items in VersionHistory, will be used to look up the entire version history |
|
dc.relation.replaces | doi:10.651/dryad.154.1 | Will be used to trace the Revision Tree. |
|
|
|
|
|
|
|
|
|
dc.identifier | doi:10.651/dryad.154.1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For Item doi:10.651/dryad.154
...