<kares>
latest 1.3.x however works with 9.4 fine so it would make sense to have a plan for that as well ...
<headius>
kares: yeah this is part of the move to have major versions tied to a specific rails major (5.0, 5.1) so we don't have to manage many versions in a single branch
<headius>
dunno if you saw yesterday but debating versioning scheme...something like 50.x.y, 51.x.y for arjdbc for Rails 5.0, 5.1 seems logical
<headius>
we are trying to match API compat after all, so having the rails number as our major would be clean
dave__ has joined #jruby
dave__ has quit [Ping timeout: 260 seconds]
<rdubya>
kares: sounds good, was hoping we'd be able to get upgraded for this release
<GitHub143>
jruby/master 4f6e17c Charles Oliver Nutter: Merge remote-tracking branch 'origin/jruby-9.1'
<GitHub7>
[jruby] headius closed issue #4843: popen doesn't work on Windows https://git.io/vFu2h
olle has quit [Quit: olle]
<headius>
love those copypasta bugs
<kares>
headius: whatever you guys came up with - other adapters depending on Rails and supporting only a single release follow the Rails numbers
<kares>
but I am not sure I like it - was thinking about the same and there's no good solution I got
<kares>
basically Rails versioning is 'screwed' ... it isn't really for users but for adapter gem creators :)
<enebo>
kares: ultimately I am not a fan multi-branch releases but I think from point to point we will not have much we need to change across the branches
<enebo>
kares: but arjdbc 1.3.x is very difficult to know whether code can be changed because we do not know details of all supported things
<kares>
well the Rails chase is (still) on ... time will tell
<kares>
enebo: yy
<enebo>
kares: and I think historical Rails support was much harder than now
<enebo>
kares: although I will be proven wrong in Rails 6 no doubt :)
<kares>
well I am amazed about the 5 work ... assumed its not that big of a change
<enebo>
mysql adapter code is almost down to 100 lines (excluding connection_methods)
<kares>
but given all the legacy crap ... that might adding quite a lot to the pile
<enebo>
ruby code that is. We still have plenty of Java
<kares>
Java we must!
<enebo>
yeah I think we need legacy to stay 1.3.x forever until you/or someone does not want to support that and hope rails 5+ single version support works out well
<kares>
on a related topic - guess what the next version of PG's driver after 9.1 -> 9.2 -> 9.3 -> 9.4.1212
<kares>
42.0.0
<enebo>
hahaha really?
<kares>
YES :)
<enebo>
man we are going the right direction then!
<kares>
exactly
<enebo>
kares: since you are here...
<kares>
sorry I did not manage out jossl for 9.1.14 ;(
<kares>
haven't got the time to look into that ... or test out headius proposal
<kares>
enebo: hit me
<enebo>
kares: so this setTimestampParameter method was basically checking to see if it was a RubyString and then emulated some AR code but using a double calculation
<enebo>
kares: but in Rails 5 I think we will always get something which will coerce into a Time
<enebo>
kares: in general will prepared statements which has proper types ever be a String or something unknown?
<kares>
yeah I tihnk it got redone on master
<enebo>
kares: in this method I eliminated everything but assuming it will be a time
<kares>
enebo: it should get proper things but I noticed bits changed in AR 5
<kares>
so I can not tell for sure ...
<enebo>
kares: ok so I think we will lean on AR tests for that then
<kares>
if tests pass than it must be OK
<kares>
and assuming PS is on by default ...
<kares>
should be fine
<enebo>
kares: well that is funny thing to mention
<kares>
(I mean in Rails tests that you have prepared-statements enabled by default)
<enebo>
kares: I can run with prepared enabled or disabled but somtimes AR passes binds in and then we are "yes binds...prepare stmt time"
<kares>
well that certainly wasn't the case before
<kares>
but I barely run Rails tests
<enebo>
kares: personally I think this is reasonable but perhaps we messed something up
<enebo>
kares: but binds have to be the cause of that
<enebo>
This is one of those things where I think we will get a report or not
<kares>
sounds spooky - think if you turn PS off you should not get binds
<enebo>
I might try and find some rails devs next week and ask
<kares>
at least not on the exec_xxx paths
<enebo>
kares: in the case of mysql I am not using hardly any code
<enebo>
kares: so it is all coming from Rails
<kares>
it might be that for internal calls (getting meta-data) they still force PS
<enebo>
yeah that is a good thought
<kares>
I mean getting table data / index data
<enebo>
perhaps it is more for that
<enebo>
but I think I saw it once with a timestamp model test
<enebo>
anyways if this is a major issue someone will notice :)
<kares>
yy
<enebo>
my other mysql woe is that I am appending some garbage to get utf8 support