Decorator to auto inject columns

[enmanuelmag]

Add the ability to define decorator (@DecoratorName) to specify default columns for auto inject, example:

Decorator date_columns {
  created_at  timestamp [not null, default: `now()`]
  updated_at  timestamp [not null, default: `now()`]
  deleted_at  timestamp
}

@date_columns
Table table_1 {
  id integer [pk, unique, increment]
  name varchar(64) [not null]
}

//The final result of table_1 looks like:
Table table_1 {
  id integer [pk, unique, increment]
  name varchar(64) [not null]
  created_at  timestamp [not null, default: `now()`]
  updated_at  timestamp [not null, default: `now()`]
  deleted_at  timestamp
}

If this is approved I would like to work on this 😊

[Rackaras]

Nice one mate, pretty good.

[Jesucristhorr]

🔬

[RWOverdijk]

Yes, I like this. I'd like to add though that it would be nice to expand on this a bit and make it more than just base definitions. Allow decorators to be handled outside of the built in features. This enables us to make plugins like policies for postgres for example.

This means instead of @decorator you'd use something else for base table info, like Abstract. Could look like:

Abstract date_columns {
  created_at  timestamp [not null, default: `now()`]
  updated_at  timestamp [not null, default: `now()`]
  deleted_at  timestamp
}

@policy {
  name: account_managers
  to: table_2
  using: 'manager = current_user'
}
@abstract(date_columns)
Table table_1 [rls: force] {
  id integer [pk, unique, increment]
  name varchar(64) [not null]
}

Anything inside of athe decorator can just be passed in as arguments to whatever decorator handler registered it. So you'd get a pojo. Abstract would be a new primitive that allows for the same thing, but parses the contents as a definition.

I also added rls as a table setting, because I think arbitrary settings should also be allowed and handled through plugins.

[NQPhuc]

Hello, @RWOverdijk. Can you explain more detail about your syntax and what effect it should have from your example code snippet?

Looking at the example, I'm still not sure what the difference is between @abstract(something) and @Policy{...}, and which settings/columns should be applied to table_1.

Also, it would be very nice if you could demonstrate a specific use-case where your syntax will benefit DBML users.

[RWOverdijk]

@NQPhuc I missed this, sorry.

The difference between @abstract and @policy would be that:

• @abstract is a little bit like a trait in some programming languages. It's base definition that gets applied to the table. This helps dbml users by allowing them to basically define a base table once and reuse it across multiple tables. This is its own decorator because it isn't just key/value. It's a list of column definitions.
• @policy is just a generic decorator that could be anything, allowing dbml users to extend/make plugins for dbml. In my case for example I could make @policy, or @rls. I could even make @partition to define partitioning. In a nutshell, the syntax @anything gets stored as metadata on the table and can be retrieved by plugins. I could use it to add additional sql when generating the schema. This could also work the other way around, and allow for creating the dbml based on the sql schema. I don't see dbdiagram.io adding RLS, policy or partitioning support. But it is something I use, a lot. So for me at least having custom tooling is very important.

I would maybe even go further and allow some form of default decorators to be applied to all tables in a schema. This itself could be a generic decorator, for example @global which would allow people to make a plugin that applies whatever is in there to all tables before generating the sql schema starts.

Allowing generic decorators with any key/value inside makes dbml more flexible. Right now there is no way to add metadata to tables, and we have to manually add stuff to the generated sql code.

To add: a more formal implementation of this could also work. That way you can keep dbml schema validation and autocomplete. But the important part is to allow people to add metadata.

[NQPhuc]

Hi all,

Thank you for the valuable inputs. To consolidate the feedback on DBML table reusability, we've posted a new proposal for a new syntax called TableFragment.

You can find the details and continue the discussion here: #700