diff --git a/docs/404.html b/docs/404.html index 4756f5d8..f40e8a5b 100644 --- a/docs/404.html +++ b/docs/404.html @@ -16,7 +16,7 @@
- + \ No newline at end of file diff --git a/docs/assets/configuring.md.KxuyCa7P.js b/docs/assets/configuring.md.DpFAmSwV.js similarity index 91% rename from docs/assets/configuring.md.KxuyCa7P.js rename to docs/assets/configuring.md.DpFAmSwV.js index 09762e76..e26defe7 100644 --- a/docs/assets/configuring.md.KxuyCa7P.js +++ b/docs/assets/configuring.md.DpFAmSwV.js @@ -127,10 +127,10 @@ import{_ as i,c as a,a0 as n,o as t}from"./chunks/framework.DkRJo9Vs.js";const o postRenderHooks?: PostRenderHook[]; importsExtension?: ".ts" | ".js" | ".mjs" | ".cjs"; -};

connection ​

The only required property in the config object is connection.

This is the database connection object. It follows the client constructor in pg. As you will typically want to run Kanel on your development machine, you probably want a simple localhost connection as in the example above.

schemas ​

The schemas property can be an array of strings. This will be used as the list of schema names to include when generating types. If omitted, all the non-system schemas found in the database will be processed.

typeFilter ​

The typeFilter property allows you to choose which types (be that tables, views, enums, or whatever else) to include.

getMetadata, getPropertyMetadata and generateIdentifierType ​

If you really want to customize the behavior of Kanel, you can provide values for the getMetaData, the getPropertyMetadata and/or the generateIdentifierType functions.

propertySortFunction ​

The propertySortFunction can be supplied if you want to customize how the properties in types should be sorted. The default behavior is to put primary keys at the top and otherwise follow the ordinal order as is specified in the database.

enumStyle ​

The enumStyle can be either type or enum (default). Postgres enums will then be turned into either string unions or Typescript enums.

This, if you have an enum Fruit consisting of the values apples, oranges and bananas, you will get this type with enumStyle === 'type':

typescript
type Fruit = "apples" | "oranges" | "bananas";

..or, with enumStyle === 'enum':

typescript
enum Fruit {
+};

connection ​

The only required property in the config object is connection.

This is the database connection object. It follows the client constructor in pg. As you will typically want to run Kanel on your development machine, you probably want a simple localhost connection as in the example above.

The connection parameter can either be an object like shown above or a connection string. If the connection string starts with "file:" the specified path is opened using pglite. For example, when providing file:my/pglite/db/folder, the folder 'my/pglite/db/folder' is opened using pglite.

schemas ​

The schemas property can be an array of strings. This will be used as the list of schema names to include when generating types. If omitted, all the non-system schemas found in the database will be processed.

typeFilter ​

The typeFilter property allows you to choose which types (be that tables, views, enums, or whatever else) to include.

getMetadata, getPropertyMetadata and generateIdentifierType ​

If you really want to customize the behavior of Kanel, you can provide values for the getMetaData, the getPropertyMetadata and/or the generateIdentifierType functions.

propertySortFunction ​

The propertySortFunction can be supplied if you want to customize how the properties in types should be sorted. The default behavior is to put primary keys at the top and otherwise follow the ordinal order as is specified in the database.

enumStyle ​

The enumStyle can be either type or enum (default). Postgres enums will then be turned into either string unions or Typescript enums.

This, if you have an enum Fruit consisting of the values apples, oranges and bananas, you will get this type with enumStyle === 'type':

typescript
type Fruit = "apples" | "oranges" | "bananas";

..or, with enumStyle === 'enum':

typescript
enum Fruit {
   apples = "apples",
   oranges = "oranges",
   bananas = "bananas",
 }

outputPath ​

The outputPath specifies the root for the output files. The default implementation of getMetadata will place files in \${outputPath}/\${schemaName}/\${typeName}.ts.

preDeleteOutputFolder ​

If you set preDeleteOutputFolder to true, Kanel will delete all contents in the folder before writing types. This is recommended as it will make sure you don't have old model files of no-longer-existing database entities sitting around. Obviously it means that you shouldn't mix in any manually written code in that same folder though.

