On 31/10/2013 5:46 μμ, Samuele Kaplun wrote:
During a migration phase to a system running the latest 1.1.x and using
the usual recipe [copy bibrec IDs along with creation/modification times
between systems and then 'replace'(insert) records with bibupload -n -r
xxx.xml], I get the following error:
-ERROR: Invalid Revision - 'INVALID REVISION : 20130930185930 for
Record 250733 not in Archive.'
This is kind of strange as the revision should always ends with a ".0"...
Hmmm... I verified that the xml contains a 'proper' 005 (that ends with
a ".0"). Also, the code in bibupload_revisionverifier.py seems correct.
Maybe it's just a display issue? If so, this does the trick:
--- /opt/invenio/lib/python/invenio/bibupload_revisionverifier.py
2013-10-21 08:01:29.463652013 +0300
+++ /opt/invenio/lib/python/invenio/bibupload_revisionverifier.py.test
2013-11-01 08:59:28.510219744 +0200
@@ -361,7 +361,7 @@
r_date = upload_rev.split('.')[0]
if r_date not in [k[1] for k in get_record_revisions(self.rec_id)]:
- raise InvenioBibUploadInvalidRevisionError(self.rec_id, r_date)
+ raise InvenioBibUploadInvalidRevisionError(self.rec_id,
upload_rev)
else:
raise InvenioBibUploadMissing005Error(self.rec_id)
This check obviously relates to tag 005 and did not exist in previous
releases. Is there a flag to override this behavior and have the records
replaced (inserted) anyway? (Or should i put all 005s in some table
prior to import?)
Nope. And actually it's strange that you have a revision that does not exist
in the history of records...
Well, In this particular case, its normal. See, that I'm only 'faking'
bibrecs by just manually creating entries in bibrec. Nothing more. And
the idea is to upload records from another invenio instance, so that
timestamps and bibrec IDs are the same across systems (I didn't bother
messing around with hstRECORD, as I thought bibupload would update it
during import).
Indeed dropping the 005 would do the trick...
Indeed. Tried it and it works.
But if you can ticketize this with more details we can work on a real solution
:-)
I would be happy to, but it might be nothing wrong here...
Unless of course we're talking about a feature request for a new flag in
bibupload (ie "--skip-005") to properly handle (skip) 005s in input
records... If you're in to this, you could implement a whole set of
'skips' (like --skip-001) or -even better- a more generic
"--skip-tag=XXX,YYY". Sounds interesting?
Cheers,
Theodoros
