[
https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998041#comment-12998041
]
Chris A. Mattmann edited comment on OODT-147 at 2/22/11 9:12 PM:
-----------------------------------------------------------------
Hi Brian:
bq. Not to start a he said you said, but you specifically total me that
ElementId is computer ID and ElementName is human readable ID
And how specifically is what I'm saying in violation of that statement (that I
did make, to leverage as an analogy to illustrate the concept)? The element ID
*is* the only part of the Element that I've said *must* be unique.
bq. there is code in the filemgr which relies on such a concept . . . for
example in DataSourceCatalog assumes ElementName is unique:
So? That's an implementation of an extension point for the Catalog. It's not a
concrete, core class. There are other Catalog implementations. Furthermore, the
above code *does not* rely on the fact that the Element name is unique -- as I
said -- the behavior of getElementByName is such that it should only return the
first (and possibly only) matching Element with the given name. If there is
only one element (or even many Elements) the Catalog implementation still
functions as expected.
bq. 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
I'm happy to add the above method, but there isn't anything else across the
file manager that needs to be done.
bq. 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.
So basically what you're saying is that you had to branch an entire major
component of the system rather than simply extending the existing component and
writing your own ValidationLayer, as was intended when the extension point was
created? I'm not buying that, sorry. ValidationLayers are hidden in the catalog
implementation and thus don't have any specific contract on their particular
interface other than a few core methods. You could have arbitrarily added
methods to *your ValidationLayer implementation* without changing *any of the
core code* in the File Manager.
was (Author: chrismattmann):
Hi Brian:
bq. Not to start a he said you said, but you specifically total me that
ElementId is computer ID and ElementName is human readable ID
And how specifically is what I'm saying in violation of that statement (that I
did make, to leverage as an analogy to illustrate the concept)? The element ID
*is* the only part of the Element that I've said *must* be unique.
bq. there is code in the filemgr which relies on such a concept . . . for
example in DataSourceCatalog assumes ElementName is unique:
So? That's an implementation of an extension point for the Catalog. It's not a
concrete, core classes. There are other Catalog implementations. Furthermore,
the above code *does not* rely on the fact that the Element name is unique --
as I said -- the behavior of getElementByName is such that it should only
return the first (and possibly only) matching Element with the given name. If
there is only one element (or even many Elements) the Catalog implementation
still functions as expected.
bq. 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
I'm happy to add the above method, but there isn't anything else across the
file manager that needs to be done.
bq. 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.
So basically what you're saying is that you had to branch an entire major
component of the system rather than simply extending the existing component and
writing your own ValidationLayer, as was intended when the extension point was
created? I'm not buying that, sorry. ValidationLayers are hidden in the catalog
implementation and thus don't have any specific contract on their particular
interface other than a few core methods. You could have arbitrarily added
methods to *your ValidationLayer implementation* without changing *any of the
core code* in the File Manager.
> 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 below:
> {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 type.
> # 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
