Rails edge now includes activerecord test adaptors for jdbc databases

Ruby JRuby
1

The patch on this ticket for rails: Add AR test-connections for JDBC via
JRuby
http://rails.lighthouseapp.com/projects/8994/tickets/1685-adding-ar-test-connections-for-jdbc-via-jruby

Was just applied to rails edge:

This means with edge rails you can now run the full active-record
suite of tests against the following databases connections (without
patching rails):

jdbcmysql jdbcpostgresql jdbcsqlite3 jdbcderby jdbch2 jdbchsqldb

There’s still a bunch of work to do to get most of these databases
and the connectors passing the activerecord test suite.

The jdbcmysql adapter/database is the only one close.

Here are my results from a couple of weeks ago:

test status with trunk JRuby (r8541) and activerecord-jdbc v0.9

jdbcmysql: 1807 tests, 6004 assertions, 20 failures, 1 errors
jdbcpostgresql: 1812 tests, 1310 assertions, 4 failures, 1675 errors
jdbcsqlite3: 1807 tests, 889 assertions, 15 failures, 1673 errors
jdbch2: 1807 tests, 1809 assertions, 41 failures, 1361 errors
jdbchsqldb: 1807 tests, 4181 assertions, 33 failures, 553 errors
jdbcderby: 1812 tests, 759 assertions, 20 failures, 1765 errors

There’s some additional info about how to run the tests in the
Lighthouse ticket link.

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
2

Stephen B. wrote:

test status with trunk JRuby (r8541) and activerecord-jdbc v0.9

jdbcmysql: 1807 tests, 6004 assertions, 20 failures, 1 errors
jdbcpostgresql: 1812 tests, 1310 assertions, 4 failures, 1675 errors
jdbcsqlite3: 1807 tests, 889 assertions, 15 failures, 1673 errors
jdbch2: 1807 tests, 1809 assertions, 41 failures, 1361 errors
jdbchsqldb: 1807 tests, 4181 assertions, 33 failures, 553 errors
jdbcderby: 1812 tests, 759 assertions, 20 failures, 1765 errors

Heh, I guess we need a little work on the others :slight_smile: Though with the
number of failures it almost seems like they’re misconfigured or
something.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
3

Actually, in running sqlite3 the other day I could tell that lack of
column quoting caused almost none of the proper tables to get set up.
I think a few fixes could probably fix a large number of these.

-Tom

On Mon, Jan 26, 2009 at 12:49 AM, Charles Oliver N.
[email protected] wrote:

–
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [email protected] , [email protected]

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
4

Another problem with the sqlite3 adapter is going to be its handling (or
lack there of) in dealing with Dates and Time unless someone has worked
on
this since I put together the original sqlite3 adapter. I couldn’t ever
really figure out how dates are supposed to work with sqlite3 since
according to the documentation it doesn’t have built in types for them
Datatypes In SQLite. But the native C adadpters seem
to
somehow create them anyways.

Could I also recommend that as we fix these test failures from rails we
try
and port them back in to the actually activerecord-jdbc project’s tests?
For example I’m pretty sure the sqlite3 adapter passes these tests, but
obviously it still has major issues.

Joe

5

On Mon, Jan 26, 2009 at 12:47 PM, Joseph A. [email protected]
wrote:

For example I’m pretty sure the sqlite3 adapter passes these tests, but
obviously it still has major issues.

We did land some fixes for date/time/datetime for sqlite3 recently.

Also we added a few common tests for these fixes for out local
testsuite (interestingly, sharing these helped find bugs in other
adatpers). So adding more tests is a good idea…

-Tom

–
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [email protected] , [email protected]

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
6

Stephen B. wrote:

This means with edge rails you can now run the full active-record
Here are my results from a couple of weeks ago:
There’s some additional info about how to run the tests in the
Lighthouse ticket link.
Thanks for putting this patch together. Nick had already +1’d it and
when I looked at it I was surprised it hadn’t been plus-oned a second
time yet.

Hopefully, we can spend a little bit of time to correct most of these
errors. Most early errors appear to be the cause of later errors, so
the results are not as dire as they look in the results (at least I
think so).

-Tom

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
7

1812 tests, 5372 assertions, 60 failures, 39 errors (was: 1807 tests,
889 assertions, 15 failures, 1673 errors)

This is looking much better than before. So, I will try and go
through the other adapters and at least get them far enough past
simple quoting bugs to see where we really stand with each one.

Thanks Tom!!!

I’m helping where I can and I figured if I could get the tests for
the jdbc adapters into rails edge it would be much easier for all of
us to fix the issues.

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
8

On Mon, Jan 26, 2009 at 2:03 PM, Thomas E Enebo [email protected]
wrote:

and port them back in to the actually activerecord-jdbc project’s tests?
For example I’m pretty sure the sqlite3 adapter passes these tests, but
obviously it still has major issues.

We did land some fixes for date/time/datetime for sqlite3 recently.

Also we added a few common tests for these fixes for out local
testsuite (interestingly, sharing these helped find bugs in other
adatpers). So adding more tests is a good idea…