customTypeMap ​

The customTypeMap property can be set if you want to specify what a given type should map to. It's a record of a postgres typename to a Typescript type. The key is qualified with schema name, which for built-in types means that they should be prefixed with pg_catalog. So for instance if you want to map float8 to number (as opposed to the default string), you would set it like this:

typescript
{
   'pg_catalog.float8': 'number'
-}

resolveViews ​

If you set resolveViews to true, Kanel will attempt to give you better types for views. If a view returns, say, a column called account_id that represents a foreign key in the original table, we would like the resulting type to be AccountId or whatever we call our identifier types. Similarly, we would like to mark it as nullable only if the "source" column is nullable. Postgres will per default not give us these data about views, so Kanel attempts to infer them by parsing the SQL that defines the view. Obviously, this non-trivial and there are situations where it fails so use with slight caution.

preRenderHooks ​

The preRenderHooks property can be set if you want to supply one or more hooks that will run before the render step. At this point, Kanel has gathered a record of file paths and corresponding Declaration arrays. A declaration is an abstract bit of Typescript like an interface or type definition.

See the preRenderHooks section for more info.

postRenderHooks ​

If you need to do something more brute-force like, you might prefer to create one or more postRenderHooks, which will be called with a filename and an array of strings which are the raw contents, just before the file is written.

See the postRenderHooks section for more info.

importsExtension ​

To use a different file extension for project file import references, set importsExtension to .ts, .js, .mjs, or .cjs.

If no value is set, no extension will be appended.

`,44)]))}const g=i(e,[["render",h]]);export{o as __pageData,g as default}; +}

resolveViews ​

If you set resolveViews to true, Kanel will attempt to give you better types for views. If a view returns, say, a column called account_id that represents a foreign key in the original table, we would like the resulting type to be AccountId or whatever we call our identifier types. Similarly, we would like to mark it as nullable only if the "source" column is nullable. Postgres will per default not give us these data about views, so Kanel attempts to infer them by parsing the SQL that defines the view. Obviously, this non-trivial and there are situations where it fails so use with slight caution.

preRenderHooks ​

The preRenderHooks property can be set if you want to supply one or more hooks that will run before the render step. At this point, Kanel has gathered a record of file paths and corresponding Declaration arrays. A declaration is an abstract bit of Typescript like an interface or type definition.

See the preRenderHooks section for more info.

postRenderHooks ​

If you need to do something more brute-force like, you might prefer to create one or more postRenderHooks, which will be called with a filename and an array of strings which are the raw contents, just before the file is written.

See the postRenderHooks section for more info.

importsExtension ​

To use a different file extension for project file import references, set importsExtension to .ts, .js, .mjs, or .cjs.

If no value is set, no extension will be appended.

`,45)]))}const g=i(e,[["render",h]]);export{o as __pageData,g as default}; diff --git a/docs/assets/configuring.md.KxuyCa7P.lean.js b/docs/assets/configuring.md.DpFAmSwV.lean.js similarity index 91% rename from docs/assets/configuring.md.KxuyCa7P.lean.js rename to docs/assets/configuring.md.DpFAmSwV.lean.js index 09762e76..e26defe7 100644 --- a/docs/assets/configuring.md.KxuyCa7P.lean.js +++ b/docs/assets/configuring.md.DpFAmSwV.lean.js @@ -127,10 +127,10 @@ import{_ as i,c as a,a0 as n,o as t}from"./chunks/framework.DkRJo9Vs.js";const o postRenderHooks?: PostRenderHook[]; importsExtension?: ".ts" | ".js" | ".mjs" | ".cjs"; -};

connection ​

The only required property in the config object is connection.

This is the database connection object. It follows the client constructor in pg. As you will typically want to run Kanel on your development machine, you probably want a simple localhost connection as in the example above.

schemas ​

The schemas property can be an array of strings. This will be used as the list of schema names to include when generating types. If omitted, all the non-system schemas found in the database will be processed.

typeFilter ​

The typeFilter property allows you to choose which types (be that tables, views, enums, or whatever else) to include.

getMetadata, getPropertyMetadata and generateIdentifierType ​

