Finally got these patches finished up. Sorry for the delay ( had a
machine learning program fighting me all weekend). Please let me know
if this is not what you need, or more it turns out there is something
not working. All seems to be working, and am actually using the
resulting jar in a external app. Though the tests get the job done,
they are a bit 'brute force'. i figure they can be re-factored later.
probably goes for the other code as well I suppose.
Jeff
On Jan 31, 2007, at 6:49 PM, Kris Jurka wrote:
>
>
> On Wed, 31 Jan 2007, Jeffrey Cox wrote:
>
>> Yea sure... I will look into the COLUM_TYPE issue and write a test
>> case for column names. On that note, when I ran the test suit all
>> the jdbc2 test would run fine, however, most of the others failed
>> due to "to many connections". I of course tried to up my max
>> connections beyond 20, but looks like will need to up shared
>> memory maximums. (which might be interesting given I am on os X.
>> Just never done that since switching). So before I go about
>> figuring all that out, are failures expected? and if not, any
>> thoughts on the number of connections I should configure for?
>>
>
> No failures are expected, but it's not surprising for things to go
> bad after completing the jdbc2 tests because that's when it starts
> testing connection pooling stuff that will open a fair number of
> connections. I don't think it uses more than 20 simultaneous
> connections so it's likely that there are just some that aren't
> closed or are in the process of closing as new ones are opened.
>
> If you can't get these tests straightened out I wouldn't worry
> about it because the changes you are making shouldn't affect any
> tests beyond the jdbc2 ones.
>
> Kris Jurka