I just a couple of very small changes to sqlite3 adapter and we are:

1812 tests, 5372 assertions, 60 failures, 39 errors (was: 1807 tests,
889 assertions, 15 failures, 1673 errors)

This is looking much better than before. So, I will try and go
through the other adapters and at least get them far enough past
simple quoting bugs to see where we really stand with each one.

-Tom

–
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [email protected] , [email protected]

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
9

Joseph A. wrote:

That’s just great getting the sqlite3 adapter working so well, I think
supporting the default rails db type will be nice for anyone looking to
try out JRuby.

BTW, if anyone knows where to patch, it would be supergreat to get the
“rails” command to accept our “jdbc” adapter names, like

rails -d jdbcmysql

If there’s a set of names it recognizes, we ought to be able to just
submit a patch for our JDBC versions, so they generate the right
database.yml under JRuby too.

  • Charlie

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
10

I see in the code where this is going on, but I’m wondering what the
best
solution is. I see 3 choices:

  1. We just follow the same model in the current code and add the jdbc
    adapters as valid choices and add corresponding database.yml templates
    for
    each of our adapters (unfortunately quite a bit of redundancy there
    with
    nearly identical yml files)

  2. In each of the template database.yml files, do a simple check of the
    environment being used to create the file, if we are using jruby, simply
    append jdbc to the front of the adapter name. So if you generate your
    rails
    app using JRuby you just send normal options to the rails command, but
    when
    it generates your app it will put “jdbcmysql” as the adapter instead of
    just
    “mysql”, as an example.

  3. Change the rails app generators to make the database.yml files jdbc
    and
    native driver safe out of the box. So intead of:
    development:
    adapter: mysql
    encoding: utf8
    database: myapp_development
    pool: 5
    username: root
    password:
    host: localhost

Actually generate the database.yml file as:

development:
adapter: <%= RUBY_PLATFORM =~ /java/ ? ‘jdbc’ : ‘’ %>mysql
encoding: utf8
database: myapp_development
pool: 5
username: root
password:
host: localhost

right out of the box. Anyone have any thoughts? For an example of one
of
the yml files see this:

Joe

On Tue, Jan 27, 2009 at 9:02 AM, Charles Oliver N. <

11

Well 1 probably would mean the least amount of change, but you’re right
about it being a lot of duplication. But 2 and 3 seem unlikely to happen
since they would mean adding JRuby-specific stuff to every template.
Then what happens with the next impl and the next?

I’m leaning toward just doing 1 for now and having a jruby dir with all
our supported adapter names and templates. They’ll probably be
duplicates in several cases, but they’ll be totally new in others (h2,
derby for example).

  • Charlie

Joseph A. wrote:

append jdbc to the front of the adapter name. So if you generate your
pool: 5
pool: 5

BTW, if anyone knows where to patch, it would be *supergreat* to get

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
12

I’m sure you are right that path #1 is the least resistance. One thing
I’ve
never found out is why do we have to put “jdbcmysql” anyways? Isn’t
there
some way in the JDBC adapters to get just “mysql” to load the correct
jdbc
adapter? It seems like that is the “right” answer. I would think the
ultimate goal would be for a developer to write their application one
way no
matter what the Ruby implementation used is. I’m sure there is a good
reason I just can’t remember what it is now.
To pursue #1 we just start by making a lighthouse ticket right?

Joe

On Tue, Jan 27, 2009 at 11:04 PM, Charles Oliver N. <

13

On Mon, Jan 26, 2009 at 4:21 PM, Thomas E Enebo [email protected]
wrote:

Could I also recommend that as we fix these test failures from rails we try

I just a couple of very small changes to sqlite3 adapter and we are:

1812 tests, 5372 assertions, 60 failures, 39 errors (was: 1807 tests,
889 assertions, 15 failures, 1673 errors)

Did a few minor changes to Derby adapter:

1817 tests, 5484 assertions, 41 failures, 185 errors (was: 1812 tests,
759 assertions, 20 failures, 1765 errors)

-Tom

–
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [email protected] , [email protected]

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
14

On Tue, Jan 27, 2009 at 11:17 PM, Joseph A. [email protected]
wrote:

I’m sure you are right that path #1 is the least resistance. One thing I’ve
never found out is why do we have to put “jdbcmysql” anyways? Isn’t there
some way in the JDBC adapters to get just “mysql” to load the correct jdbc
adapter? It seems like that is the “right” answer. I would think the
ultimate goal would be for a developer to write their application one way no
matter what the Ruby implementation used is. I’m sure there is a good
reason I just can’t remember what it is now.
To pursue #1 we just start by making a lighthouse ticket right?

Yes, but I think they like patches attached to those tickets as well.
So if you don’t have the patch ready perhaps specify you are working
on the enhancement so they don’t close it out of hand.

Thanks for working on this… :slight_smile:

-Tom

–
Blog: http://www.bloglines.com/blog/ThomasEEnebo
Email: [email protected] , [email protected]

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email