If you really want to customize the behavior of Kanel, you can provide values for the getMetaData, the getPropertyMetadata and/or the generateIdentifierType functions.

propertySortFunction ​

The propertySortFunction can be supplied if you want to customize how the properties in types should be sorted. The default behavior is to put primary keys at the top and otherwise follow the ordinal order as is specified in the database.

enumStyle ​

The enumStyle can be either type or enum (default). Postgres enums will then be turned into either string unions or Typescript enums.

This, if you have an enum Fruit consisting of the values apples, oranges and bananas, you will get this type with enumStyle === 'type':

typescript
type Fruit = "apples" | "oranges" | "bananas";

..or, with enumStyle === 'enum':

typescript
enum Fruit {
+};

connection ​

The only required property in the config object is connection.

This is the database connection object. It follows the client constructor in pg. As you will typically want to run Kanel on your development machine, you probably want a simple localhost connection as in the example above.

The connection parameter can either be an object like shown above or a connection string. If the connection string starts with "file:" the specified path is opened using pglite. For example, when providing file:my/pglite/db/folder, the folder 'my/pglite/db/folder' is opened using pglite.

schemas ​

The schemas property can be an array of strings. This will be used as the list of schema names to include when generating types. If omitted, all the non-system schemas found in the database will be processed.

typeFilter ​

The typeFilter property allows you to choose which types (be that tables, views, enums, or whatever else) to include.

getMetadata, getPropertyMetadata and generateIdentifierType ​

If you really want to customize the behavior of Kanel, you can provide values for the getMetaData, the getPropertyMetadata and/or the generateIdentifierType functions.

propertySortFunction ​

The propertySortFunction can be supplied if you want to customize how the properties in types should be sorted. The default behavior is to put primary keys at the top and otherwise follow the ordinal order as is specified in the database.

enumStyle ​

The enumStyle can be either type or enum (default). Postgres enums will then be turned into either string unions or Typescript enums.

This, if you have an enum Fruit consisting of the values apples, oranges and bananas, you will get this type with enumStyle === 'type':

typescript
type Fruit = "apples" | "oranges" | "bananas";

..or, with enumStyle === 'enum':

typescript
enum Fruit {
   apples = "apples",
   oranges = "oranges",
   bananas = "bananas",
 }

outputPath ​

The outputPath specifies the root for the output files. The default implementation of getMetadata will place files in \${outputPath}/\${schemaName}/\${typeName}.ts.

preDeleteOutputFolder ​

If you set preDeleteOutputFolder to true, Kanel will delete all contents in the folder before writing types. This is recommended as it will make sure you don't have old model files of no-longer-existing database entities sitting around. Obviously it means that you shouldn't mix in any manually written code in that same folder though.

customTypeMap ​

The customTypeMap property can be set if you want to specify what a given type should map to. It's a record of a postgres typename to a Typescript type. The key is qualified with schema name, which for built-in types means that they should be prefixed with pg_catalog. So for instance if you want to map float8 to number (as opposed to the default string), you would set it like this:

typescript
{
   'pg_catalog.float8': 'number'
-}

resolveViews ​

If you set resolveViews to true, Kanel will attempt to give you better types for views. If a view returns, say, a column called account_id that represents a foreign key in the original table, we would like the resulting type to be AccountId or whatever we call our identifier types. Similarly, we would like to mark it as nullable only if the "source" column is nullable. Postgres will per default not give us these data about views, so Kanel attempts to infer them by parsing the SQL that defines the view. Obviously, this non-trivial and there are situations where it fails so use with slight caution.

preRenderHooks ​

The preRenderHooks property can be set if you want to supply one or more hooks that will run before the render step. At this point, Kanel has gathered a record of file paths and corresponding Declaration arrays. A declaration is an abstract bit of Typescript like an interface or type definition.

See the preRenderHooks section for more info.

postRenderHooks ​

If you need to do something more brute-force like, you might prefer to create one or more postRenderHooks, which will be called with a filename and an array of strings which are the raw contents, just before the file is written.

See the postRenderHooks section for more info.

importsExtension ​

To use a different file extension for project file import references, set importsExtension to .ts, .js, .mjs, or .cjs.

