Story #3448
add (client) methods to traverse obsoletes chain
100%
Description
clients working with other people's data objects could use a convenient way to know if they have the latest version of a file - for example, corrected data instead of the original.
At least at the client side, it should be possible to use the obsoletes and obsoletedBy tags in the systemMetadata to get the latest version, and to get the entire obsoletes chain, ideally including the publication dates of each.
Consider an ObsoletesChain class, or a simple sortable map (TreeMap ?) to hold the chain. Advantages of an ObsoletesChain class would be the ability to add comparator and other "versionAsOf(Date date)" methods
ObsoletesChain.java 
- refactored to track possible NotAuthorized situations
(4.47 KB)
ObsoletesChainTest.java
(4.19 KB)
D1Client.java
- refactored to insert possible NotAuthorized situations
(13.3 KB)
Subtasks
Related issues
History
#1 Updated by Rob Nahf over 11 years ago
- % Done changed from 0 to 80
- Status changed from New to In Progress
designed and built ObsoletesChain data object to hold the obsoletes chain path traversal.
designed and built the D1Client.getObsoletesChain method
#2 Updated by Ben Leinfelder about 11 years ago
I'd argue for adding a server-side method for retrieving this information. We've found that long revision chains take a long time to traverse in Morpho because we have to recursively fetch the SystemMetadata for each revision.
#3 Updated by Rob Nahf about 11 years ago
- Target version changed from 2013.2-Block.1.1 to 2013.10-Block.2.1
- Due date changed from 2013-01-31 to 2013-03-16
#4 Updated by Rob Nahf about 11 years ago
That's a good idea. The client-side implementation can work as a stop-gap solution, until the infrastructure is built-out. There is already demand in the R-Client for getting to latest packages. (#3639).
Another optimization for the client-side implementation is to lazy-load the obsoletes chain based on the method called from it - if someone wants only the latest version of something, avoid fetching predecessors until needed, etc.
#5 Updated by Rob Nahf almost 11 years ago
- Target version changed from 2013.10-Block.2.1 to 2013.20-Block.3.2
- Due date changed from 2013-03-16 to 2013-05-25
#6 Updated by Rob Nahf almost 11 years ago
- Due date changed from 2013-05-25 to 2013-06-08
- Target version changed from 2013.20-Block.3.2 to 2013.22-Block.3.3
#7 Updated by Rob Nahf over 10 years ago
- Target version changed from 2013.22-Block.3.3 to 2013.30-Block.4.3
- Due date changed from 2013-06-08 to 2013-08-10
#8 Updated by Rob Nahf over 10 years ago
- File ObsoletesChainTest.java added
- File ObsoletesChain.java added
- File D1Client.java added
Need to finish this implementation in trunk, but currently it's not ready - some of the ObsoletesChain methods (like getLatestVersion()) need to be made aware of NotAuthorized situations that block getting to the end of a chain. parking the code in the attached files.
#9 Updated by Rob Nahf over 10 years ago
client side implementation falls short because of potential access-policy differences, so users aren't always able to navigate the entire chain. I suggest leaving this out of libclient_java, in favor of a server-side implementation.
#10 Updated by Rob Nahf over 10 years ago
- Start date deleted (
2013-01-31) - Target version deleted (
2013.30-Block.4.3) - Due date deleted (
2013-08-10)
move to backlogs until server side vs. client side approach can be decided.
#11 Updated by Rob Nahf over 9 years ago
- Status changed from In Progress to Closed
