Mailing-List: contact commits-help@oodt.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@oodt.apache.org
Message-ID: <30153920.11121291791420931.JavaMail.jira@thor>
Date: Wed, 8 Dec 2010 01:57:00 -0500 (EST)
From: "Chris A. Mattmann (JIRA)" <jira@apache.org>
To: commits@oodt.apache.org
Subject: [jira] Commented: (OODT-72) Unable to set Metadata based off
 Product Versioning during Product ingestion
In-Reply-To: <29057056.1751291760580668.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.