If no value is set, no extension will be appended.

`,44)]))}const g=i(e,[["render",h]]);export{o as __pageData,g as default}; +}

resolveViews ​

If you set resolveViews to true, Kanel will attempt to give you better types for views. If a view returns, say, a column called account_id that represents a foreign key in the original table, we would like the resulting type to be AccountId or whatever we call our identifier types. Similarly, we would like to mark it as nullable only if the "source" column is nullable. Postgres will per default not give us these data about views, so Kanel attempts to infer them by parsing the SQL that defines the view. Obviously, this non-trivial and there are situations where it fails so use with slight caution.

preRenderHooks ​

The preRenderHooks property can be set if you want to supply one or more hooks that will run before the render step. At this point, Kanel has gathered a record of file paths and corresponding Declaration arrays. A declaration is an abstract bit of Typescript like an interface or type definition.

See the preRenderHooks section for more info.

postRenderHooks ​

If you need to do something more brute-force like, you might prefer to create one or more postRenderHooks, which will be called with a filename and an array of strings which are the raw contents, just before the file is written.

See the postRenderHooks section for more info.

importsExtension ​

To use a different file extension for project file import references, set importsExtension to .ts, .js, .mjs, or .cjs.

If no value is set, no extension will be appended.

`,45)]))}const g=i(e,[["render",h]]);export{o as __pageData,g as default}; diff --git a/docs/configuring.html b/docs/configuring.html index bb749e1e..1c57e222 100644 --- a/docs/configuring.html +++ b/docs/configuring.html @@ -13,7 +13,7 @@ - + @@ -147,14 +147,14 @@ postRenderHooks?: PostRenderHook[]; importsExtension?: ".ts" | ".js" | ".mjs" | ".cjs"; -};

connection ​

The only required property in the config object is connection.

This is the database connection object. It follows the client constructor in pg. As you will typically want to run Kanel on your development machine, you probably want a simple localhost connection as in the example above.

schemas ​

The schemas property can be an array of strings. This will be used as the list of schema names to include when generating types. If omitted, all the non-system schemas found in the database will be processed.

typeFilter ​

The typeFilter property allows you to choose which types (be that tables, views, enums, or whatever else) to include.

getMetadata, getPropertyMetadata and generateIdentifierType ​

If you really want to customize the behavior of Kanel, you can provide values for the getMetaData, the getPropertyMetadata and/or the generateIdentifierType functions.

propertySortFunction ​

The propertySortFunction can be supplied if you want to customize how the properties in types should be sorted. The default behavior is to put primary keys at the top and otherwise follow the ordinal order as is specified in the database.

enumStyle ​

The enumStyle can be either type or enum (default). Postgres enums will then be turned into either string unions or Typescript enums.

This, if you have an enum Fruit consisting of the values apples, oranges and bananas, you will get this type with enumStyle === 'type':

typescript
type Fruit = "apples" | "oranges" | "bananas";

..or, with enumStyle === 'enum':

typescript
enum Fruit {
+};

connection ​

The only required property in the config object is connection.

This is the database connection object. It follows the client constructor in pg. As you will typically want to run Kanel on your development machine, you probably want a simple localhost connection as in the example above.

The connection parameter can either be an object like shown above or a connection string. If the connection string starts with "file:" the specified path is opened using pglite. For example, when providing file:my/pglite/db/folder, the folder 'my/pglite/db/folder' is opened using pglite.

schemas ​

The schemas property can be an array of strings. This will be used as the list of schema names to include when generating types. If omitted, all the non-system schemas found in the database will be processed.

typeFilter ​

The typeFilter property allows you to choose which types (be that tables, views, enums, or whatever else) to include.

getMetadata, getPropertyMetadata and generateIdentifierType ​

If you really want to customize the behavior of Kanel, you can provide values for the getMetaData, the getPropertyMetadata and/or the generateIdentifierType functions.

propertySortFunction ​

The propertySortFunction can be supplied if you want to customize how the properties in types should be sorted. The default behavior is to put primary keys at the top and otherwise follow the ordinal order as is specified in the database.

enumStyle ​

The enumStyle can be either type or enum (default). Postgres enums will then be turned into either string unions or Typescript enums.

