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
After #357 is merged, the filemanager query logic could be transitioned away from using .sql files and sqlx for migrations, and instead using sea-orm for migrations. Note, sqlx and sea-orm can coexist together for the time being because sea-orm uses sqlx.
The text was updated successfully, but these errors were encountered:
After looking into this, I don't know if using sea-orm for migrations is the best. It seems a bit verbose, and for table definitions, raw SQL could be enough. For example, the object table definition would be something like:
usecrate::migrations::m0001_create_table::ObjectGroup::{Attributes,ObjectId};use sea_orm::DeriveIden;use sea_orm_migration::prelude::{DeriveMigrationName,Table};use sea_orm_migration::schema::{json_binary, uuid};use sea_orm_migration::{async_trait,DbErr,MigrationTrait,SchemaManager};/// The object_group table.#[derive(DeriveIden)]enumObjectGroup{Table,ObjectId,Attributes,}/// The migration struct used to implement `MigrationTrait`.#[derive(DeriveMigrationName)]pubstructMigration;#[async_trait::async_trait]implMigrationTraitforMigration{asyncfnup(&self,manager:&SchemaManager) -> Result<(),DbErr>{
manager
.create_table(Table::create().table(ObjectGroup::Table).col(uuid(ObjectId).primary_key()).col(json_binary(Attributes)).to_owned(),).await}asyncfndown(&self,manager:&SchemaManager) -> Result<(),DbErr>{
manager
.drop_table(Table::drop().table(ObjectGroup::Table).to_owned()).await}}
vs the following in plain SQL:
-- An general object table common across all storage types.createtableobject (
-- The unique id for this object group.
object_id uuid not nullprimary key,
-- Attributes for a group of objects.
attributes jsonb default null
);
The sea-orm example does have a down script, which could be useful - does that outweigh the extra code/verbosity? I'm open to either approach. We could also keep this issue paused for a bit because we can always transition later if we want.
Note, I think using sea-orm for queries is definitely better than raw SQL, because it's much more concise. This issue doesn't affect transitioning to using sea-orm in general.
After #357 is merged, the filemanager query logic could be transitioned away from using
.sql
files andsqlx
for migrations, and instead usingsea-orm
for migrations. Note,sqlx
andsea-orm
can coexist together for the time being because sea-orm uses sqlx.The text was updated successfully, but these errors were encountered: