Comments (5)
Hi @toydestroyer,
This is a great idea! I'm so happy your team is leveraging the gem so deep that you create custom checkers.
I like the feature, but I have a question.
Would we support adding such through database_consistency.yml
, or would it be better to have it with a ruby configuration?
DatabaseConsistency.configure do
add_checkers CustomChecker1, CustomChecker2
add_writers SimpleWriter1, AutofixWriter1
end
How would those - rubocop-performance
or ./lib/....some_custom_cop.rb
look like?
Something like this?
class CustomChecker < DatabaseConsistency::Checkers::ColumnChecker
...
end
DatabaseConsistency.add_checker(CustomChecker)
P.S. Do you have any suggestions for problem one? strong_migrations
is fantastic, but I don't know how to adapt to that, so we don't need to duplicate their code.
from database_consistency.
Would we support adding such through database_consistency.yml, or would it be better to have it with a ruby configuration?
I don't have a strong opinion here. Yaml is neater, and this is what rubocop is doing (here's how).
Rubocop rules are self-contained. You do checks, reporting, and autocorrections in the same class (example).
Rubocop does have a registry and register new rules upon inheritance.
But in the case of DatabaseConsistency gem, we need to register the checker, simple writer, error slug (?), and sometimes autofix.
I'll think more about the topic this week. For now, I want to share my findings and thoughts and hear your thoughts as well @djezzzl.
P.S. Do you have any suggestions for problem one?
strong_migrations
is fantastic, but I don't know how to adapt to that, so we don't need to duplicate their code.
This definitely should be a separate gem that overrides autofix writers. We don't need to duplicate their code, we just need to generate migration files that don't violate strong_migrrations' recommendations.
from database_consistency.
Yaml is neater, and this is what rubocop is doing
I don't see any issues with doing the same.
register new rules upon inheritance.
Excellent, we can do the same
we need to register the checker, simple writer, error slug (?), and sometimes auto fix.
We may have some logic to ensure that everything (or minimal requirement) is provided, but my main idea was to avoid being bound to any of the writers (TODO/Simple/Autofix, etc.). But I understand if there is none provided, how would the consumer know something needs to be added to make it fully work? We may start with good guidance or additional "code" that validates custom classes if they have everything/something to be written.
I'll think more about the topic this week.
Please share once you foresee some vision; I like the idea and want to help you and your team leverage the gem as much as possible.
This definitely should be a separate gem that overrides autofix writers. We don't need to duplicate their code
Agree; let's let strong_migrations
do its job.
we just need to generate migration files that don't violate strong_migrrations' recommendations.
Now, I'm kind of confused. How can we write good migrations without "duplicating the strong_recommendations"? It would require us to maintain and support all recent changes, and I wonder if we should do this.
I agree that strong_migrations
is helpful. However, some projects don't need the gem's complexity, for example, when the zero downtime policy can be ignored. Therefore, we may emphasize and recommend using strong_migrations
somewhere (as a comment in generated migrations, maybe), but we shouldn't create complex migration initially.
What do you think, @toydestroyer?
from database_consistency.
Now, I'm kind of confused. How can we write good migrations without "duplicating the strong_recommendations"?
Sorry for the confusion, let me clarify. I meant there should be a gem called database_consistency-strong_migrations
that doesn't add any new checkers but only overwrites existing Autofix writers to comply with strong_migrations' recommendations.
It would require us to maintain and support all recent changes, and I wonder if we should do this.
You personally shouldn't do anything as long as database_consistency
provides an API to extend itself similarly to that some of the rubocop extensions are not maintained by the rubocop core team.
Also, maintenance shouldn't be a big issue because there are not many changes in how you write safe migrations. For example, last time there was a change in how you safely add NOT NULL
constraint in PostgreSQL 12. So the reasons to update the database_consistency-strong_migrations
gem would be:
database_consistency
adds new autofixstrong_migrations
changes its recommendations.
However, some projects don't need the gem's complexity
In that case, they just use pure database_consistency
without database_consistency-strong_migrations
extension. Similarly, people who don't use RSpec just don't include rubocop-rspec
in their rubocop config
from database_consistency.
We may have some logic to ensure that everything (or minimal requirement) is provided, but my main idea was to avoid being bound to any of the writers (TODO/Simple/Autofix, etc.). But I understand if there is none provided, how would the consumer know something needs to be added to make it fully work? We may start with good guidance or additional "code" that validates custom classes if they have everything/something to be written.
I have a feeling that "simple writer" should be replaced by the concept of "formatter". This is something RSpec does. Take a look at the progress and documentation formatters for example.
The idea is that the checker should report all the information anyone might need to render the result. And if you think about it, TodoWriter
is already like this because, unlike SimpleWriter
, it knows how to generate a todo item for any checker.
In order to make this happen, we need to move the template
from a checker-specific simple writer to the checker itself, remove all checker-specific writers, and make SimpleWriter
read the template
from a checker.
Once again, this opens an opportunity for extensions (rspec_junit_formatter as an example of such an extension for RSpec). Like, what if I want to generate the report in an HTML file? I just do DatabaseConsistency::Writers::HTMLWriter < BaseWriter
in my project and then run
bundle exec database_consistency --writer HTMLWriter
How does this sound to you @djezzzl?
from database_consistency.
Related Issues (20)
- `EnumTypeChecker` is complaining about `enum` column HOT 4
- Misleading commandline help message HOT 3
- `ColumnPresenceChecker` and polymorphic association HOT 1
- `ColumnPresenceChecker`, `belongs_to `associations, and `optional`, `required` options HOT 3
- Checker that makes sure that enum type is used to store ActiveRecord's enums HOT 14
- EnumValueChecker doesn't work with ActiveRecord below 7 HOT 4
- Add ability to ignore certain namespaces HOT 5
- Does this gem recognize a find on a column without index? HOT 4
- database_consistency -f generates duplicate migrations HOT 3
- Inconsistency found in NullConstaintChecker HOT 3
- [Feature] Check constraint checker HOT 2
- Excluding Database Connections to Non Primary Databases Including sqlserver HOT 2
- Ensure that generated todo files are created with consistent ordering HOT 6
- MissingIndexChecker violation on polymorphic association HOT 3
- ForeignKeyCascadeChecker default mapping HOT 3
- "undefined method `null' for nil:NilClass" in column_presence_checker.rb:54 HOT 7
- UniqueIndexChecker and postgresql partial indexes HOT 1
- Checker for implicit_order_column for table with uuid as primary key HOT 8
- False-positive when index columns are defined as a string and not array HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from database_consistency.