This, if you have an enum Fruit consisting of the values apples, oranges and bananas, you will get this type with enumStyle === 'type':

typescript
type Fruit = "apples" | "oranges" | "bananas";

..or, with enumStyle === 'enum':

typescript
enum Fruit {
   apples = "apples",
   oranges = "oranges",
   bananas = "bananas",
 }

outputPath ​

The outputPath specifies the root for the output files. The default implementation of getMetadata will place files in ${outputPath}/${schemaName}/${typeName}.ts.

preDeleteOutputFolder ​

If you set preDeleteOutputFolder to true, Kanel will delete all contents in the folder before writing types. This is recommended as it will make sure you don't have old model files of no-longer-existing database entities sitting around. Obviously it means that you shouldn't mix in any manually written code in that same folder though.

customTypeMap ​

The customTypeMap property can be set if you want to specify what a given type should map to. It's a record of a postgres typename to a Typescript type. The key is qualified with schema name, which for built-in types means that they should be prefixed with pg_catalog. So for instance if you want to map float8 to number (as opposed to the default string), you would set it like this:

typescript
{
   'pg_catalog.float8': 'number'
 }

resolveViews ​

If you set resolveViews to true, Kanel will attempt to give you better types for views. If a view returns, say, a column called account_id that represents a foreign key in the original table, we would like the resulting type to be AccountId or whatever we call our identifier types. Similarly, we would like to mark it as nullable only if the "source" column is nullable. Postgres will per default not give us these data about views, so Kanel attempts to infer them by parsing the SQL that defines the view. Obviously, this non-trivial and there are situations where it fails so use with slight caution.

preRenderHooks ​

The preRenderHooks property can be set if you want to supply one or more hooks that will run before the render step. At this point, Kanel has gathered a record of file paths and corresponding Declaration arrays. A declaration is an abstract bit of Typescript like an interface or type definition.

See the preRenderHooks section for more info.

postRenderHooks ​

If you need to do something more brute-force like, you might prefer to create one or more postRenderHooks, which will be called with a filename and an array of strings which are the raw contents, just before the file is written.

See the postRenderHooks section for more info.

importsExtension ​

To use a different file extension for project file import references, set importsExtension to .ts, .js, .mjs, or .cjs.

If no value is set, no extension will be appended.

- + \ No newline at end of file diff --git a/docs/dataTypes.html b/docs/dataTypes.html index f1cfcb8c..144bd2ac 100644 --- a/docs/dataTypes.html +++ b/docs/dataTypes.html @@ -54,7 +54,7 @@ ): string { return serialize(this as Range<Date>, prepareValue); };

Now, we can use the Range class in our queries, inserts and updates.

- + \ No newline at end of file diff --git a/docs/examples.html b/docs/examples.html index 213c42f2..f33d3f62 100644 --- a/docs/examples.html +++ b/docs/examples.html @@ -19,7 +19,7 @@
Kanel

Appearance

Examples ​

- + \ No newline at end of file diff --git a/docs/generateIdentifierType.html b/docs/generateIdentifierType.html index bd4ddb5b..d42b6b8d 100644 --- a/docs/generateIdentifierType.html +++ b/docs/generateIdentifierType.html @@ -53,7 +53,7 @@ comment: [`Identifier type for ${details.schemaName}.${details.name}`], }; }; - + \ No newline at end of file diff --git a/docs/getMetadata.html b/docs/getMetadata.html index bcf27e6f..40cdfff2 100644 --- a/docs/getMetadata.html +++ b/docs/getMetadata.html @@ -105,7 +105,7 @@ */ interface MemberAddress { // ...

You may want to use the incoming details.comment string here.

The path field tells Kanel where (i.e. in which file) to place the type. Note that this field should not include the .ts extension which is added automatically. The reason for this is that this field is also used for generating imports and those should not include extensions.

- + \ No newline at end of file diff --git a/docs/getPropertyMetadata.html b/docs/getPropertyMetadata.html index ba1429b5..b993c9cd 100644 --- a/docs/getPropertyMetadata.html +++ b/docs/getPropertyMetadata.html @@ -49,7 +49,7 @@ nullableOverride?: boolean; optionalOverride?: boolean; };

