You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Logidze Version: 1.2.1 though this exists on 1.3.0
What did you do?
We use some CI tooling to ensure non-related schema changes are not being made during a pull request. This is done by checking out the commit off which a branch was based on main, the running rails db:prepare, then resetting using git reset --hard, then finally rails db:migrate and checking for any diffs. If diffs exist then we know changes made their way into the schema file that aren't applicable to the pull request being submitted.
This becomes difficult (perhaps more annoying than difficult) to manage with Logdize because the create_triggers are ordered by our local dev machines based on the id/age of the table for which the trigger belongs to. When running rails db:prepare, table age/ids match the alphabetical order of the tables since schema.rb is read top-to-bottom. This leads to a diff occurring in our CI process because in the local environment, the trigger position in schema.rb may not (and most likely won't) match alphabetical order.
To fully replicate, start with a new (or existing) rails app:
Create a model Zzz using a generator - run the migrations
Add logdize to the Zzz model via the generator - run the migrations
Create a model Aaa using a generator - run the migrations
Add logdize to the Aaa model via the generator - run the migrations
Note that at this point, schema.rb will show create_trigger on aaa is coming after the create_trigger for zzz
Commit these changes
Then run rails db:drop && rails db:prepare
Note that there are now changes compared to the previous commit
What did you expect to happen?
It would be nice to be able to configure the create_triggers dump to keep the triggers in alphabetical order.
What actually happened?
The text was updated successfully, but these errors were encountered:
Tell us about your environment
Ruby Version: 3.0
Rails Version: 7.1
PostgreSQL Version: 14.?
Logidze Version: 1.2.1 though this exists on 1.3.0
What did you do?
We use some CI tooling to ensure non-related schema changes are not being made during a pull request. This is done by checking out the commit off which a branch was based on
main
, the runningrails db:prepare
, then resetting usinggit reset --hard
, then finallyrails db:migrate
and checking for any diffs. If diffs exist then we know changes made their way into the schema file that aren't applicable to the pull request being submitted.This becomes difficult (perhaps more annoying than difficult) to manage with Logdize because the
create_triggers
are ordered by our local dev machines based on the id/age of the table for which the trigger belongs to. When runningrails db:prepare
, table age/ids match the alphabetical order of the tables sinceschema.rb
is read top-to-bottom. This leads to a diff occurring in our CI process because in the local environment, the trigger position in schema.rb may not (and most likely won't) match alphabetical order.To fully replicate, start with a new (or existing) rails app:
create_trigger
on aaa is coming after thecreate_trigger
for zzzrails db:drop && rails db:prepare
What did you expect to happen?
It would be nice to be able to configure the
create_triggers
dump to keep the triggers in alphabetical order.What actually happened?
The text was updated successfully, but these errors were encountered: