Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve DatabaseCleaner Configuration API #546

Open
botandrose opened this issue May 1, 2018 · 1 comment
Open

Improve DatabaseCleaner Configuration API #546

botandrose opened this issue May 1, 2018 · 1 comment

Comments

@botandrose
Copy link
Contributor

botandrose commented May 1, 2018

Way back in 2012, 016d66c changed the ::[] API to act as both a command and query, in a decision based on pragmatism. At the time, @bmabey noted his dislike for this, and his desire to deprecate it. Now that we're talking about a v2.0 release, I think this is a good time to talk about improving this situation in a backwards-incompatible way.

I have an alternative API proposal that I've been exploring, which splits the ::[] method into ::[] for queries, and ::[]= for commands. Complex configuration is also simplified to a hash, or array of hashes:

# simple config
DatabaseCleaner[:active_record].strategy = :truncation
# complex config
DatabaseCleaner[:active_record] = {
  connection: :test,
  strategy: :truncation,
  except: %w[goats donkeys],
}
# complex multiple db config
DatabaseCleaner[:active_record] = [
  { connection: :test, strategy: :truncation, except: %w[goats donkeys] },
  { connection: :test_2, strategy: :transaction },
]

I have been working on a document exploring what this API change would look like for DatabaseCleaner's many different use-cases, ranging from the most simplistic all the way up to very complex multiple ORM and database configuration, and this seems like this could work well, while also simplifying internals. I haven't prototyped it yet to confirm, but I even think its possible to add API this to the 1.x series in a backwards-compatible way, which would ease the v2.0 transition.

However, I want to get some feedback on this general direction before going too deep down the rabbit hole. Perhaps there is already an alternative API that you folks have in mind? Or perhaps we don't want to change the API at all at this point? But if this API looks promising, I'll post the document, and we can go from there!

@botandrose botandrose mentioned this issue May 2, 2018
@botandrose
Copy link
Contributor Author

In the interest of getting v2.0 out the door, I'm going to defer this to some later v2.x release, with potential for removing the old interface in v3.x

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant