amacneil / amacneil/dbmate

Session variables are leaking across migration scripts

Aberta
#216 7 comentários 1 reação 0 responsáveis Ver no GitHub
bug feature request
Linguagem predominante
Go
Estrelas
7.4k
Forks
380
Merge médio
1d 16h
PRs com merge (30d)
2

Descrição

### Problem

When a user defines a session variable, the expectation is that the variable will be scoped to the current migration script. However, the migrations seem to reuse the same session, resulting in scope leaks from one migration script to the next. You can recreate this problem using the following migration scripts:

* migration_1
```
-- migrate:up
create table leak_demo_users (
name varchar(255) not null
);
select 'VALUE_LEAK1' into @leaky_var1;
set @leaky_var2='VALUE_LEAK2';

-- migrate:down
drop table leak_demo_users;
```

* migration_2
```
-- migrate:up
insert into
leak_demo_users
values
(@leaky_var1),
(@leaky_var2)
;

-- migrate:down
delete from leak_demo_users;

```
These migrations will succeed if you run them in sequence, resulting in the following table records, which is not expected behavior.
```
mysql> select * from leak_demo_users;
+-------------+
| name |
+-------------+
| VALUE_LEAK1 |
| VALUE_LEAK2 |
+-------------+
```
The expected behavior is for migration_2 to result in an error. However, if we perform a single rollback and run the migration again, then the correct behavior is encountered (see below). This is because now migration_2 is running in isolation without the benefit of the variable leak from migration_1.
```
Error: Error 1048: Column 'name' cannot be null
```
### Problem Location
Here's location of the problematic function:
https://github.com/amacneil/dbmate/blob/cdbbdd65ea149ff9acf4342a136139adbbf33115/pkg/dbmate/db.go#L317

### Solutions
A few ways to fix this include:
* Close and reopen the database connection between each migration script
* Provide a new CLI command `step` which will run only a single migration script and exit

The second option might be the most backwards compatible approach, since some folks may be dependent (perhaps unwittingly?) on this behavior.

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.