scenic-views / scenic

Versioned database views for Rails
https://thoughtbot.com/blog/announcing-scenic--versioned-database-views-for-rails
MIT License
3.45k stars 224 forks source link

Centralise and expose configurable db views folder #380

Open hlascelles opened 1 year ago

hlascelles commented 1 year ago

We run an app that needs two migrations folders (one each for two very different DB setups).

So our project folder looks like:

app
db
  migrate
  views
db_2
  migrate
  views
...

We'd like to use scenic for the other database too.

We've implemented it, and everything works great except the path to the views dir.

That is described concretely in two places in scenic:

https://github.com/scenic-views/scenic/blob/3600a485797fe1dbf30d152cc60b6d2318f04c48/lib/generators/scenic/view/view_generator.rb#L83

https://github.com/scenic-views/scenic/blob/b1544dc517349400a21f9c6cac36114daeb75ce6/lib/scenic/definition.rb#L22

Would you be open to a PR that centralises the reference to that path, and exposes it as a configurable value?

Thanks!

gap777 commented 1 year ago

We also have this need, as we're building a modular monolith via packwerk, and each pack has it's own db/migrate directory. Can you reply to @hlascelles as to whether you would consider such a PR?

@derekprior what about PR https://github.com/scenic-views/scenic/pull/287?

That would address the issue here.

hlascelles commented 1 year ago

@derekprior what do you think of this proposal?

hlascelles commented 7 months ago

Would you be open to a PR for it?

gap777 commented 7 months ago

@hlascelles would you open a PR? I'd like to see how you solved it. We may have to just fork this repo if its no longer maintained.

derekprior commented 6 months ago

@gap777: This library is actively, if sporadically, maintained by @calebhearth and I. We take a conservative approach to its maintenance, which has served us very well for over 8 years and more 23 million downloads. We implement features and fix bugs that we have confidence and familiarity with. We've occasionally strayed from this strategy and have often regretted that decision as we're left to support issues that arise in functionality we aren't experienced with.

A perusal of the issue tracker will show that there are some themes to some of the remaining issues which are helpfully denoted with labels. It's not that we don't want to fix these issues, it's that we want to fix them in a way we feel confident we can support for another 8 years.

In the case of this issue with https://github.com/scenic-views/scenic/labels/view-paths, I'm hesitant to accept any pull request until we have #402 sorted. I do not want to implement a fix here only to discover it conflicts with, is superseded by, or diverges from patterns present in the official multi database support from Rails. I understand you may not want to wait for us to figure out #402. If you peruse the label I linked earlier, you'll see a couple of PRs open with various implementations that may suit your needs.