Why is the syntax double in field names?

[josvanos]

Why is the syntax:

const users = pgTable('users', {
  id: serial('id').primaryKey(),
  fullName: text('full_name'),
  phone: varchar('phone', { length: 256 }),
});

And not:

const users = pgTable('users', {
  id: serial().primaryKey(),
  fullName: text(),
  phone: varchar ({ length: 256 }),
});

[AndriiSherman]

Object keys are responsible for determining which variables you will use in your code and which keys will be inferred from the schema. Names inside type functions are responsible for the names in the database. It's useful when you want to have camelCase in your code and snake_case in the database, or even name them differently

Just a small example

const users = pgTable('users', {
  id: serial('id').primaryKey(),
  codeName: text('full_name'),
  userPhone: varchar('phone', { length: 256 }),
});

But we have plans to make the string inside the column function an optional field and just use the key for the database name

[josvanos]

Thanks for the reply! This really confused me as it feels double (redundant), and more error prone (typo's). Especially, If you migrate from a schema.prisma file, your code does not consist a lot of such mappings (database name -> orm name). I am looking forward to the column being optional!

[cr101]

@josvanos Even in Prisma I always use the @@map attribute to explicitly set the table and field names like so:

model User {
  id            Int      @id @default(autoincrement()) @map("user_id")
  firstName     String   @map("first_name")
  lastName      String   @map("last_name")
  ....
}

Conventions streamline onboarding. When you have an experienced developer joining the team, following industry standards allow that developer to onboard seamlessly into your team. If you have a junior joining having conventions helps them not only learn, but have confidence contributing.

Most database experts would recommend: Database Naming Standards and Database Naming Convention

[josvanos]

@cr101 you are right. My apologies for bringing a personal experience as an argument/fact. However, I still think a more explicit naming of it would be beneficial, such as:

const users = pgTable('users', {
  id:  pg.field("id").serial().primaryKey(),
  codeName: pg.text(),
  userPhone: pg.varchar(256) // like how you would write it in SQL. https://www.postgresql.org/docs/current/datatype-character.html
});

Note that I strongly believe that mapping should be possible, however in such case I would rather have explicit and like orms such as Prisma optional. Maybe, because the docs really use the same key twice a lot, it felt more double. But after seeing your case I also understand your point of view!

[Senbonzakura1234]

It's useful if you need to connect between a database and a service that have different naming convention. Saying you need to connect to an already established database that has columns named like foo_bar, but your current micro service already has camelCase naming convention fooBar and you don't want to make an exception.
Changing a schema field in a service is much easier than changing a name of a database column.
Though i agree this field should be optional instead of being required.

[MariuzM]

Does Drizzle have an utilitu that converts incoming data from user_id to userId like its in schema? I have case now where i get data not via Drizzle but hole app is based on userId instead of user_id. Right now i just manually created new object and re-assigned