VegBank

I'd imagine this working on the VegBank side as a new table called "issuedAccessionCode"

A client would be able to request as many accessionCodes as they need for their application in a request (one request per table) like this:

http://vegbank.org/requestxml/{table}/{numberOfAccCodesNeeded}
--this would forward to the appropriate servlet/jsp page that would process the request, adding {numberOfAccCodesNeeded} records to the issuedAccessionCode table with the tableName field in that table set to {table} from the request.

then, VegBranch or whatever client would take those codes, write them as GUID accessionCode identifiers for the new data.

When the data are exported to VegBank-data-xml and uploaded to VegBank, the XML-Loader would use this logic with incoming accCodes:

1) is this accessionCode in the VegBank database already
1a) if so, reference that entitiy
1b) if not do #2
2) is this accessionCode in the stack of accCodes listed in "issuedAccessionCode"?
2a) if so, then use that accessionCode in the database, and delete it from the "issuedAccessionCode" stack.
2b) if not, then ignore the accessionCode and write a new VegBank accessionCode.

we might format the requested code differently. Currently we have "VB.Tbl.PK#.Confirm." Requested might be "VBReq.Tbl.PK#.Confirm" or something like that. This would ensure uniqueness between the two sets of codes.

Confirm for newly issues confirmation codes should be some random string, as we won't know "diddley" about the actual element until well after the AccessionCode is generated. Still useful in making sure typos didn't occur. If someone was only requesting one code, we could potentially issue a confirmation code. (I'm unsure about the wisdom even in that case...) Otherwise, it would be problematic as they'd be trying to match confirmation codes with their new entities... leads to possible mismatching.

this XML was successfully imported:
http://www.unc.edu/~mikelee/Misc/testImportXML2.xml

database.accession.key.preassign=VBAldoPre
is also added to build.properties in the /vegbank/ directory.

http://aldo.nceas.ucsb.edu/vegbank/views/getNewRequestID.jsp?tablename=observation&recordcount=4

creates 4 new observation accession codes as XML that can be downloaded by a client (VegBranch). VegBranch has successfully downloaded such accessionCodes to uniquely identify observations.

getPKFromAccessionCode() needs to be modified to look for the accessionCode in the "lookup table" if it isn't already found. It should only look for accessionCodes that are of the right prefix (set in .props file) to save time to avoid looking up VegBranch accessionCodes. If it finds the accessionCode there, it should somehow flag that code as acceptable, and this would stop removeAccessionCode() from doing what it does. I suppose that we don't have to enforce removal of that accessionCode then from the pre-request list, but it would be nice to. It could be done later, I think, or perhaps just flagged as removed (update seems safer than delete).

If it doesn't find the accessionCode there, then nothing different happens.

Works now. New data that are loaded into VegBank accept accessionCodes that are in the dba_preassignAccCode table. This means less work as we don't have to deal with multiple sets of accessionCodes (incoming codes and our unique codes).

Original Bugzilla ID was 2442