-
Notifications
You must be signed in to change notification settings - Fork 10
Conversation
M3ssman
commented
Oct 25, 2019
- fix changeMetadata
- ignore local bin-Folder
@@ -1,2 +1,3 @@ | |||
/build | |||
/dist | |||
/bin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ant and ant tools are not creating directory called bin
. Maybe your build environment must be adjusted or add /bin
to your global git ignore list. IMHO: There is no need to add more directories to the ignore list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, you're right, it has nothing to do with Ant. Eclipse IDE did this, according to the Eclipse-configuration that is already included in the Repository Branch 2.x at ugh/.project
@@ -1742,8 +1742,8 @@ public boolean changeMetadata(Metadata theOldMd, Metadata theNewMd) { | |||
oldName = oldMdt.getName(); | |||
newName = newMdt.getName(); | |||
|
|||
if (oldName.equals(newName)) { | |||
// Different metadata types. | |||
if (! oldName.equals(newName)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are you try to fix? If the meta data are the same (according to the name of the meta data) there is no change needed. Ignoring comments is sometimes a good choice as they are in most cases not updated if the code is changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use Case: Exchange metadata values, i.e. put a different value for Metadatatype "4000 (Hauptitel)" (PICA-Data).
The Variables state, IMHO, that if the names of the Metadatatypes (not the values) are equal, there is nothing to exchange. The Method returns immediately, therefore it is not possible Update the Value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change seems right to me. Also, considering the method description in Javadoc above: The method must be used to swap the same type of metadata, so return
ing in case of the same type has been a mistake.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In which context are you using this method? So far as I could discover this method is not used direct or indirect by Kitodo.Production so I assume that you write your own application which is using Kitodo.UGH?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@henning-gerhardt
No, you can't yet, you're right.
It is an enhancement to existing Metadaten-Backing-Bean in Kitodo.Production 2.x to handle possible Updates of Metadata and alike. It's required by our staff when they need to do metadata corrections afterwards, i.e. at structure or segmentation stages.
I'm not sure if this is of interest to the community, since it was obviously not used in other scopes until now and it is only for users that spent a lot of resources for very precise structures. Furthermore, the old Metadaten-class is already some complex piece of code, but it's got even more complicated by now.
Meanwhile, it is possible to achieve this if you iterate all Metadata of a given DocStruct, pic the one to replace (in case there is only one, of course), remove it and finally add the updated one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not understand me wrong. I would to see an update feature in Kitodo.Production for existing meta and structure data as this can solve a lot of issues of the daily work. But I think on the other side that this kind of improvement should be done in Kitodo.Production 3.x as this version has the current and future focus in development. I don't think that Kitodo.Production 2.x receive a lot of updates so additional work should be decided by how important is this feature and can it be done in 3.x on an easier way or can it be re-implemented in 3.x in a same or cleaner way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@henning-gerhardt
I totally agree, Version 3 has to have focus. Personally, I do not like to resurrect legacy ghosts of version 2. I'm in to provide a proper platform for our library staff, based on what already has been done.
To provide some explanations: Back in time, when ULB Sachsen-Anhalt decided to move to Kitodo.Production, there was no Version 3. Therefore, many parts of the digitalization-workflow-in-spe came to life since 2017 are centered around Version 2.x. For the next 1-2 years I have to support this old stuff. There's no green field left on our side.