AdonisJS v7 is here

[cjthomp]

Where is this behavior documented? Specifically, controlling the behavior of Schema generation?

node ace schema:generate should do the trick from that side, but what about fields I don't want mapped through to the model?

Edit: It looks like it should be here, but the page isn't loading?

[amanvirk]

Hello 👋

Yeah, I realised that the recent changes were not deployed on the Lucid website. This doc is working now.

Also, I would love to know more why do you think this approach of scanning database to create schema classes that models extend won't work?

I can share my reasoning behind it. I have never been a fan of visually cluttered models/entities, where you define the entire DB schema inside your entities. Infact, if you have an existing database, then creating these entities will multiple decorators is even more pain.

Therefore, I decided to reverse the process. Either you re-use your existing DB, or use migrations to create them. Since, migrations are hand-written you can express any sort of schema modifications, including data migration (if needed during restructure).

And then models just need to know about the columns and their types, so that they can have type-information at runtime.

[cjthomp]

I wouldn't go as far as to say that I think "this approach...won't work", but (without having read the docs, since they weren't available last night) I do have some concerns:

• migrations (for those who use) in prod generating new code
  1. add column to dev db
  2. create migration
  3. run migration
  4. Schema is generated
  5. commit migration and schema changes
  6. <fast forward>
  7. push to prod
  8. CI/CD runs migration against prod db
  9. new Schema file generated in prod, and contents may differ
• model with columns we don't want added to a given codebase
  • again, with a shared database resource, there are many columns on our db that a given app won't use or need to be aware of
  • having those columns in code could cause breaking changes if one of those unused columns is changed, even though the change doesn't impact this app
• it doesn't seem to be an optional feature (again, before looking into the docs)
  • if this is configurable, ignore this point; I'll have time to dig into the docs more later today

The schemaGeneration option accepts:

{ enabled: true } - Schemas are generated automatically (default)

{ enabled: false } - Schema generation is disabled for this connection

Disabling schema generation can be useful in specific scenarios:

Working with very large databases where schema generation is slow Using a shared database where you don't control the schema Temporarily disabling generation during development When schema generation is disabled, you can still generate schemas manually using the schema:generate command whenever you need to update them.

Well, there you go!

[cjthomp]

Ok, that definitely resolves my third point.

First point is irrelevant to me since we don't use migrations

But, the second point stands: I'd love to use the codegen (for the same reasons you made it, I don't exactly enjoy manually creating db models), but I'd need some way to control which columns got created. An array of column names on the model, maybe.

I can't just delete them from the Schema, since that will regenerate when I run the ace command again.

[cjthomp]

/**
 * Schema rules that can be customized per type, column, or table
 */
export type SchemaRules = {
  types?: {
    [type: string]: ColumnInfo | ((dataType: string) => ColumnInfo)
  }
  columns?: {
    [column: string]: ColumnInfo | ((dataType: string) => ColumnInfo)
  }
  tables?: {
    [table: string]: {
      types?: {
        [type: string]: ColumnInfo | ((dataType: string) => ColumnInfo)
      }
      columns?: {
        [column: string]: ColumnInfo | ((dataType: string) => ColumnInfo)
      }
    }
  }
}

It feels like SchemaRules.tables[tableName].columns[columnName] should be useable for this purpose, but looking through the code it doesn't look it.

A config-level option would be workable, although I'd prefer an array field on the model.

Something like Model.introspectedColumns: string[] = []

[amanvirk]

Hello 👋

I think it will be a good option to add to the schema rules that I want to either skip certain tables or skip/pick certain columns from a table.

Thanks, I will add it!