Introduce versions formatter for the schema dumper#53797
Conversation
|
I love this idea! IMO the comment is a bit confusing unless you already know about the algorithm. |
15dfdcb to
081880b
Compare
|
Agree, changed to print only a comment at the top of the list. |
|
I'm not too sure how I feel about that. I'm sympathetic to the desire of reducing conflicts, but it feels weird to have these versions ordered in a seemingly arbitrary fashion. I'll try to seek a second opinion. |
|
Another alternative is the ability for users to provide a custom proc, which will be used for sorting these versions. |
|
|
||
| schema_info = ActiveRecord::Base.lease_connection.dump_schema_information | ||
| expected = <<~STR | ||
| -- Versions are sorted by reverse representations of numbers (abc -> cba) in descending order. |
There was a problem hiding this comment.
| -- Versions are sorted by reverse representations of numbers (abc -> cba) in descending order. | |
| -- Versions are sorted by reverse representations of numbers (20241225000000 -> 00000052214202) in descending order. |
|
I'm sympathetic to the problem but I really don't like this solution. Reversing the strings is just confusing and I can imagine both beginners and seasoned Rails devs getting stuck on this. If we merge this we'll get endless bug reports and complaints. |
|
Wdyt about my alternative idea
so people can be able to configure their custom logic? And we preserve the original implementation by default. |
I'm skeptical. I am going to monkey patch this into our codebase, and see if anyone (~50 devs) notices or asks. |
|
^ A week later nobody has asked about it (as far as I'm aware) and we're definitely seeing less merge conflicts. |
|
This was the reactions when the order was reversed: #44363 |
|
If this PR is implemented in alternative way, for example, providing users a proc to configure, for example |
@eileencodes @matthewd thoughts? I'm not against it, but it's yet another super obscure config. |
I can be convinced to offer some way to customize this, but I wonder if rather than just exposing a sort proc, we might not as well refactor def insert_versions_sql
self.class.schema_version_inserter.generate(pool.schema_migration)
endThen you get the flexibility to order however you want, but also include some comments, and even fetch the list of versions differently. |
081880b to
6c18dc7
Compare
INSERT statements in structure.sql dumps|
Updated with the suggestion for a separate class. |
6c18dc7 to
7bdd0df
Compare
7bdd0df to
0cc1842
Compare
| to change the default behavior: | ||
|
|
||
| ```ruby | ||
| class CustomSchemaVersionsFormatter |
There was a problem hiding this comment.
I've just tried this snippet and it's missing
private attr_reader :connection
def initialize(connection)
@connection = connection
end
Follow up to #44363 (cc @ghiculescu).
Previously, the versions were sorted in decreasing order and new added to the top of the list. Within large-enough teams, this can cause many merge conflicts near the top of this list. Within my company, we have lots of developers pushing lots of schema changes and half of the time someone merges a PR, lots of existing PRs now have conflicts with the master.
Now, the versions are sorted by their reverse representations (
20241201183002->20038110214202), in decreasing (can be increasing, does not matter, but to be consistent with the previous implementation) order. This will greatly reduce the likelihood of merge conflicts as now new versions can be inserted at any place in the existing list. I did a simple calculation and while before we had a likelihood of conflict within a list of, say 5 top elements (20%), now - within a whole list of 600+ items (0.1%).I also added a comment with reversed version representation for each version within dumped
structure.sqlfile for people to more easily solve the merge conflicts. But we can remove this and add a comment at the top of theINSERTdescribing the algorithm.For existing apps, there will be a large diff the next time
structure.sqlis generated.