schemats
schemats copied to clipboard
SweetIQ
Comments support?
How about retrieving comments for all tables + columns, and adding them as TypeScript comments? ;)
See:
FWIW, to retrieve comments with information schema statements :
SELECT
obj_description(format('%s.%s',isc.table_schema,isc.table_name)::regclass::oid, 'pg_class') as table_description,
pg_catalog.col_description(format('%s.%s',isc.table_schema,isc.table_name)::regclass::oid,isc.ordinal_position) as column_description
FROM
information_schema.columns isc
@abenhamdine the same code was shown from the first link that I provided, the answer given by user T.Z. there :wink:
There are several ways in fact.
@vitaly-t Ah yes, you're right : actually, I was reading a SO question about this, and I paste immediatly the code without having read your first link... which turned out to be the same link 😉
Otherwise, I still wonder if it exists a 'pure' information schema way to retrieve comments, without any specific pg function, as this module until now is still sql-generic.
I was thinking : it would be a good thing to add in the comments the true datatype of the database column, as the ts types are far more limited, and it can be useful to know the full SQL type.
Example : for a json column :
export namespace osm {
export namespace usersFields {
export type last_post = Object;
...
export interface users {
/** last post of the user (SQL type : jsonb) */
last_post: usersFields.last_post;
...
I was thinking : it would be a good thing to add in the comments the true datatype of the database column, as the ts types are far more limited, and it can be useful to know the full SQL type.
That's a nice idea, can be very useful.
In the same way, :
- it could be useful to have in the comments the default SQL value of the column, if it's different from null.
- if there's a check constraint, it could be interesting too to add it, as it provides information about the values allowed for the column.
Not necessary all that in the same PR.
For the foreseeable future, support to PostgreSQL exclusively will be fine.
- MySQL is less feature rich, and its lack of feature is often complemented by application tier ORMs.
- NodeJS is rarely seen used with MSSQL or Oracle, mainly because using them with C#/.Net and Java respectively offer a far better experience.
@jmealo do you intend to send PR for this ? If not, I can perhaps give it a try next week. Let me know if you have begun to tackle this.
@xiamx When people are going around hunting for tools like schemats to help them work with an unfamiliar database schema, it is likely they don't have control over the choice of database.
You have a point @masaeedu . With https://github.com/SweetIQ/schemats/pull/52, we adopted a structure that allows us to support other types of databases (they just need to implement a common interface).
Pull requests to support other databases (MSSQL, Sqlite (this one is difficult), etc) are very welcomed.
I think this was implemented by https://github.com/vaultdairy/schemats/commit/ed446b43c6708f7f27dac7b2c819df93f6b88951 and https://github.com/vaultdairy/schemats/commit/f50bd4a7be5218aa8bf08a0ca0e44c8828f6ca07.
@evdhiggins I noticed you've done some major changes in your fork (some of them I might use myself), are these changes compatible with the main repository?
@HoldYourWaffle -- Unfortunately, no. The fork now generates io-ts types instead of regular Typescript interfaces. While the output types can be used just as regular types, this change probably isn't something that most consumers of schemats would want.
