Consider making `Scenic::Adapters::Postgres` public API about scenic HOT 10 CLOSED

We would keep the internal classes private (the connection decorator, the views, query object) except for the exceptions that are included in #111, which would be public since they are surfaced in user apps.

from scenic.

Docs aside, is there a benefit an end user might have see from using the Postgres class?

from scenic.

The refresh method, for one, lives only there. We could add a method directly to the Scenic module to abstract that, I suppose.

Other than knowing some more specific information on how the methods behave, I don't think there's much practical use beyond the refresh method. From time to time, I've wanted to do things like call add_index from something other than a migration so I could see that maybe coming in handy but it's a stretch.

Hmmm.

from scenic.

We could promote refresh to the generic adapter module as well. It could noop by default.

I'd obviously rather not expand the surface area of the API if not necessary, especially since the class is documented and open source for a reference.

Maybe there's room for add_ and remove_index in the adapter API as well if that's necessary? Is there a reason that isn't support through AR::Migration's generic interface to databases?

from scenic.

Sorry, I wasn't clear: The add_index example I gave was a poor analogy. I was trying to say that sometimes I want to execute methods that migration schema methods make available in my regular (non-migration) rails code. On those grounds, I could see someone wanting to call Scenic.database.create_view.

We could promote refresh to the generic adapter module as well. It could noop by default.

There is no "generic adapter module". There is a collection of schema statements we monkey patch into ActiveRecord schema statements that we document. I don't think it would make any sense for refresh_materialized_view to be a schema statement, but right now that's our only place for public api documentation.

I get where you are coming from. I like how very small the the public interface for this gem is. I just think that if I were a user I'd want to know some of the stuff that's hiding out in the postgres documentation. For instance, information about materialized view indexes being reapplied automatically, or database version support for materialized views.

For what it's worth, I don't think we've made a breaking change to the adapter ever (except the 'bug' where we supported only postgres 9.3 for a bit). Certainly not in this lated 3 months or so of development.

from scenic.

I'm currently working on a project that has a view that depends on another view, so I've been thinking about view creation and destruction recently. @derekprior do these changes just make Scenic's create_view, update_view, and destroy_view accessible outside of migrations?

from scenic.

FWIW, I think it's fair to make someone building cascading views jump through some extra hoops. It's an architecture smell.

from scenic.

They're already available outside of migrations. There's nothing to stop you from doing Scenic.database.create_view from anywhere. The methods on the adapter itself are public in the ruby sense but are not documented as public and therefore we can change them on a whim.

I'm proposing that we document them in the publicly available documentation because I think the docs we've already written (but not exposed) contain interesting information that would be useful to users. Like this:

• https://github.com/thoughtbot/scenic/blob/master/lib/scenic/adapters/postgres.rb#L52-L65
• https://github.com/thoughtbot/scenic/blob/master/lib/scenic/adapters/postgres.rb#L94-L106

from scenic.

And this: https://github.com/thoughtbot/scenic/blob/master/lib/scenic/adapters/postgres.rb#L130-L146

from scenic.

Closed in favor of #123

from scenic.