[TS] Fix useTable casing issues

[coolreader18]

Description of Changes

Fixes #3807. Not sure what the best way to model this in the API is (another argument to t.row()?), but it does work.

Expected complexity level and risk

1

Testing

[cloutiertyler]

@coolreader18 I think this is the way we should model it:

export default new __t.row(
  {
    id: __t.u32().primaryKey(),
    userId: __t.identity("user_id"),
    name: __t.string(),
    get location() {
      return Point;
    },
  },
);

or

export default new __t.row(
  {
    id: __t.u32().primaryKey(),
    userId: __t.identity.name("user_id"),
    name: __t.string(),
    get location() {
      return Point;
    },
  },
);

perhaps. That is similar to what DrizzleORM does: https://orm.drizzle.team/docs/sql-schema-declaration#shape-your-data-schema.

If you think you can swing that quickly, I'd like to make that change. I'd rather do something like that because it will be how we will implement a more general "column alias" feature, but if we need to rush this we could do what you're doing.

I'm a little hesitant to expose RowBuilder though since we're not even sure that that should exist, to your point.

[coolreader18]

Having it just on ColumnBuilder for now is reasonable, I guess. The issue is that we'd also want to support having alternate names for product type fields as well.

[cloutiertyler]

Having it just on ColumnBuilder for now is reasonable, I guess. The issue is that we'd also want to support having alternate names for product type fields as well.

Agreed, although we're moving in that direction and I think this would be easy enough to extend to that as well.

[coolreader18]

Mmm, I don't know if easy is the right word - it would involve making a new category of TypeBuilders (like, NamedU8Builder etc) that can be used as product fields but not in an array or option

[cloutiertyler]

This now LGTM!