The name field will be the actual name of the property. The default implementation will pass the name through so it matches what you have in the database. As there is a convention for using snake_case in Postgres, this will break the Typescript convention of using camelCase for properties. If you want to, you could make your interfaces match the Typescript convention, though you will then need to do that conversion when you send and receive values from the database.

The comment array will be the comments that go above the property. It will be enclosed in JSDoc style comments: /** ... */, so you can use JSDoc syntax and tags to refine documentation.

The three *Override values can be set if you want to override the default resolution of whether this property should be nullable or optional, or if you want to override the base type itself.

- + \ No newline at end of file diff --git a/docs/getting-started.html b/docs/getting-started.html index 811f8e95..d75a346d 100644 --- a/docs/getting-started.html +++ b/docs/getting-started.html @@ -37,7 +37,7 @@ "pg_catalog.bpchar": "string", }, };

Once you have that, you can run Kanel without any parameters:

bash
$ npx kanel

The configuration section has details on how to configure Kanel.

- + \ No newline at end of file diff --git a/docs/hashmap.json b/docs/hashmap.json index 2c1b1099..af5ebab9 100644 --- a/docs/hashmap.json +++ b/docs/hashmap.json @@ -1 +1 @@ -{"configuring.md":"KxuyCa7P","datatypes.md":"Dz1mw1x3","examples.md":"n555mVZp","generateidentifiertype.md":"5xhHCAdk","getmetadata.md":"CrngRb4M","getpropertymetadata.md":"CfW_IJVa","getting-started.md":"C4_C--_e","index.md":"bMb3McTY","kanel-knex.md":"DneP1F-j","kanel-kysely.md":"DjJMRj-J","kanel-zod.md":"CtNKy1Of","migration.md":"CZS0bzTu","postrenderhooks.md":"dWDHViud","prerenderhooks.md":"DoD1TUf6","workflow.md":"Bg6DqO1L"} +{"configuring.md":"DpFAmSwV","datatypes.md":"Dz1mw1x3","examples.md":"n555mVZp","generateidentifiertype.md":"5xhHCAdk","getmetadata.md":"CrngRb4M","getpropertymetadata.md":"CfW_IJVa","getting-started.md":"C4_C--_e","index.md":"bMb3McTY","kanel-knex.md":"DneP1F-j","kanel-kysely.md":"DjJMRj-J","kanel-zod.md":"CtNKy1Of","migration.md":"CZS0bzTu","postrenderhooks.md":"dWDHViud","prerenderhooks.md":"DoD1TUf6","workflow.md":"Bg6DqO1L"} diff --git a/docs/index.html b/docs/index.html index 4ae66550..53c54308 100644 --- a/docs/index.html +++ b/docs/index.html @@ -100,7 +100,7 @@ country_id: countryId.optional(), last_update: z.date().optional(), }) as unknown as z.Schema<CityMutator>;

It does this by inspecting a live PostgreSQL database, sort of like a reverse object/relations mapper.

You check the generated code into your repository and work with it using Knex.js or similar.

The idea is introduced in this blog post.

If you want to learn about how I use this together with tRPC to create end-to-end type safety with PostgreSQL as the source of truth, check out my course on Newline:

Copyright © 2018 Kristian Dupont, licensed under the MIT License

Cinnamon

- + \ No newline at end of file diff --git a/docs/kanel-knex.html b/docs/kanel-knex.html index be032d9b..4fda0330 100644 --- a/docs/kanel-knex.html +++ b/docs/kanel-knex.html @@ -44,7 +44,7 @@ preRenderHooks: [generateMigrationCheck], }; - + \ No newline at end of file diff --git a/docs/kanel-kysely.html b/docs/kanel-kysely.html index 9a37fb8e..6b2aafad 100644 --- a/docs/kanel-kysely.html +++ b/docs/kanel-kysely.html @@ -65,7 +65,7 @@ typeFilter: kyselyTypeFilter, }; - + \ No newline at end of file diff --git a/docs/kanel-zod.html b/docs/kanel-zod.html index e1d5fd29..98a436d6 100644 --- a/docs/kanel-zod.html +++ b/docs/kanel-zod.html @@ -51,7 +51,7 @@ preRenderHooks: [generateZodSchemas, zodCamelCaseHook], }; - + \ No newline at end of file diff --git a/docs/migration.html b/docs/migration.html index 20dc0c58..be2a4a39 100644 --- a/docs/migration.html +++ b/docs/migration.html @@ -26,7 +26,7 @@ // Generate an index file with exports of everything preRenderHooks: [generateIndexFile], };

