Redesign table config

[romeerez]

The current way of defining tables is weird, to say the least.

You can't simply tell TS that books belong to authors and authors have many books, because TS is confused with the type recursion (book -> author -> book -> author -> ...).

The limitation can be only bypassed by using class syntax.

I've been looking for a workaround to make it look nicer for years, and finally I got it!

I have a working proof-of-concept, so this should work out well, here is the spoiler of the future table syntax:

const BookTable = defineTable("book")
  .columns((t) => ({
    id: t.identity().primaryKey(),
    title: t.string(),
    authorId: t.integer().references(() => AuthorTable("id")),
  }))
  .relations((t) => ({
    author: t.belongsTo({
      from: ["authorId"],
      to: () => AuthorTable("id"),
    }),
  }));

const AuthorTable = defineTable("author")
  .columns((t) => ({
    id: t.identity().primaryKey(),
    name: t.string(),
  }))
  .relations((t) => ({
    books: t.hasMany({
      from: ["id"],
      to: () => BookTable("id"),
    }),
  }));

[mordechaim]

Starting to look like drizzle... I hope the existing config will be backward compatible, or at least, move to Orchid 2.0

[IlyaSemenov]

Since columns are an essential, inseparable part of the table, shouldn't they be rather passed as the second argument of defineTable? Is there any point in defineTable() without .columns() other than (quite arguable) clarity of code?

Example:

const BookTable = defineTable("book", t => ({
  id: t.identity().primaryKey(),
  title: t.string(),
  authorId: t.integer().references(() => AuthorTable("id")),
})).relations(t => ({
  author: t.belongsTo({
    from: ["authorId"],
    to: () => AuthorTable("id"),
  }),
}))

[romeerez]

Starting to look like drizzle... I hope the existing config will be backward compatible, or at least, move to Orchid 2.0

As for compatibility - sure, will be kept (not forever).

I'm was happy to get around TS limitations for that syntax, but seems like you're not really appreciating it, why not?

• it's notably more compact and neat
• class was confusing because it makes you think it's an OOP entity/model, while it's just a table config
• annoying readonly for table is required for proper TS inference of string literal
• some other option, softDelete I guess, also requires readonly, so some props are readonly and others aren't just to satisfy TS limitation
• columns = this.setColumns - so annoying to say that columns = setColumns. columns = is already setting columns, why to repeat this fact with setColumns.
• in some environments, users have to add override because TS is complaining that table and columns were already defined in the BaseTable, while it's not required on my machine.

columns passed as the second argument

Good idea!

I guess sure, let columns be the second argument, as long as they don't depend on any of possible table options.

There are some possible options such as softDelete, noPrimaryKey, maybe some others, and if the t arg somehow depends on those options, columns must to follow the options. But that's not the case, so softDelete, noPrimaryKey and future parameters can be defined after columns (by chaining a method call).