-
Notifications
You must be signed in to change notification settings - Fork 386
Migrating from 1.2.x to 1.3.0
While the 1.3 release is meant to be compatible with 1.2 as much as possible (that's why it's not called 2.0 although it truly deserves it) there are a few places where things might have changed. Usually this is for the better to fix old unwanted behaviour and/or ActiveRecord compatibility.
In ActiveRecord 3.1 methods such as exec_query
, exec_insert
and exec_update
where added, on AR-JDBC's side support for them only meant delegating to what's been available already (mostly execute
). Thus in 1.2 exec_query
returns Array
results for all versions of ActiveRecord. Since 1.3 under ActiveRecord >= 3.1 we return ActiveRecord::Result
objects - which behave quite similar (like enumerables) but one does need to be aware of the differences and not assume they're instances of Array
.
Also related to exec_xxx
is binds substitution (with SQL strings), this is something ActiveRecord never supported e.g. exec_query('SELECT * FROM users WHERE name = ?', 'SQL', [ [ nil, 'kares' ] ])
fails with AR. However, "magically" works with AR-JDBC since we substitute bind parameters in a string. This of course is dangerous since we can not do it properly (there's no query analyzing) thus simply a query such as 'SELECT * FROM users WHERE name NOT LIKE 'k?%' AND created_at = ?'
with a single bind parameter provided will fail. Starting 1.3.0 this is getting deprecated and might be turned off (using the arjdbc.adapter.suble_binds VM property or programmatically ActiveRecord::ConnectionAdapters::JdbcAdapter.suble_binds = false
). Due some internal changes in ActiveRecord 4.0 string bind substitution is not supported if you're upgrading to 4.0 you will need to review your code (for most users this whole "suble_binds" things should be nothing to worry about).
When setting non-string values for string/text columns the adapter does a bit of quoting to make sure the database does not vomit. Some of the quoting logic was a bit surprising and seemed redundant esp. since 1.3 supports prepared statements thus things got changed, namely :
- for
true
/false
valuesto_s
will be called, previously they were "quoted" into'0'
/'1'
values - for non-numeric, non-boolean, non-string and non-date-like objects (e.g. Hash-es) 1.2 does
to_yaml
while 1.3 callsto_s
NOTE: this is all assuming plain-old non-serializable attributes - those behave as expected. Also on ActiveRecord 2.3 it behaves the same as before (returns to_yaml
) due the way how serialized attributes are handled in 2.3.