rails_db_views

rails_db_views copied to clipboard

Is it possible for the schema export to also dump the views into the db/schema.rb file? imo, that would be beneficial for anyone who uses this gem - also useful (imo) when using schemaSpy to generate db schema diagrams.

Currently I've no idea of how to do it. If you have any documentation, I would look forward to it.

However, doesn't it cause problem in case of generation from schema via rails db:schema:load ? It would create the table where no table exists...

@anykeyh - imo, since your plugin knows about the sql files, can you not inject the contents of the file within a connection.execute call inside of the schema.rb - (or) however your decipher the name of the view along with the appropriate DROP IF EXIST and CREATE VIEW... commands?

the whole reason I am looking at this gem is because rails does not support view creations, and thus can't have them created via the schema.rb file.

the alternative, is to dump your DB into a structure.sql file instead, via a config option http://guides.rubyonrails.org/v3.2.8/migrations.html#types-of-schema-dumps

I like the idea of using a separate rake task to create those when needed.

rake db:create_functions                # Create or replace all the functions
rake db:create_views                    # Create all the database views of the current project
rake db:drop_functions                  # Remove all the functions (to use manually only)
rake db:drop_views                      # Drop all the database views of the current project

the whole reason I am looking at this gem is because rails does not support view creations, and thus can't have them created via the schema.rb file.

I think schema.rb can leverage all the goodness of AR Migrations - and thus can also have connection.execute statements within it as well.

i found a gem that does it, and that's what I will use

https://github.com/thoughtbot/scenic

thanks @mathieujobin - i might also switch over if the transition is palatable.

Hello ! Scenic is indeed doing this. It acts differently from this gems as it manages views through migration, which I would argue is not want I wanted to do here (to much hassle in my opinion, as views are read only!).

It handles also materialized views, something which I will never do.

In my case, we use different set of views, which are connected through each other. Having directive to handle the creation process was a must have in my current projects.

Due to lack of activities here, this gem is not so well maintained, which is something which can change in the futur if I see a real need.

Some good features we built will be merged also here soon, noticeably the ParametrableView system we built, which allow you to use view object with custom filters in your query and improve drastically the performance for view projection on big set of data ( no more CTE scan / view seq scan ! ).

Feel free to test both and chose wisely