oodt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Foster (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OODT-147) Completely refactor TypeHandling code
Date Tue, 22 Feb 2011 20:08:38 GMT

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

Brian Foster commented on OODT-147:

Not to start a he said you said, but you specifically total me that ElementId is computer
ID and ElementName is human readable ID . . . there is code in the filemgr which relies on
such a concept . . . for example in DataSourceCatalog assumes ElementName is unique:

    public Metadata getReducedMetadata(Product product, List<String> elems) throws CatalogException
       elementIds += " OR element_id = '" + this.validationLayer.getElementByName(elems.get(i)).getElementId()
+ "'";

either way . . . even if you think i am misquoting you . . . i believe we should create an
issue against the filemgr which adds the above method to ValidationLayer and ensures ElementName
everywhere is treated as if it is not unique . . . the reason i'm being persistant here is
because this particular issue is one of the primary reasons i had to branched the filemgr
in wengine for PEATE . . . so i could add such methods to the ValidationLayer.

> Completely refactor TypeHandling code 
> --------------------------------------
>                 Key: OODT-147
>                 URL: https://issues.apache.org/jira/browse/OODT-147
>             Project: OODT
>          Issue Type: Improvement
>          Components: file manager
>    Affects Versions: 0.1-incubating, 0.2
>         Environment: indep. of env.
>            Reporter: Chris A. Mattmann
>            Assignee: Chris A. Mattmann
>            Priority: Critical
>              Labels: file, handling, manager, oodt, type
>             Fix For: 0.3
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to
strongly type Metadata elements within CAS file manager. IOW, it was originally conceived
to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly
is a {noformat}Date{noformat} element. 
> Type handling was supposed to take care of this. As it stands, there are a number of
fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored
for the general audience and does little to inform a user of what Type handling is supposed
to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they
really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare
the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default
> # Adds a bunch more documentation.
> # Adds unit tests.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message