Support generating database-scoped enumerations#20
Open
beverloo wants to merge 2 commits intolorefnon:mainfrom
Open
Support generating database-scoped enumerations#20beverloo wants to merge 2 commits intolorefnon:mainfrom
beverloo wants to merge 2 commits intolorefnon:mainfrom
Conversation
There are two changes part of this commit, after which the entire test suite passes correctly. 1) Using the `force` flag when calling `fs.rm`, which is necessary because Windows throws an ENOENT filesystem error (and thus exception) when removing non-existing files and directories. The test suite carefully removes the `generated` directory before each test. 2) Always importing from `path` (rather than `path/poxix`), and correcting the path separators in the two places it matters. In order to be able to use `String.replaceAll()` I updated the `target` in `tsconfig.json` to es2021, as it seems fairly unlikely that anyone running this script isn't able to run that. An alternative would be to use a regular expression based replace.
This commit introduces the ability to generate types for enumerations defined as types in the database, as is supported by e.g. PostgreSQL. (& already in test.sql). It's presently disabled by default. Generated files for enumerations export two things: 1) A constant, such as `kGenre`, which is an object that allows code to refer to specific values part of the enumeration, enabling cross referencing in editors. 2) A type, such as `Genre`, which is a union of all valid values. The generated type is added to a list of generated field types and thus doesn't need any additional new handling. For compatibility with existing usage, the list of generated field types is considered after all other defined field types. Tests are added to confirm generation, the "include" and "exclude" functionality and the ability to customise naming for generated enumerations, separately for the generated constant and type.
Owner
|
Hi @beverloo Thank you for your interest in this library. All of these look like great additions and I am happy to incorporate them. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello! I'm wondering if you'd consider this as a contribution before I put more time into it 😃
In short, this PR contains two commits, one that makes it possible to run the
ts-sql-codegentests on a Windows machine, and the second which generates files for enumerations that are database-scoped (such as supported by PostgreSQL).tbls output:
Generated files export two things:
kGenre, which is an object that allows code to refer to specific values part of the enumeration, enabling cross referencing in editors:kGenre.fantasyinstead of"fantasy"(although both are valid),Genre, which is a union of all valid values.The generated type is added to a list of generated field types and thus doesn't need any additional new handling. For compatibility with existing usage, the list of generated field types is considered after all other defined field types.
Tests are added to confirm generation, the "include" and "exclude" functionality and the ability to customise naming for generated enumerations, separately for the generated constant and type.
There's quite a lot of space for opinions and code cleanups here, particularly as there's some debate about how to represent enumerations in TypeScript w/o using
enum, so I wanted to limit the scope and ask for your opinion before proceeding further. Specifically:generator.tsthat refer toTable, but may now also contain anEnum(e.g.TableKindand method names)? It's quite noisy, so I'd create a separate PR for that.Genretype mapping from all existing tests? (Except maybe a new precedence test.) This also is quite noisy, so not done in this PR.tbls output: