[OODT-199] CoreMetExtractor chokes on Hierarchical Products

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 0.1-incubating, 0.2
• Fix Version/s: 0.3
• Component/s: file manager
• Labels: core directory extractor met product
• Assignee: Chris A. Mattmann
• Reporter: Chris A. Mattmann
• Created: 17/Jun/11 22:53
• Updated: 18/Jun/11 05:19
• Resolved: 18/Jun/11 05:19

Description

While performing some work for a demo recently that involved Product.STRUCTURE_HIERARCHICAL (or Directory-based) products, I found out that the CoreMetExtractor chokes and causes ingestion to fail.

This is due to the following function, which incorrectly assumes that DataStoreReferences exist and that Versioning has already occured:

    protected String getRootRefPath(List<Reference> refs,
            String productTypeRepoPath) throws URISyntaxException {
        // product type repo: file://foo/path
        // ref data store path: file:/foo/path/myproddir/dir1/file

        String productTypeAbsPath = new File(new URI(productTypeRepoPath))
                .getAbsolutePath();
        String anyRefDataStorePath = new File(new URI(refs.get(0)
                .getDataStoreReference())).getAbsolutePath();
        String lastDirPath = anyRefDataStorePath;

        while (!anyRefDataStorePath.equals(productTypeAbsPath)) {
            lastDirPath = anyRefDataStorePath;
            // chop off last dir
            anyRefDataStorePath = anyRefDataStorePath.substring(0,
                    anyRefDataStorePath.lastIndexOf("/"));
        }

        return lastDirPath;

    }

A local workaround that appears to be succeeding is assuming that the first Reference even in a Hierarchical product is the initial ref. This works fine for the LuceneCatalog which preserves the ordering of References as they are inserted, but not sure it would work for the DataSourceCatalog which I'm not sure exactly preserves the ordering of References.

I'll look into a generalized solution. And I'll add a unit test.