You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@oodt.apache.org by "Chris A. Mattmann (JIRA)" <ji...@apache.org> on 2010/12/08 07:01:46 UTC

[jira] Commented: (OODT-72) Unable to set Metadata based off Product Versioning during Product ingestion

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

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

I fundamentally disagree with this approach. Metadata passed in to Versioners *is intended* to be immutable.

That's been the architecture as documented since 2005 and there is little reason to change it. Now onto addressing your specific points:

bq. This prevents Metadata elements such as FileLocation from being set based off Product References since metadata is added to catalog pre-versioning

No it doesn't. The Versioner can be called ahead of time to compute the file reference(s) and then flowed through either on client side metadata or server side.

bq.    * 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.

What you call a work-around I call the intended behavior. Versioners are intended to get an un-modifiable metadata object. IOW, they shouldn't assume that any changes they make to the met object will have *any* chance of being persisted. Period. There was a lot of thinking in this. Here's a counter-example:

- I create a Versioner to generate a Metadata field that I don't intend to be persisted, but that I intend to use by sub-classing the MetadataBasedFileVersioner. This Versioner has a filePathSpec:

{code}
/[ProdDate]/foo/bar/Filename
{code}

where the [ProdDate] met field is the dynamic met field that I intend to compute in the versioner (but that I don't intend to be persisted). 

On the one hand you could say this is dealt with by smart product type policy management where we simply don't include ProdDate as a metadata element that we intend to persist, but I'll argue that the met element ProdDate should *not* even be present in the metadata that's sent to a Catalog to be persisted.

bq. I purpose that Versioning take place before MetExtractors run.

I disagree, -1.

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