Nominators ​

The nominators have been replaced by getMetadata, getPropertyMetadata and generateIdentifierType. These functions can be configured to return a custom name, comment and other things to customize your output.

The hooks are more or less intact as postRenderHooks. Those take a path and an array of strings, allowing you to do crude processing if necessary. However, you will probably prefer to create preRenderHooks that operate on more abstract data models and allow you more flexibility.

Ignoring entities ​

The schema.ignore property has been replaced by one general typeFilter function which can filter out any table, view or other entity that you don't want to process.

If you used to have an ignore property like this:

ignore: [/^celery/, /^djcelery/],

you could replace it with this:

typeFilter: d => ![/^celery/, /^djcelery/].some((v) => v.test(d.name)),

customTypeMap ​

The customTypeMap has changed slightly as well. It should now be indexed by schemaName.typeName. For builtin types, this means you specify them as pg_catalog.float8 etc. Also, you no longer have to specify array types explicitly as these should be resolved using the same rules as non-array types.

External types ​

The externalTypesFolder has been removed. Kanel will now assume that all types that are referenced as a simple string are built-in Typescript types (like string, number, Record<>, etc.). If you want to refer to a type that you created in a different file or that exists in an external package, you need to reference it as a TypeImport. You can do that in tagged comments like this: @type(EmailString, "./models/types/EmailString", false, true) Email address -- this will import a type called EmailString from a file of the same name in the types folder. It will be imported as a named import.

- + \ No newline at end of file diff --git a/docs/postRenderHooks.html b/docs/postRenderHooks.html index f9678ff1..d055ef8b 100644 --- a/docs/postRenderHooks.html +++ b/docs/postRenderHooks.html @@ -23,7 +23,7 @@ lines: string[], instantiatedConfig: InstantiatedConfig, ) => Awaitable<string[]>;

For every file that is about to be written, this function will be called. The lines parameter is the raw strings that will comprise the file. You should return the entire array of lines that you want the file to contain.

The function receives the instantiated configuration (i.e. the settings as well as the extracted schemas) in case you need any information from there.

- + \ No newline at end of file diff --git a/docs/preRenderHooks.html b/docs/preRenderHooks.html index bb75405c..0fba9167 100644 --- a/docs/preRenderHooks.html +++ b/docs/preRenderHooks.html @@ -79,7 +79,7 @@ | EnumDeclaration | ConstantDeclaration | GenericDeclaration;

The function receives the instantiated configuration (i.e. the settings as well as the extracted schemas) in case you need any information from there.

- + \ No newline at end of file diff --git a/docs/workflow.html b/docs/workflow.html index ca7f31ea..310a4550 100644 --- a/docs/workflow.html +++ b/docs/workflow.html @@ -19,7 +19,7 @@
Kanel

Appearance

How to work with Kanel ​

Kanel is well suited for a workflow where you let the database schema drive the architecture of your application. It is easier if you have a mono-repo setup or at least have the code that relies on these types version controlled together with your migrations.

The recommended process making an architectural change is:

  1. Create a database migration using Knex or regular SQL.
  2. Run the migration on your local development database.
  3. Run Kanel on your dev database. It will create/update your type definitions.
  4. Review the new defintions and update your code to support the new architecture.
  5. When everything works, push and deploy the migration together with the updated type definitions and other changes.

Introduction to the idea is outlined here.

Linting ​

When using the database as the source of truth, you want to perform your linter checks on the structure of the database, i.e. the schema. For that, you can use schemalint which is a linter for Postgres schemas.

As for the generated code, it will contain a @generated tag which is a semi-standard that a number of tools respect. You can use eslint-plugin-ignore-generated to ignore these files.

- + \ No newline at end of file