Open fibers opened 10 years ago
Very interesting.
Before Rails 4 and ActiveRelation's references
method the logic of includes
was as follows:
You used the first case to run the query for two different databases, which is kind of amazing :) I don't think that AR authors could ever imagine such usage :)
In Rails 4 this automagical recognition of whether there are conditions for that table or not has been dropped in favor of references
, which is an explicit way of saying "I want this association to be joined in one SQL query and there will be conditions on that table".
The effectively broke WiceGrid in Rails 4 in those cases when there are filters for the columns from that associated table. Apparently this is not your case because you only used includes
to preinitialize all associated ActoveRecord, and not for filters.
I needed to start using references
, and because the whole point of WiceGrid is to run one big query, I retained the Rails 3 behavior of includes
by running references
inside of the plugin for every association in includes
. In my mind this was a bugfix, hence a minor version was incremented, but it broke your usage of includes
.
This all leads me to believe that I should follow the semantics of ActiveRelation and introduce references
explicitly in the API. Then the plugin will work again for your two databases.
Example. Using self.establish_connection to specify the belonging database. Model 'User' from database A, Model 'UserReport' from database B
if we initialize the grid like this :
When in version 3.4.4 , this would create the following sql plans.
It won't cause any problems cause it query the database by a sequence sqls step by step. Each sql will use rails native method, so the application know which database the sql should be sent to.
But when in version 3.4.9, the wice_grid will generate the sql with 'JOIN' clause.
In this case , the application will be confused.