oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From holeno...@me.com
Subject Re: Organization of Java-SQL-DB Interface
Date Wed, 04 Apr 2012 20:37:31 GMT
hey mike,

Are you looking do something like this?  Storing queries in a file and adding in values utilizing
PathUtils replacement:
SELECT DISTINCT product_id from MOA_IASI_L1C_Metadata where element_id = 'urn:peate:NominalDate'
and element_value = '[NominalDate]';

While this is cool and convenient, i see a few problems with dynamically loading the queries:
1) The inline queries in Java are able to be well unit-tested
2) Making the queries too easy to change can be a production code nightmare... This is the
SQL which determines if the Product's metadata gets ingested correctly or not... i wouldn't
want to just be able to easily changes these without going through a rigorous testing process
to be sure they work correctly

While i noted these problems, i'm not adverse to this being checked in as a new implementation...
i'd be interested to see what you've got... could you create a JIRA issue and attach your


Not sure you want these SQL commands to be easy to change... you pull them out then they become
hard to unit-test... also 

On Apr 04, 2012, at 01:00 PM, "Starch, Michael D (388L)" <Michael.D.Starch@jpl.nasa.gov>


I am currently working on designing a catalog implementation that interacts with an oracle
database for use with the filemanager component. The current version uses sql that is inline
with the java code. However, a recent need for maintenance to this SQL has highlighted the
need to pull the sql into separate files for easier maintenance.

What is the preferred way in oodt to store such information and load it?

-Michael Starch

  • Unnamed multipart/alternative (inline, None, 0 bytes)
    • Unnamed multipart/related (inline, None, 0 bytes)
View raw message