Type safe ORM

[muchirajunior]

This is not an issue but i was looking for feature like drizzle orm where we can use dart syntax to query or update data using this package. Would really make it very easy to handle and ensure safety and no typing bugs.

regards

[simolus3]

There's typed_sql and Drift (disclosure: that's my package) and many more packages which provide type-safe access and can use this package underneath.

[muchirajunior]

@simolus3 they all seem to work with sqlite is there one that works without codegen and more into postgres. i like using written model with from json and tojson

[EchoEllet]

This is not an issue but i was looking for feature like drizzle orm where we can use dart syntax to query or update data using this package. Would really make it very easy to handle and ensure safety and no typing bugs.

You can write raw SQL while adding type safety on top without an ORM layer or changing the underline SQL code. I would consider sqlc (example Dart plugin). It is not supported on Dart out-of-the-box so you may need to search for language support.

In my case I wrote a simple code generator which introspects a real database and generate Dart row data classes (details). It is not seamless when working with JOINs, and you can still write invalid SQL statements. I would either write integration tests that verify the behavior against a real database or consider Sqlc.

Example with my Dart code generator

For example:

CREATE TYPE audit_action AS ENUM (
  'create',
  'update',
  'delete'
);

CREATE TABLE audit_logs (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id UUID NOT NULL,
  action audit_action NOT NULL,
  old_value JSONB NOT NULL,
  new_value JSONB NOT NULL,
  ip_address INET,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Generates:

/// Generated enum from PostgreSQL enum `audit_action`.
enum AuditActionPgEnum {
  create('create'),
  update('update'),
  delete('delete');

  const AuditActionPgEnum(this.text);

  final String text;

  static AuditActionPgEnum fromText(String value) {
    return values.firstWhere(
      (e) => e.text == value,
      orElse: () => throw ArgumentError('Unknown enum value: $value'),
    );
  }
}

/// Generated row mapping for the `audit_logs` table.
/// Represents a full-row result where all columns are expected to be present.
///
/// This model assumes SELECT queries include all columns defined in the table (i.e., `SELECT * FROM audit_logs`).
/// Partial SELECT projections are **not** supported and may result in runtime errors.
@immutable
final class AuditLogsRow {
  const AuditLogsRow({...});
  factory AuditLogsRow.fromMap(Map<String, Object?> map) => AuditLogsRow(...);

  final int id;
  final String userId;

  /// Requires casting to TEXT when selecting this column (i..e, SELECT action::text)
  final String action;
  final JsonMap oldValue;
  final JsonMap newValue;

  /// Requires casting to TEXT when selecting this column (i..e, SELECT ip_address::text)
  final String? ipAddress;
  final DateTime createdAt;
}

Sqlc is more future-proof and promising than writing a custom code generator, and makes it easy to migrate from any programming language, database driver. ORMs has tradeoffs and sometimes hidden ones.
Since the SQL statements are written in a separate file, you can use a linter or validate it using Sqlc compiler (you may find more details in this YouTube video).

Overall I think this package is a database driver, or low-level compared to ORMs, and should not add ORM support directly within. You may build an ORM on top of this, like Serverpod framework did.