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