#1753 closed defect (fixed)
TableExporter generate UPDATE logs in "Change History"
Reported by: | Nicklas Nordborg | Owned by: | everyone |
---|---|---|---|
Priority: | minor | Milestone: | BASE 3.2.3 |
Component: | core | Version: | |
Keywords: | Cc: |
Description
Checking the 'Change history' on the 'lorry' server lists the 'Table exporter' as a source for an UPDATE action for several items (for example, '1106248.1.his'). There is no text in the 'Change info' column so I am not sure if something has really been updated or not. I am not sure how to reproduce this issue but it needs to be investigated.
Doing some manual SQL on the database finds a total of 83 different timepoints where this has happened, each one "updating" from 1 to well over a thousand items.
Change History (5)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
(In [6272]) References #1753: TableExporter generate UPDATE logs in "Change History"
Try to set AnnotationSet.itemId
already at creation time which should lower the number of items without a value in that column.
comment:3 by , 12 years ago
(In [6273]) Fixes #1753: TableExporter? generate UPDATE logs in "Change History"
Added check in the logging implementation so that changes to "itemId" are ignored.
comment:4 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:5 by , 12 years ago
(In [6276]) References #1753: TableExporter generate UPDATE logs in "Change History"
Next BASE version is 3.2.3
After some investigations it was found that the source of the log entry is the
AnnotationSetLogger
. The reason that a log entry is created is that theitem_id
value is modified.To begin with
AnnotationSet
items are created with a NULL value in theitem_id
column (since it is not be known which id the item will get when creating new items and annotations at the same time). Then, whenever the BASE core get the desired information theitem_id
column is automatically populated in the background and saved to the database. It just happened that the "Table exporter" triggered it in this case.The reason that there is no text in the "Change info" column is due to a bug in
EntityDetails.getModifiedProperties()
method. This method is expected to ignore changes to collections and theversion
column, but the check for this is not correct. The reason is that several numerical column types in Hibernate are subclasses of theVersionType
class, so this means that changes to numerical columns are not logged correctly (but this should be another ticket).