All, So upon testing my first pass at the implementation, I realized that not all of our elements should be of the new subtype, as not all of the elements are backed in the Database.
I see two solutions to this: 1. Change the name of the element tag to a new name, for any element belonging to the new subtype. 2. If the element tag has the new fields I am adding, it is treated as the new subtype, otherwise it is treated as the old element type. I like solution 1, as it is a bit clearer from reading the xml file that there is a difference between types. Solution 2 requires fewer changes to the elements.xml file. Do you all have a preferred solution? -Michael On May 19, 2011, at 11:06 PM, Mattmann, Chris A (388J) wrote: > Hi Michael, > > I'd be happy to reply below, but yes I'd suggest initially CC'ing > [email protected]. Giving this information is great, but I prefer the > community to benefit from these types of discussions (and it means that I or > you or Albert or Cecilia can point others to this question if it is asked > again rather than typing the same answer again or fwd'ing something private). > Also no worries about researching it -- you can ask questions on that list -- > researched or not. We welcome feedback from the community. > > Answers inline below: > > On May 19, 2011, at 2:44 PM, Starch, Michael D (388L) wrote: > >> Chris, >> >> In order to create tables in the new database architecture that Brian Foster >> set up for use, we need the ability to specify some information beyond that >> which is stored in elements.xml. We wish to store this information as part >> of PCS, rather than continually haggling back and forth with our DBA in >> order to get this set in an ad-hoc manner. >> >> The data we need to store is: >> >> -Is it a vector type? >> -Data-type >> -Max data size >> and potentially a few more items. > > Gotcha. > >> >> As it stands now, Brian has used the DCElement tag in elements.xml file in >> order to store some of this information but not all of it. Thus it seems >> natural that the rest of this information gets stored along side it. >> >> There seem to be three ways to accomplish this: >> >> 1. Add more information to the DCElement tag, >> 2. Add additional tags to the element file containing this information >> 3. Create a sperate file to store this information (Not part of PCS) > > I've got a 4th option. > > 4. Write a new ValidationLayer implementation, that extends > XMLValidationLayer, but adds your desired information to elements.xml. For > that extra information, I'd favor your proposed option #2 -- I think it's > cleaner. > >> >> As head of oodt, we were looking for you input as to which option to choose, >> or if you wish this question to be brought to [email protected], where can I >> research this information before asking the question on that list? >> >> Below is a brief analysis of each option, from our perspective. >> >> Thanks, >> >> Michael Starch >> >> 1. Add more information to the DCElements tag. >> -I believe Brain said this tag was unused, so he "borrowed" it to suit >> this purpose. >> -Adding more information to the tag would "hijack" this tag to a >> further extent. >> -The changes could be made locally to our ColumnBasedDataSourceCatalog >> in the manner Brian already used. >> -If the DCElement is used ouside of the new use Brian invented, this >> change could affect the intended (original) use > > I don't like this one (nor do I think others will) since it hijacks dcElement > (which is supposed to be a mapping to a Dublin Core element name, rather than > used for other information). > >> >> 2. Add more tags to elements.xml >> -Most elegant solution, as each data field has a tag specified to hold >> exactly it >> -No need to use tags which were originally intended for some other >> purpose >> -It is an architectural change, changing the format of the elements.xml >> file >> -Must be done carefully to prevent us from deviating from apache-oodt >> when it is not necessary to do so. > > +1 for this option. > >> >> 3. A separate file >> -Creates data/configuration duplication, as some of these fields must >> stay (in some form) in elements.xml >> -Separates similar pieces of data >> -Doesn't alter PCS as it exists now > > This is fine too, but I prefer #2. > >> >> We favor number 1 or number 2 as it keeps similar data together, and feels >> like it is the most logical place to store this information. >> >> I personally favor number 2, as it does not use tags for unintended >> purposes, but I do not wish to make a change that affects our compatibility >> with apache code. Hence your input. >> > > +1 to your preference. I think the way to accomplish it is to write a > YourExtendedValidationLayer extends XMLValidationLayer and that provides a > customized: > 1. YourElementClass extends Element > - provides extra props (getters+setters) that you want to leverage > 2. implementations of the SerDe for your specialized elements.xml that > includes those extra tags > 3. provides the ability to access this ValidationLayer information and > Element information in ColumnBasedDataSourceCatalog. > > BTW, I think it would be great to bake up patches for Apache OODT for what > you are working on, including ColumnBasedDataSourceCatalog (already there but > in a branch, would be nice to forward port to trunk, and your proposed > ValidationLayer and Element extensions). Thoughts? Do you have the time? I > think the community at Apache would sincerely appreciate the effort. > > Cheers, > Chris > > P.S. Would you be OK with me forwarding this thread to [email protected]? I think > there's some good info here that I'd hate to be lost in the ether... > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/ > Phone: +1 (818) 354-8810 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >
