db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Army <qoz...@sbcglobal.net>
Subject Re: Derby-573 - optimizer overrides changes to metadata.properties and upgrade
Date Fri, 11 Nov 2005 19:45:33 GMT
> Mamta Satoor wrote:
>>The patch for optimizer overrides includes changes in metadata.properties.
>>I think this change in metadata.properties is going to require some form of
>>upgrade code so that the sql text stored in the systems tables can be
>>replaced with new sql text which uses this new form of optimizer overrides.

If I'm following the metadata codepath correctly, I don't _think_ the SQL text 
for metadata.properties is actually stored in the system tables.  Rather, Derby 
reads the "metadata.properties" file (which is part of the classes directory and 
is included in the build jars) directly at run time.

To explain why I think this is the case, take "getProcedures()" (which is part 
of the Java DatabaseMetaData class) as an example.  In the EmbedDatabaseMetaData 
class, the getProcedures() call ends up being:

	PreparedStatement s = getPreparedQuery(queryName);
	s.setString(1, swapNull(catalog));
	s.setString(2, swapNull(schemaPattern));
	s.setString(3, swapNull(procedureNamePattern));
	return s.executeQuery();

"getPreparedQuery()" includes the following line:

	String queryText = getQueryDescriptions().getProperty(nameKey);

Then "getQueryDescriptions()" calls "loadQueryDescriptions()", which does some 
security checking and ultimately calls "PBloadQueryDescriptions()", which 
(finally) calls:

	InputStream is = getClass().getResourceAsStream("metadata.properties");		

As a quick (but not by any means exhaustive) check of this, I went and renamed 
the "metadata.properties" file in my classes directory to something else, then 
tried to call "getProcedures" from a Derby DatabaseMetaData instance after 
connecting to (an already created) database.  The call failed with an NPE 
because the InputStream was not able to find metadata.properties.  I then put 
the metadata.properties file back and deleted the "getProcedures" statement, to 
see what would happen if the file was there but didn't have the query in it. 
That failed, too, with an error saying:

	Feature not implemented: getProcedures.

So that leads me to believe that the queries are not actually stored in the 

As for the stored procedures that Kathey mentioned, those are used for 
client-server communication.  The client calls these stored procedures, which 
are then mapped to the appropriate methods in EmbedDatabaseMetaData (the mapping 
occurs in SystemProcedures.java, which is where the stored procedures are 
implemented), and thus the same codepath shown above is used.

>>I wondered if anyone can give me some pointers on how to get started with
>>upgrade code to achieve this. In the mean time, I will start looking into it

All of that said, I'm not entirely sure what that means for your upgrade 
question.  But here's my theory:

Even if metadata.properties is different from one version to another, the engine 
will only read the metadata.properties file that it has in its build.  So as 
long as your changes don't modify the stored procedure signatures in any way 
(they only change the metadata.properties file), I don't _think_ upgrade is an 
issue because nothing in the system table has actually changed.

As for soft upgrade...umm, I tend to lean toward this being a non-issue, as 
well, because nothing in the database is actually _changed_ when a metadata 
procedure is called.  If you soft upgrade to a later version, execute a bunch of 
metadata queries, then revert back to an older version and execute a bunch more 
metadata queries, everything should still be fine...I think.

But all of that is based on my examination of the metadata codepath; if I've 
overlooked or oversimplified, people should feel free to correct me.

Hopefully that's more helpful than confusing,

View raw message