@kares What do you think for we should do for _string_to_time? Should we add our own method per in base adapter? I tried fixing it from java codebase but was not able to. Because I could not reach the column instance from native codebase.

I'm sorry, I can not tell without looking in detail ... I recall it's a "hack" to support conversion to Time and similar on the Java side. got introduced with the compatibility for custom selects such as SELECT now to have correct type, so there might be no Column info available (or maybe there is I'm not sure how Rails handles these cases - making sure a correct type is casted). the simplest thing possible to support would be najs :) would love to help but I really need to spend some quality AR-JDBC time elsewhere + it's about time for the youngsters to step up to their keyboards :) !

I'd just like to mention that I've added a $100 bounty to this project on BountySouce.
https://www.bountysource.com/issues/5831191-tasks-to-finish-4-2-support

Any further news on progress toward Rails 4.2 compatability?

Please note that the uuid native postgres type is not supported in the 4.2 version of the adapter. It works fine with 4.0 though. Many thanks for working on this!

I've added a bounty of 250USD to the project

Added another $15 and sent the bounty around on my social medias.

JRuby-based Rails 4.2 unable to let gem to generate model for us. For example, Remexify gem (and also Devise) were unable of generating model from scratch through its generate command.

@kares What's left on this? It looks like #632 was closed finishing [postgres] bigserial PK support rails/rails@6dc1787, and maybe type_cast for postgres.

we're working on it ... it still might need a week or two to get pass (hopefully most) supported adapters.

Oh awesome. Need help testing anything?

@Ch4s3 you could run against our 1-3-stable branch as it's already (and still expected) to be updated.
we'll mostly need non-mysql/pg/sqlite testers later ... oracle, db2, hsqldb, h2 maybe ms-sql and firebird
... but its likely we won't cover all (thoroughly) since its just too much to handle on our own ...

Ok, so 1-3-stable seems to work fine with jRuby 9000, Rails 4.2.3 for may app. I ran rake db:reset and a bunch of Postgres heavy rspec tests.

@kares Should we close this now? AR 4.2 is now supported on all but the special adapters: oracle, db2, firebird, and mssql. We could track these in separat issues, and only emit the AR 4.2 warning for these adapters.

do not see a reason why we should split it for a "few left" at least until a review is done. would prefer to keep the warning until the generic jdbc case handles type resolution to at least some degree (like it used to on pre 4.2) - travis-ci fully green ... think we're close but there's no need to rush. the hard work (after some of the special one reviews) will be mostly about supporting bug reports anyways.

👍

after 1.3.17 that included a lot of AR 4.2 compatibility improvements, mostly for MySQL/PostgreSQL as well as the generic JDBC adapter, in 1.3.18 literally all adapters have been reviewed to support AR 4.2 to around the same extent as they handle previous AR versions ... some of course need real-world usage to confirm thus warnings are left on Oracle/DB2/MSSQL despite support being there. also worth mentioning that generic adapter: jdbc and AR-JDBC extension gems should have an easier job of handling changes such as the 'new' AR::Type system since 1.3.18