Bugs item #2082623, was opened at 2008-08-29 17:41
Message generated for change (Comment added) made by bollini
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=119984&aid=2082623&group_id=19984
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XMLUI (Manakin)
Group: 1.5
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Keith Gilbertson (kgilbertson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Metadata values saved in incorrect order, xmlui
Initial Comment:
The XMLUI looks to be saving metadata values in the wrong order.
An example is with multiple contributor.author fields. When entering these
authors in this order during item submission:
Santhanam, Lakshmi
Yoo, Younghwan
Agrawal, Dharma
Nandiraju, Nagesh
the authors are stored in the metadata value table in seemingly reverse order:
metadata_field_id | text_value | place
-------------------+-----------------------------
3 | Nandiraju, Nagesh | 1
3 | Agrawal, Dharma | 2
3 | Yoo, Younghwan | 3
3 | Santhanam, Lakshmi | 4
This is causing the authors to display in the reverse order of which they were
entered.
Additionally, the metadata ordering in the table is inadvertently changed when
the metadata is later edited using the XMLUI. As an example, a dc.subject
value was added to the same record. The contributor.author fields were not
changed by the tester. After the dc.subject value was added, the authors
appeared in this order in the database:
metadata_field_id | text_value | place
---------------- --+---------------------------
3 | Santhanam, Lakshmi | 1
3 | Yoo, Younghwan | 2
3 | Agrawal, Dharma | 3
3 | Nandiraju, Nagesh | 4
In the above case the authors are again in the order of original entry, but in
duplicate tests the order in which they appeared after the metadata was edited
appeared random.
Based on user reports, this is happening with other repeatable metadata fields
as well. The order of metadata values is important to the users because they
wish to use it to indicate primary authorship, and also to have values for
other fields (in particular, subject, and identifier.other) to display in a
sensible order.
A similar problem, at least from a user standpoint, looks to be occurring in
the 1.5.1 beta on Claudia's test system.
----------------------------------------------------------------------
>Comment By: Andrea Bollini (bollini)
Date: 2009-03-04 15:48
Message:
The bug has fixed in the duplicate bug [ 2655052 ] Authors re-ordered when
item edited
https://sourceforge.net/tracker/index.php?func=detail&aid=2655052&group_id=19984&atid=119984
----------------------------------------------------------------------
Comment By: Sands Fish (sandsfish)
Date: 2008-09-02 21:40
Message:
Logged In: YES
user_id=1667587
Originator: NO
This is particularly troublesome when it comes to dc.description fields
that contain spliced values of one original value because the value was too
large for the metadata field (i.e. a long description is split up into the
first chunk of a description, then another dc.description with (cont.)
prepended, etc. etc.) When these are reordered, the resultant display of
the description is nonsensical.
Unfortunately, not all metadata schemas provision for field ordering (in
fact, I don't know if any do) so beware that even if a fix is implemented
for this behavior in DSpace, exports of this metadata may not necessarily
retain the ordering. We are seeing this when trying to use the metadata
for alternate search/discovery/browse systems.
----------------------------------------------------------------------
Comment By: Keith Gilbertson (kgilbertson)
Date: 2008-08-29 21:41
Message:
Logged In: YES
user_id=1996121
Originator: YES
Oops, I've worded that extremely badly. What I meant is that the xmlui
looks to be putting incorrect values in the "place" column of the
metadatavalue table.
When the data displays, it is displaying in order according to the values
in the "place" column, but I think that there is a problem with the values
that are put in that column when the metadata are saved/edited.
----------------------------------------------------------------------
Comment By: Mark H. Wood (mwoodiupui)
Date: 2008-08-29 20:52
Message:
Logged In: YES
user_id=576574
Originator: NO
Probably not specific to XMLUI. An RDBMS responds to a query with a set
of rows which match it. Set elements have no intrinsic order; the DBMS is
free to return rows in whatever order is most convenient. The observed
behavior is expected.
That's not to say that the observed behavior is *desirable*, but changing
it will require extending the database schema for each field type which
should preserve order, extending the submission and editing forms in many
places to introduce the concept of ordered values, crafting controls which
enable arbitrary reordering of values, and adding sorting to all of the
places where the (now) ordered values are displayed. It won't be a simple
fix.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=119984&aid=2082623&group_id=19984
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
