Feature description
In experimenting with the new fixture feature, I noticed that:
- There is no way to tell in the committed migration that a fixture was used.
- When uncommitting a migration that used a fixture, the fixture contents are inlined back into the migration
It seems like it would be useful to include some comments that indicate it came from a fixture. Maybe something like
current.sql:
select 'foo';
--! include functions/hello.sql
fixtures/functions/hello.sql
create or replace function public.hello() returns text as $$
select 'Hello, world!';
$$ language sql;
translating into 000001.sql
--! Previous: -
--! Hash: sha1:a62f7d32702b880992ad9e2a7753dd977267064a
select 'foo';
--! Included: functions/hello.sql
create or replace function public.hello() returns text as $$
select 'Hello, world!';
$$ language sql;
--! EndIncluded
I'm not deeply familiar with naming conventions of the !-- comments, so of course feel free to suggest better names
Motivating example
I was messing around with the new fixture features and was curious how it handled unmigrations. Admittedly, unmigrating is not a common thing I do, so it's not a huge deal. But as I thought about it, I came to think that even including a comment in the final migration that the statements came from a fixture is a positive addition to help future readers of migrations understand how the migrations were written.
Breaking changes
It seems like a change like this would only affect migrations going forward, so hopefully no breaking changes for anyone who is already on the 2.0 release candidates.
Supporting development
I:
Feature description
In experimenting with the new fixture feature, I noticed that:
It seems like it would be useful to include some comments that indicate it came from a fixture. Maybe something like
current.sql:
fixtures/functions/hello.sql
translating into 000001.sql
I'm not deeply familiar with naming conventions of the !-- comments, so of course feel free to suggest better names
Motivating example
I was messing around with the new fixture features and was curious how it handled unmigrations. Admittedly, unmigrating is not a common thing I do, so it's not a huge deal. But as I thought about it, I came to think that even including a comment in the final migration that the statements came from a fixture is a positive addition to help future readers of migrations understand how the migrations were written.
Breaking changes
It seems like a change like this would only affect migrations going forward, so hopefully no breaking changes for anyone who is already on the 2.0 release candidates.
Supporting development
I: