[
https://issues.apache.org/jira/browse/OODT-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13558409#comment-13558409
]
Brian Foster edited comment on OODT-551 at 1/20/13 10:40 PM:
-------------------------------------------------------------
I think this is a huge assumption change in the infrastructure... a lot of
javadoc and unit-testing would have to be done for Metadata class, FM Catalog
interface/classes, and anywhere else where this assumption may affect... are we
even sure that Metadata does for sure return in add order in all cases?... i'm
pretty sure there are cases in which this is not true... for example:
{code}
Metadata m = new Metadata();
m.addMetadata("/Catalog/Test/Name", "TestCatalog");
m.addMetadata("/Catalog/Test", "TestCatalog.java");
m.getAllKeys(); // Pretty sure this will return:
/Catalog/Test,/Catalog/Test/Name
{code}
I'd much rather see a wrapper layer around Metadata:
{code}
public class OrderedMetadata {
public static final String ORDERING_KEY = "OrderedListOfKeys";
private Metadata metadata;
public OrderedMetadata(Metadata metadata) {
this.metadata = metadata;
}
public Metadata getMetadata() {
return metadata;
}
public void addMetadata(String key, List<String> values) {
metadata.addMetadata(key, values);
metadata.addMetadata(ORDERING_KEY, key);
}
...
// Similar for other methods.
...
public List<String> getAllMetadata(String key) {
return metadata.getAllMetadata(key);
}
public List<String> getAllKeys() {
return metadata.getAllMetadata(OrderedMetadata.ORDERING_KEY);
}
}
{code}
Then when you load the Metadata back from the Catalog you can just do the
following:
{code}
Metadata m = // Load Metadata.
OrderedMetadata orderedMetadata = new OrderedMetadata(m);
for (String key : orderedMetadata.getAllKeys()) {
List<String> values = orderedMetadata.getAllMetadata(key);
// Do something with current key/values.
}
{code}
was (Author: bfoster):
I think this is a huge assumption change in the infrastructure... a lot of
javadocing would have to be done in Metadata class, FM Catalog interface, and
anywhere else where this assumption may affect... are we even sure that
Metadata does for sure return in add order in all cases?... i'm pretty sure
there are cases in which this is not true... for example:
{code}
Metadata m = new Metadata();
m.addMetadata("/Catalog/Test/Name", "TestCatalog");
m.addMetadata("/Catalog/Test", "TestCatalog.java");
m.getAllKeys(); // Pretty sure this will return:
/Catalog/Test,/Catalog/Test/Name
{code}
I'd much rather see a wrapper layer around Metadata:
{code}
public class OrderedMetadata {
public static final String ORDERING_KEY = "OrderedListOfKeys";
private Metadata metadata;
public OrderedMetadata(Metadata metadata) {
this.metadata = metadata;
}
public Metadata getMetadata() {
return metadata;
}
public void addMetadata(String key, List<String> values) {
metadata.addMetadata(key, values);
metadata.addMetadata(ORDERING_KEY, key);
}
...
// Similar for other methods.
...
public List<String> getAllMetadata(String key) {
return metadata.getAllMetadata(key);
}
public List<String> getAllKeys() {
return metadata.getAllMetadata(OrderedMetadata.ORDERING_KEY);
}
}
{code}
Then when you load the Metadata back from the Catalog you can just do the
following:
{code}
Metadata m = // Load Metadata.
OrderedMetadata orderedMetadata = new OrderedMetadata(m);
for (String key : orderedMetadata.getAllKeys()) {
List<String> values = orderedMetadata.getAllMetadata(key);
// Do something with current key/values.
}
{code}
> 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