Calling for opinions: incompatibility between v0.x and v1

[mirakui]

There are several incompatible changes from Arproxy v0.x to v1.
In most cases, existing configurations can be used as-is in v1, but there are some exceptions.
The specification of custom proxies (classes inheriting from Arproxy::Base) has changed as follows:

1. Removal of keyword arguments (kwargs)

In v0.2.9, **kwargs was added to the arguments of the #execute method (#21), but this argument has been removed in v1.

These kwargs were removed in v1 because their specifications differed depending on the Connection Adapter of each database.

# ~> v0.2.9
class MyProxy < Arproxy::Base
  def execute(sql, name=nil, **kwargs)
    super
  end
end

# >= v1.0.0
class MyProxy < Arproxy::Base
  def execute(sql, name=nil)
    super
  end
end

2. Arproxy::Base#execute (super) no longer executes queries

In v0.x, the Arproxy::Base#execute method was a method to execute a query on the Database Adapter.
That is, when super is called in the #execute method of a custom proxy, a query is executed on the Database Adapter at the end of the proxy chain.

In v1, the Arproxy::Base#execute method does not execute a query. The query is executed outside the #execute method after the proxy chain of #execute is complete.

This change was necessary to support various Database Adapters while maintaining backward compatibility with custom proxies as much as possible.

However, this change has the following incompatibilities:

• The return value of super cannot be used.
• The query execution time cannot be measured.

2.1. The return value of super cannot be used

In v0.x, the return value of super was the result of actually executing a query on the Database Adapter.
For example, if you are using the mysql2 Adapter, the return value of super was a Mysql2::Result object.

In v1, the return value of super is a value used internally by Arproxy's proxy chain instead of the result of actually executing a query on the Database Adapter.
You still need to return the return value of super in the #execute method of your custom proxy.
However, the Arproxy::Base in v1 does not expect to use this return value in the custom proxy.

If your custom proxy expects the return value of super to be an object representing the query result, you need to be careful because it is not available in v1.

class MyProxy < Arproxy::Base
  def execute(sql, name=nil)
    result = super(sql, name)
    # ...
    # In v0.x, the return value of the Database Adapter such as Mysql2::Result was stored,
    # but in v1, the value used internally by Arproxy's proxy chain is stored.
    result
  end
end

2.2. The query execution time cannot be measured

For example, even if you write code to measure the execution time of super, it no longer means the query execution time.

class MyProxy < Arproxy::Base
  def execute(sql, name=nil)
    t = Time.now
    result = super(sql, name)
    # This code no longer means the query execution time
    Rails.logger.info "Slow(#{Time.now - t}ms): #{sql}"
    result
  end
end

Discussion

The specification changes in v1 have allowed more Database Adapters to be supported and made Arproxy more resistant to changes in ActiveRecord's internal structure.
However, as described in the previous section, there are cases where the custom proxies written in v0.x will no longer work.

We do not know the use cases of Arproxy users other than ourselves very well, so we are soliciting opinions on the changes in this time.
If there are many requests, we will prepare a new base class for custom proxies with a different interface from Arproxy::Base, so that custom proxy writing similar to that in v0.x can be done.

[negipo]

@mirakui Hello,

We are using Blouson::SensitiveTableQueryLogSilencer from cookpad/blouson. It uses Arproxy and silences logs by wrapping super with ActiveRecord::Base.logger.silence { ... }. Therefore, it seems that it doesn't work with the v1 specifications proposed here. Please consider this as an example of an use case as it is not functional.