Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#634 closed enhancement (fixed)

BibUpload: only add new BibDoc version if changed

Reported by: jlavik Owned by: skaplun
Priority: major Milestone:
Component: BibUpload Version:
Keywords: Cc:

Description

When uploading FFT fields in correct mode for records already having the same files attached (same docname), will cause another version to be added. However, sometimes the files being added is identical to the existing attached file. Intended behavior here would be that files with same names having identical md5 hash would not create a new version, avoiding duplicate versions.

Such functionality could be added in the BibDoc class, function add_file_new_version().

Attachments (1)

0001-BibUpload-check-for-already-existing-fulltext.patch (14.2 KB) - added by skaplun 3 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 3 years ago by skaplun

Hi Jay,

but are you actually putting a path to a fulltext in FFT $a when using the correct mode? Are you doing this even when you simply wants to modify some other information (e.g. restriction, description...)? the $a field is not mandatory, so in general if you don't want to create a new revision you can simply avoid putting a $a.

On the other hand, if in your use-case you can't easily understand if a file has been modified or not, then this feature could be a nice addition (but might hide those cases when uploading twice via FFT the same documents is actually a bug).

Version 0, edited 3 years ago by skaplun (next)

comment:2 Changed 3 years ago by jlavik

Hi Sam,

Yeah, this ticket was created from the point of view of OAI harvesting, where the FFT generation process does not necessarily know if the existing file is the same or not, and $a is always included. Sorry for not being entirely clear here.

In the case of a bug, I guess this can be at least a way of avoiding repercussions should there one. Detection of such a bug, however, would as you say not be so obvious. But we could add some warning messages, telling that existing version is identical and was not updated.

comment:3 Changed 3 years ago by skaplun

  • Owner set to skaplun
  • Status changed from new to assigned

Hi Jan,

Indeed, to print a warning would be an optimal solution.

comment:4 Changed 3 years ago by skaplun

  • Milestone set to v1.0
  • Status changed from assigned to in_merge

Done! I sent you and Tibor a patch to merge this feature :-)

comment:5 follow-up: Changed 3 years ago by simko

  • Status changed from in_merge to assigned

The patch seems to break the following unit and regression tests:

FAIL: plotextractor - get defaults
FAIL: bibupload - detailed FFT insert
FAIL: bibupload - simple FFT insert with icon
FAIL: bibupload - simple FFT insert with restriction

comment:6 in reply to: ↑ 5 ; follow-up: Changed 3 years ago by simko

Replying to simko:

FAIL: plotextractor - get defaults

This one is actually independent, see build:246.

comment:7 in reply to: ↑ 6 Changed 3 years ago by simko

Replying to simko:

This one is actually independent, see build:246.

... and it is due to [4a220ae02c4a37e9d904a02d824a83c477c6fef4].
I've created an independent ticket:637 for this one.

comment:8 Changed 3 years ago by skaplun

  • Status changed from assigned to in_merge

Hi Tibor,

here's the revised patch where I updated the regression tests (which naively were using all the time the same physical files).

(I also sent you the same patch via git send-email but I am not sure it worked from home)

comment:9 Changed 3 years ago by Samuele Kaplun <samuele.kaplun@…>

  • Resolution set to fixed
  • Status changed from in_merge to closed

In [f8a1ec18882f0f438b08fd43e93c7ee9b46ef697]:

BibUpload: check for already existing fulltext

  • When performing an FFT append or revise of fulltext, if the file being added happen to be already attached to the record (for the corresponding bibdoc), simply ignore the file (while printing a warning) and keep on merging corresponding comments and descriptions. (closes #634)

comment:10 Changed 2 years ago by simko

  • Milestone v1.0 deleted

Milestone v1.0 deleted

Note: See TracTickets for help on using tickets.