We need DEFINE LAYER

[dkr8toha]

It would be nice to see a new type of DEFINE LAYER to manage defaults for any kind of definition, e.g. when creating a namespace, database, table or field. In simplicity i was looking for something like this:

DEFINE LAYER emailAddress AS FIELD FLEXIBLE DEFAULT "test" PERMISSIONS FULL;
DEFINE FIELD mail ON Person USE emailAdress;

When upgrading the layer emailAddress with a new version the defined field will not change but can be updated manually:

DEFINE LAYER emailAddress VERSION 2 DEFAULT "test2";
APPLY LAYER emailAddress VERSION 2 ON Person.mail;
-- or simply by using the latest version:
APPLY LAYER emailAddress LATEST ON Person.mail;

Or using auto upgrade mechanism by default:

DEFINE FIELD mail ON Person USE emailAdress LATEST PERMISSIONS FULL;

Another main idea is to create defaults for namespaces like automatically create or upgrade databases/tables and so on:

DEFINE LAYER animalDefault AS DATABASE ...;
DEFINE LAYER defaultDatabases AS QUERY
  (DEFINE DATABASE colors), (DEFINE DATABASE animal USE animalDefault);
DEFINE NAMESPACE foobar USE defaultDatabases LATEST;

Is somthing planned or on the todo-list of this great project?

[dkr8toha]

It would be also really cool to switch them:

-- one may define a premium database if the customer has not already fulfilled their registration
DEFINE NAMESPACE premiumCustomerXXX USE premiumDatabaseNotFulfilled LATEST

-- and if defined change the namespace layer to the real premium database
DEFINE NAMESPACE premiumCustomerXXX USE premiumDatabase LATEST;

-- where the premiumDatabase layer may extend the not fullfilled one (and other layers)
-- one may write queries when a layer is applied, and so on ...
DEFINE LAYER canLogin AS FIELD ...
DEFINE LAYER paymentPlan AS DATABASE ...
DEFINE LAYER premiumDatabase USE premiumDatabaseNotFulfilled, canLogin WITH (DEFAULT false), paymentPlan WITH QUERY (
  INSERT INTO ...
)
DEFINE NAMESPACE premiumCustomerXXX USE premiumDatabase LATEST;

And we also need some kind of Upgrade instructions (EVENTS) to manage the data while an definition upgrade is made:

DEFINE LAYER defaultDatabasesPremium VERSION 2
  (UPDATE person SET important = true),
  -- when the process starts
  ON BEGIN (
  ),
  -- when a definition (namespace,database,field,...) is going to be replaced
  ON UPGRADING (
  ),
  -- when the replacement is done (change data after replacement)
  ON UPGRADED (
  ),
  -- when the process ends
  ON END (
  );
  -- when the process fails
  ON ERROR (
    ...
  )

Or maybe/also something like this:

APPLY LAYER defaultDatabasesPremium TO namespace WITH QUERY (
  ...
)

Layer updates should be performed in an transaction and if failed they will automatically rollback.

Imagine you have thousands of namespaces and all databases need to be in sync, you will have no chance without such a system, or am i wrong?

[adminy]

are you suggesting aspecting in DB 🫨 (because I imagine the security side of this is not going to make it easy to implement).
I think that's what events do at the moment:

DEFINE EVENT eventname ON TABLE sometable
WHEN $event = "CREATE" THEN {
   -- this is an atomic operation and it will fail adding to the original table if something fails inside the event
};

at least partially.

[man-of-fox]

I thought about a nearly equal thing as something like templating repeating definitions in this post. But in this Post it seems to go deeper to layer everything, not only tables, like in my post. But in addition to this post it should be useful to combine Layers to build modular definitions.
I don't think it's a runtime thing which should be handled within events. It is a define time part to make definitions of big databases readable, modular and simpler.
For Example:
Database with lots of tables, where most tables needs createt_at (timestamp) and created_by (author) fields which can be filled by default value.
Or a template for catalog tables, which all have fields like name, description, position or something like that.

I tried to write a function which defines fields with dynamic table name, but it seems not to be possible to provide a dynamic table name like:

DEFINE FUNCTION fn::CREATION_FIELDS($table: string) {
  DEFINE FIELD created_at ON $table
    TYPE datetime
    DEFAULT time::now()
    PERMISSIONS FOR select FULL FOR create, update NONE
}

This could be an alternative way but with DEFINE LAYER or DEFINE TEMPLATE style it would be a more user/db-admin friendlier way, I think. It feels a little bit like class and interface definitions in object orientated programming languages.