Any Interest in Moving Rails SQL Views into AR?

One of the items which has come out of the ActiveWarehouse plugin development is the Rails SQL Views plugin. It adds support for create_view and drop_view statements in migrations and also supports extracting those elements to the schema.rb dump. Currently it is implemented for MySQL and PostgreSQL. Is there any interest in eventually moving this code into ActiveRecord or should it just remain as an extension gem/plugin?

If there is interest to bring it into the AR core then I can create the patches for it.

Thoughts?

V/r Anthony Eden

I think possibly the biggest issue with bringing views into AR's schema notation is that most (useful) views don't just contain columns from other tables; they often perform functions (SUM, AVG). From looking at the current plugin, it seems like you'd end up having to write that as a fairly explicit SQL statement, and I'm not sure in such cases how great the value in using Ruby to declare the columns.

In a nutshell, is

  create_view :v_stuff, %{      SELECT thing_id, other_thing_id, SUM(stuff) as blah      FROM things, other things      WHERE thing_attribute LIKE "wibble"      GROUP BY other_things.cost   } do |v|      v.column :thing_id      v.column :other_thing_id      v.column :blah   end

really that much better than

  SomeModel.connection.execute %{      CREATE VIEW v_stuff AS (      SELECT thing_id, other_thing_id, SUM(stuff) as blah      FROM things, other things      WHERE thing_attribute LIKE "wibble"      GROUP BY other_things.cost )   }

... I'm not sure. Convince me, because we're using views with legacy-style databases at the moment, and if anything can be done make this simpler, I'm definitely interested.

- James

I think the primary benefit would be that views would be included in schema.rb and thus would be usable in the test environment with no additional work required. The primary thing is that Rails would understand views whereas right now views just get silently ignored.

V/r Anthony

Hi Lists,

I think possibly the biggest issue with bringing views into AR's schema notation is that most (useful) views don't just contain columns from other tables; they often perform functions (SUM, AVG). From looking at the current plugin, it seems like you'd end up having to write that as a fairly explicit SQL statement, and I'm not sure in such cases how great the value in using Ruby to declare the columns.

In a nutshell, is

  create_view :v_stuff, %{      SELECT thing_id, other_thing_id, SUM(stuff) as blah      FROM things, other things      WHERE thing_attribute LIKE "wibble"      GROUP BY other_things.cost   } do |v|      v.column :thing_id      v.column :other_thing_id      v.column :blah   end

really that much better than

  SomeModel.connection.execute %{      CREATE VIEW v_stuff AS (      SELECT thing_id, other_thing_id, SUM(stuff) as blah      FROM things, other things      WHERE thing_attribute LIKE "wibble"      GROUP BY other_things.cost )   }

This is my first post to this list.

We now working on integration of our Valentina database into RoR.

During this, we have note, that RoR people are used to specify field alias without single quotes, as above for example.

      SELECT thing_id, other_thing_id, SUM(stuff) as blah                                                  ^^^^^^^^^

I wonder, may be it can be more accurate if ROR will produce SQL queries using single quotes, according to SQL92 standard?

Also, please, let me know if this list is correct place for talk/questions about Valentina database integration into ROR?

Hi, Anthony,

Maybe, one has to think about a different syntax, e.g., something like: create_view :my_view do |v|     v.column :thing :from => table1.thing     v.column :thing2 :from => table2.thing     v.conditions :where=>some sql, :group => again_sql end

Well, personally, I am convinced that extending AR with capabilities of modeling also sql views is essential advantage.

Greetings, Giorgi

Anthony Eden wrote: