[
https://issues.apache.org/jira/browse/OODT-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558434#comment-13558434
]
Luca Cinquini commented on OODT-551:
------------------------------------
Hey guys, excellent discussion, and thanks for the historical background Chris!
Let me chime in...
First of all, we are talking about ordering of the values for a given Metadata
key, not ordering of the keys... In other words:
m.addMetadata("key","value1");
m.addMetadata("key","value2");
List<String> values = m.getAllValues("key");
--> should return the list "value1", "value2" in the same order they were
inserted.
I don't think you can build a wrapper layer to implement this functionality: if
the order of the values is lost in the back-end storage, nothing can be done to
re-order the values in the API layer.
As Chris was mentioning, some (all?) back-end FM implementation already respect
the order of the values - such is Lucene. The proposal here is to simply
implement the same functionality in another FM back-end, i.e. the
DataSourceCatalog. This does NOT mean that the semantics of the Metadata object
needs to change: a client could still use a FM with MySQL backend and expect
nothing about the ordering of the values. But, if a client application was
indeed interested in preserving the ordering of the values, they could choose
to use an FM implementation that indeed guarantees that order. Such
implementation would state this guarantee in the Javadoc, and we could
implement it either as standard behavior, or as a property-based behavior as
Chris suggested.
Bottom line: if a client doesn't expect values returned in order, it won't care
or notice if the values are indeed ordered.
> DataSourceCatalog implementation does not preserve order of metadata values
> ---------------------------------------------------------------------------
>
> Key: OODT-551
> URL: https://issues.apache.org/jira/browse/OODT-551
> Project: OODT
> Issue Type: Bug
> Components: file manager
> Affects Versions: 0.5
> Reporter: Luca Cinquini
> Assignee: Luca Cinquini
> Fix For: 0.6
>
> Attachments: OODT-551.luca.patch.txt
>
>
> The table that stores the metadata (key, value) pairs for the File Manager
> database-based implementation has no primary key - as a consequence, values
> are not guaranteed to be returned in any order, which is a problem for
> applications that rely on the order of the values (for example, among
> different metadata keys).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
