oodt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OODT-72) Unable to set Metadata based off Product Versioning during Product ingestion
Date Wed, 08 Dec 2010 06:57:00 GMT

    [ https://issues.apache.org/jira/browse/OODT-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969217#action_12969217
] 

Chris A. Mattmann commented on OODT-72:
---------------------------------------

bq. aside from wrapping the versioner inside a MetExtractor there is NO way, when using the
ingestProduct method, to set FileLocation . . .

_Not_true_.  Counter-example:

{code}
public class SuperVersioner implements Versioner{
 // ...
  public void createDataStoreReferences(Product product, Metadata metadata){
             XmlRpcFileManagerClient fmClient = new XmlRpcFileManagerClient(new URL(fmUrl));
             Reference persistedRef = fmClient.getProductReferences(product).get(0);
             String finalArchiveLocation = persistedRef.getDataStoreLocation();
             // use finalArchiveLocation in versioning...
  }

}
{code}

bq. and this requires the MetExtractor to dynamically load the Versioner and create a cloned
Product object so to trick the Versioner into thinking it is filling the References for the
actual Product, so that the References can then be retrieved from this cloned Product and
then FileLocation set based off that 

Whoah. Umm, no, it really doesn't. It's not nearly that hard. Counter-example:

{code}
public class MetExtractor extends CmdLineMetExtractor{
   XmlRpcFileManagerClient fm;
  // ..
   public Metadata extrMetadata(File f){
        Metadata met = ...extractMet
        ProductType p = this.fm.getProductTypeByName(this.conf.getProductTypeName());
        Versioner v = GenericFileManagerObjectFactory.getVersionerFromClassName(p.getProductType().getVersionerClass());
        Product p = Product.blankProduct(); 
        p.getReferences().add(new Reference(...f.toURL().toExternalForm());
        v.createDataStoreReferences(p, met);
     }
}
{code}


bq. . . . then later the versioner is again dynamically loaded and re-run on the actual Product
object used for ingestion.

Sigh, again *not* true. Not in all cases.

bq.     # the Metadata object could be cloned before calling the versioner . . . that would
address your "un-modifiable metadata" conserns

Not sure how?

bq. An alternative solution might be to optionally have the filemgr fill a FileLocation like
metadata field when retrieving a Product's Metadata . . . FileLocation doesn't necessarily
need to be stored in the catalog as it typically is not queried on

FileLocation is already there in the references. If it needs to be in the metadata in its
final form, there are at least 2 ways to do it with the File Manager today *without changing
anything*. 


> Unable to set Metadata based off Product Versioning during Product ingestion
> ----------------------------------------------------------------------------
>
>                 Key: OODT-72
>                 URL: https://issues.apache.org/jira/browse/OODT-72
>             Project: OODT
>          Issue Type: Improvement
>          Components: file manager
>    Affects Versions: 0.1-incubating
>         Environment: none
>            Reporter: Brian Foster
>            Assignee: Brian Foster
>            Priority: Minor
>             Fix For: 0.2
>
>
> Ingest order:
>   - add product to catalog
>   - metextractors run
>   - add metadata to catalog
>   - versioner runs (on client or on server)
>   - add references to catalog
> This prevents Metadata elements such as FileLocation from being set based off Product
References since metadata is added to catalog pre-versioning
> - A known work-around is to run the versioner twice (once in a MetExtractor and again
when the Versioner is run in the ingest process) . . . however this is very much a work-around
and setting elements such as FileLocation is a very common functionality.
> I purpose that Versioning take place before MetExtractors run.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message