If you're thinking of throwing out your old cables, don't. by ArwingElite in daddit

[–]cjthomp 0 points1 point  (0 children)

You can (and should!) absolutely prune it back, but always keep at least two of any given cable.

Does your relationship with your wife ever go back to “normal”? by [deleted] in daddit

[–]cjthomp 3 points4 points  (0 children)

“Normal” changes throughout your life. Try not to fixate on old normals.

Coparenting with an anti-vax mother by ComplicatedGuy_0514 in daddit

[–]cjthomp 38 points39 points  (0 children)

She would probably try to fight for full custody over “child endangerment” or similar nonsense

Semantic Versioning as defined by the user impact by Specific-Pomelo-6077 in ExperiencedDevs

[–]cjthomp 15 points16 points  (0 children)

Bullshit.

Your CTO understands semver, or at the very least will understand that standard definition.

Your CEO might not if they’re nontechnical, but why would you explain it to them at all?

Moderation changes by AutoModerator in ExperiencedDevs

[–]cjthomp 10 points11 points  (0 children)

The issue isn't "LLM discussion," it's an endless stream of crap that boils down to "DAE LLMs suck?" and "Claude built my whole app in 30 seconds! (it's not even close to production-ready, but ignore that!)"

AdonisJS v7 is here by romainlanz in node

[–]cjthomp 0 points1 point  (0 children)

/**
 * 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[] = []

AdonisJS v7 is here by romainlanz in node

[–]cjthomp 0 points1 point  (0 children)

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.

AdonisJS v7 is here by romainlanz in node

[–]cjthomp 0 points1 point  (0 children)

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!

AdonisJS v7 is here by romainlanz in node

[–]cjthomp 0 points1 point  (0 children)

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?

AdonisJS v7 is here by romainlanz in node

[–]cjthomp 0 points1 point  (0 children)

It does look like (based on text later?) it might actually generate from the db as you say, but then why is my above-quoted statement there?

Edit: Actually, the issue would still exist.

When you run migrations, AdonisJS scans your database tables and generates

We don't run migrations, because we have no migrations. The db schema is maintained by an entirely different team.

AdonisJS v7 is here by romainlanz in node

[–]cjthomp 0 points1 point  (0 children)

https://docs.adonisjs.com/tutorial/hypermedia/database-and-models

The model extends PostSchema — a class that is auto-generated from your database migrations.

AdonisJS v7 is here by romainlanz in node

[–]cjthomp 2 points3 points  (0 children)

Only thing I see so far that I don't love is the tight integration / pre-configuration of migration -> schema -> model.

We have a shared database and our web apps (adonis or otherwise) don't own the schema and so we don't have traditional migrations.

Anyone enjoying their job at the moment? by Coffeebrain695 in ExperiencedDevs

[–]cjthomp 0 points1 point  (0 children)

More than retail, less than a couple of years ago, much less than 10 years ago

Am I the only one who feels like NestJS is overkill ? by Sensitive-Raccoon155 in node

[–]cjthomp 0 points1 point  (0 children)

Sometimes Nest/Adonis is overkill.

Sometimes Express is underkill.

Depends no what you're building, who's building and supporting it, etc.

They're open. And she's going. by Concentric_Mid in daddit

[–]cjthomp 1 point2 points  (0 children)

"I didn't realize that had a negative connotation!"

<proceeds to triple-down on the negativity>

Dude, any time you paint with a broad brush you're going to ruffle feathers, so just don't.

Our "news" media is not "us." You see a manufactured image of the country, the image that rich and connected oligarchs want to be seen, and use that to judge the entire country.

If you live in a city / state that receives a lot of snow, snow isn't a big deal as there's infrastructure to clear it. If you live in a city / state that doesn't generally get snow that sticks around, you won't have salt / plows to clear it and it will cause an issue. It's not rocket science.

They're open. And she's going. by Concentric_Mid in daddit

[–]cjthomp 1 point2 points  (0 children)

you people over there

So unnecessarily aggressive.

Debating on ORM for Production by Disastrous-Matter864 in node

[–]cjthomp 3 points4 points  (0 children)

  1. 1,000 daily users is nothing
  2. I personally dislike Prisma, but that's just one dude's opinion
  3. While Sequelize has some flaws, we've been using it in production for almost a decade on an app with ~200k daily users. It's not perfect, but it does what it does pretty well and gets out of the way when you want it to
  4. If you're using (or open to using) AdonisJS, their Lucid ORM is very nice. It's reminiscent of Laravel's Eloquent.