db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Bateman <r...@windofkeltia.com>
Subject Re: So, Derby works...
Date Wed, 08 Jul 2020 23:50:44 GMT
The mock driver supports a sort of bogus URL ("jdbc:mock") that it 
recognizes for its purpose which is only to respond to a single query 
with canned data (whereas I'll be able to populate Derby with as much 
and whatever data I ever want). Of course, its driver doesn't ever do 
anything "real," though it supports a few metadata methods (and the 
MockConnectionimplements Connectionand supports a whole pile of methods 
that stub out most actions and unimaginatively return the canned data).

Yes, your suggestion #3 works well and solves that particular problem of 
an empty driver list. (The list is empty instead of containing the mock 
driver because I separated the packages. DriverManagerdoes some 
reflection desperately looking for classes that might have drivers.) The 
list now has the Derby driver in it:

Down inside DriverManager's private getConnection(), walking the driver 
list using the IntelliJ IDEA debugger, I see:

    *aDriver* = {DriverInfo@2097}
    *con* = {EmbeddedConnection@2585}
    "org.apache.derby.impl.jdbc.*EmbedConnection*@1414013111 (XID =
    164), (SESSIONID = 1), (DATABASE = memory:sys), (DRDAID = null) "

I have to admit that I'm not to the point yet where I grok why I'm 
seeing AutoloadedDriverwhen I forced Java to verify EmbeddedDriver. I 
got no errors doing that; I did it just before making the call to 

    Class.forName( "org.apache.derby.jdbc.EmbeddedDriver" );
    "jdbc:derby:memory:sampledb;created=true", "sa", "sa" );

I have learned a great deal more about JDBC drivers than I had planned 
thanks to deciding to use Derby, replacing this old test mock and with 
your help which I hugely appreciate!


On 7/8/20 5:15 PM, Rick Hillegas wrote:
> It's hard to say what's going on, but the instability in your 
> experiments is hard to reconcile against the deterministic code paths 
> involved in JDBC autoloading.
> I can only speculate about what is causing this instability:
> 1) What JDBC URLs does your MockDriver claim to support?
> 2) Is something tricky being done to the classpath, creating a 
> situation in which the Derby jars are not visible when you invoke 
> DriverManager.getConnection()?
> 3) What happens when you do a 
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver")? What are the 
> chain of errors raised? For the record, this is the recommended JDBC 
> way to fault in a driver which was missed at autoloading time. 
> Autoloading occurs on the very first call to 
> DriverManager.getConnection() during the lifetime of the JVM.
> Hope this helps,
> -Rick
> On 7/8/20 10:37 AM, Russell Bateman wrote:
>> ...again, don't know what I changed.* I'm only depending on 
>> /derby-
>> What I think is going on is an artifact of being side-by-side with 
>> another JDBC driver implementation.
>> I was hoping to keep the original mocked test driver working 
>> alongside the Derby implementation at least until I'm able to abolish 
>> it in every case. Just as used to be the case, it's registered thus:
>>     DriverManager.registerDriver( new MockDriver() );
>> However, this is not how it works for Derby. It just happens on the 
>> basis of having the JAR linked (in /pom.xml/). The problem comes 
>> that, because the MockDriveris explicitly registered, when we go to 
>> create a Derby connection:
>>     java.sql.Connection connection = DriverManager.getConnection( 
>> "jdbc:derby:memory:sampledb;create=true" );
>> ...DriverManagertakes as license to create an instance of the old 
>> test mock because that is the (only) driver in its 
>> registeredDriverslist. *I moved the Derby-based code out of the same 
>> Java package to solve this?
>> Thanks again. I'm sorry for having made this annoying.
>> Russ

View raw message