Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[drift_dev]: schema_steps does not work for Postgres databases #3261

Open
exaby73 opened this issue Oct 3, 2024 · 2 comments
Open

[drift_dev]: schema_steps does not work for Postgres databases #3261

exaby73 opened this issue Oct 3, 2024 · 2 comments

Comments

@exaby73
Copy link

exaby73 commented Oct 3, 2024

I have the following table users defined like:

class Users extends Table with CreatedAt {
  UuidColumn get id => customType(PgTypes.uuid).withDefault(genRandomUuid())();

  TextColumn get name => text()();

  TextColumn get email => text().unique()();

  TextColumn get password => text()();

  @override
  Set<Column> get primaryKey => {id};
}

Notice I am using getRandomUuid() as the default. The CreatedAt mixin has the following:

mixin CreatedAt on Table {
  TimestampColumn get createdAt =>
      customType(PgTypes.timestampWithTimezone).withDefault(now())();
}

With this column, I am using now() as the default.

Running dart run drift_dev schema steps after doing a dump generates the versions file, without the import for drift_postgres. Adding the import manually (which is a workaround I am willing to automate), the values of now() and getRandomUuid() do not adhere to the DriftAny type in the generated code. Here is a snippet of the generated code for a users table from the previous schema version which fails:

i1.GeneratedColumn<i1.DriftAny> _column_0(String aliasedName) =>
    i1.GeneratedColumn<i1.DriftAny>('created_at', aliasedName, false,
        type: i1.DriftSqlType.any, defaultValue: now()); // <- Error here
i1.GeneratedColumn<i1.DriftAny> _column_1(String aliasedName) =>
    i1.GeneratedColumn<i1.DriftAny>('id', aliasedName, false,
        type: i1.DriftSqlType.any, defaultValue: genRandomUuid()); // <- Error here
i1.GeneratedColumn<String> _column_2(String aliasedName) =>
    i1.GeneratedColumn<String>('name', aliasedName, false,
        type: i1.DriftSqlType.string);
i1.GeneratedColumn<String> _column_3(String aliasedName) =>
    i1.GeneratedColumn<String>('email', aliasedName, false,
        type: i1.DriftSqlType.string);
i1.GeneratedColumn<String> _column_4(String aliasedName) =>
    i1.GeneratedColumn<String>('password', aliasedName, false,
        type: i1.DriftSqlType.string);

Let me know if there's any more information I can provide

Environment information:

drift: 2.20.3
drift_dev: 2.20.3
drift_postgres: 1.3.0
postgres: 3.4.0

build.yaml

targets:
  drift:
    auto_apply_builders: false
    builders:
      drift_dev:analyzer:
        enabled: true
        options: &options
          store_date_time_values_as_text: true
          named_parameters: true
          sql:
            dialect: postgres
      drift_dev:modular:
        enabled: true
        options: *options

  $default:
    dependencies:
      - ":drift"
    builders:
      drift_dev:
        enabled: false
@simolus3
Copy link
Owner

simolus3 commented Oct 3, 2024

Thanks for the report! These issues sound fixable and I'll take a look, but you'll probably won't get far with step-by-step migrations on postgres:

  1. The schema verification code used in tests does not support postgres (neither as a dialect nor can we reliably obtain the actual schema at runtime).
  2. Step-by-step migrations run a user_version pragma after each step, which will not work on postgres.
  3. In fact, most drift migration APIs (outside of creating tables) won't work on postgres. Migrator.alterTable certainly won't, for instance.

We should still fix this for users who are using custom types to share a database between postgres and sqlite3, but the migration tooling for Postgres is just fairly incomplete at the moment. At the moment, I suggest extracting your drift schema into a separate file (drift dev schema export!) and then use a dedicated migration tool for Postgres.

@exaby73
Copy link
Author

exaby73 commented Oct 3, 2024

Thanks for the information :) I appreciate it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants