I did want to say that although it's not my current itch to scratch, if
anyone *does* decide to work on this bigger problem please let me know
so we can collaborate and/or not step on each other's toes.
Thanks,
David
David W. Van Couvering wrote:
> Thanks for your comments. If there is a way we could do this with the
> existing factory APIs (using properties), that would be grand. Perhaps
> that's possible.
>
> That said, my focus initially will be removing compatibility constraints
> on common code; this would be a second phase, and one I am NOT working
> on now if somebody else has this itch.
>
> David
>
> Daniel John Debrunner wrote:
>
>> David W. Van Couvering wrote:
>>
>>
>>> I also wanted to share an idea to help move us towards the larger
>>> problem supporting multiple Derby systems within the same VM (currently
>>> that's not possible).
>>
>>
>>
>>> DataSource dsA = systemA.getDataSource("jdbc:derby:wombat;create=true");
>>> DataSource dsB = systemB.getDataSource("jdbc:derby:wombat;create=true");
>>>
>>> Connection connA = dsA.getConnection();
>>> Connection connB = dsB.getConnection();
>>
>>
>>
>> Has some potential, I do think we need to be careful about going in
>> directions that are not in line with existing ways to load JDBC drivers.
>> For example your code is mixing JDBC URLs with DataSource, that's not
>> expected JDBC programming. If the getDataSource() method just returned a
>> DataSource object, then this would be closer to expected JDBC
>> programming.
>>
>> DataSource dsA = systemA.getDataSource();
>> DataSource dsB = systemB.getDataSource();
>>
>> // set JavaBean properties on dsA and dsB
>>
>> However, it does seem to me that JDBC already provides two factory
>> classes for getting connections, Driver and DataSource. Do we really
>> need another factory api?
>>
>> Dan.
>>
|