What are your thoughts on the 'schema_plus_views' gem?

[EverybodyKurts]

Hey all, let me know if this is not the right place to bring this up.

Like thoughtbot's scenic gem, the schema_plus_views gem gives the developer a way to create database views through the rails api and to capture those views in the app's schema file.

One interesting difference is in its Creating Views section. You can create views through the ActiveRecord api.

It gives the following example:

create_view :posts_commented_by_staff,  Post.joins(comment: user).where(users: {role: 'staff'}).uniq

I can see an advantage and disadvantage. I can utilize the scopes and associations I've already defined on my models. I don't have to recreate them in a sql file. However, if scopes or where predicates change, two developers can have different views depending on when they run the migration.

What do you all think?

[derekprior]

We've talked about doing the same, but I have the same concerns as you. It boils down to the same reason you are discouraged from accessing external ActiveRecord models in your migrations - the underlying code can change or go away completely, leaving your migration in an invalid or incorrect state.

I could perhaps see a generator that accepts a ruby string which is then to_sqld or something? Not really sure. To be honest, my intended use case for scenic is one where you want to write SQL.

@calebthompson thoughts?

[derekprior]

More broadly, on the schema_plus_views gem: This gem did not exist separately from schema_plus itself when we started this project. schema_plus did things we didn't like, so we weren't comfortable trying to use it just for view support. It also didn't offer view versioning, like scenic tries to.

Now that schema_plus_views does exist, it may make sense to see if we could merge some of the ideas of scenic into schema_plus_views without breaking either. Food for thought anyway.

[EverybodyKurts]

I don't know. I'm pretty happy with the gem as is. You guys did a great job making this. I looked at the pull requests for materialized views but I just don't have a need for them (selfish, I know).

[calebhearth]

The ruby string thing in the generator is iffy. I rarely get complicated strings like that right the first try, and on the command line I doubt it would work. I do still like the idea of a to_sql thing though.

What about an example in the README of generating the view in IRB with scopes, then printing the to_sql and throwing it in the view definition file (incidentally, this is how I'd recommend you do it).

[calebhearth]

Our name is better we can't give up.

[derekprior]

This isn't a feature we're going to consider at this time. Thanks for the discussion, though.

[EverybodyKurts]

Totally agree! SQL statements in the schema show how the view's being built - especially important since it relies on other tables in the database. I've been using the gem for a couple of months now and am very pleased with it.