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
I used the seeding feature for the first time today and found that it is useless for Postgres. My SQL seed file will create all the schemas and tables as needed, however Phinx cannot even run a seed file without first calling AdapterInterface::createSchemaTable().
In my case, $schemaTableName=phinx.log, which is a schema called phinx with a table called log. Except, however, the schema phinx doesn't exist yet. Perhaps in MySQL land, in which most of you seem to live, it is reasonable to assume the schema would already exist, since MySQL makes the mistake of conflating database and schema, but in any other reasonable DBMS this assumption makes it impossible to seed the database unless we manually create schemas separately beforehand, which is to say, we need to seed before we seed, which makes no sense.
To be clear, I am disputing whether it makes any logical sense for Phinx to force creation of its migration table at seed time. I opine it does not, because seeding should make no assumptions about the current state of the database, particularly as its own schema is not used at all for the seeding process, as clearly noted in the documentation:
⚠️ Unlike with migrations, Phinx does not keep track of which seed classes have been run.
It does not keep track of seed classes, ergo it should not be setting up schema and tables to track migrations at seed time.
It seems to me there is a fundamentally flawed assumption that we should always, on every connection, be checking whether the Phinx schema exists. This seems like a really hacky way to create the Phinx table. The Phinx table should be created once and once only per database and there should be a formal way to do so, instead of implicitly doing it on every connection regardless of why that connection is being created.
To be absolutely clear, this seed migration will never work when migration_table is set to phinx.log:
I used the seeding feature for the first time today and found that it is useless for Postgres. My SQL seed file will create all the schemas and tables as needed, however Phinx cannot even run a seed file without first calling
AdapterInterface::createSchemaTable()
.phinx/src/Phinx/Db/Adapter/PdoAdapter.php
Line 133 in 2922b17
In my case,
$schemaTableName=phinx.log
, which is a schema called phinx with a table called log. Except, however, the schema phinx doesn't exist yet. Perhaps in MySQL land, in which most of you seem to live, it is reasonable to assume the schema would already exist, since MySQL makes the mistake of conflating database and schema, but in any other reasonable DBMS this assumption makes it impossible to seed the database unless we manually create schemas separately beforehand, which is to say, we need to seed before we seed, which makes no sense.To be clear, I am disputing whether it makes any logical sense for Phinx to force creation of its migration table at seed time. I opine it does not, because seeding should make no assumptions about the current state of the database, particularly as its own schema is not used at all for the seeding process, as clearly noted in the documentation:
It does not keep track of seed classes, ergo it should not be setting up schema and tables to track migrations at seed time.
It seems to me there is a fundamentally flawed assumption that we should always, on every connection, be checking whether the Phinx schema exists. This seems like a really hacky way to create the Phinx table. The Phinx table should be created once and once only per database and there should be a formal way to do so, instead of implicitly doing it on every connection regardless of why that connection is being created.
To be absolutely clear, this seed migration will never work when
migration_table
is set tophinx.log
:Running this seed file on a fresh Postgres database gives:
The text was updated successfully, but these errors were encountered: