Unsafe table names generate invalid ts file

[anup-the-magic]

If we have table names that, on the db side, need to be quoted, the generated type names end up being invalid typescript names. Not certain what the ideal end result should be, but just figured this was worth documenting.

for instance:

CREATE TABLE "has spaces" (id int not null);
CREATE TABLE "has-dashes" (id int not null);

Produces

export namespace has spacesFields {
  export type id = number;
}
export interface has spaces {
  id: has spacesFields.id;
}
export namespace has-dashesFields {
  export type id = number;
}
export interface has-dashes {
  id: has-dashes.id;
}

[vitaly-t]

@xiamx, @crispmark Guys, the bug should state that finding invalid names isn't handled correctly. And the fix should be: Whenever finding such names that cannot be mapped into TypeScript names, report as error, explaining the issue, and not generate invalid code.

[vitaly-t]

@xiamx @crispmark
Is this library still supported though, I wonder?

[HoldYourWaffle]

@vitaly-t #81 (comment)

[abenhamdine]

I aim to maintain this project but I will have to fork the project first, I can't and don't want to operate under SweetIQ name.

[HoldYourWaffle]

I think it'd be great if someone stepped up to maintain a fork of this project. It's very useful and has a lot of potential, but there are a few things that make this "original" version not usable for my needs (#105 for example, I've also been working on an implementation of enums for "lookup tables").
I'm not able to maintain such a fork myself right now, but if you (@abenhamdine) would be able to I'll be happy to contribute.

[xiamx]

Ideally a new fork of this project would start from someone who uses it regularly, perhaps using it as part of a production setup. I started a fork last year to try to merge some good PRs in https://github.com/xiamx/schemats/ but just didn't have the time to work on it.

[abenhamdine]

Ideally a new fork of this project would start from someone who uses it regularly, perhaps using it as part of a production setup. I started a fork last year to try to merge some good PRs in xiamx/schemats but just didn't have the time to work on it.

Ok great, I will start from there.

[HoldYourWaffle]

I think @evdhiggins made a fork (with useful changes) too (including copying my camel caseing PR 😉 ). (Link for convenience)

[evdhiggins]

I'd also be happy to contribute to a new maintained fork in the future.

(@HoldYourWaffle -- your CC PR was a great start to some really helpful things that we've been able to do internally, so I suppose I owe you a great deal of thanks!)

[HoldYourWaffle]

@evdhiggins Glad I could be of help!
Just out of curiosity, what are the differences between my implementation and yours?

[xiamx]

In that case, why not create a schemats organization and fork it from there. There was a steady growth of users (whether it's from CI or not), so there's some merits to having it become maintained again.

I still have access to the npm registry so transition for the users should be smooth

[vitaly-t]

Good to see some life here 😄

[HoldYourWaffle]

It might be a good idea to collect all useful PR's and forks currently existant that could be merged into the new "active" fork.

[evdhiggins]

@HoldYourWaffle -- Regarding the implementation differences: I think that the main difference is that the camel case options were columns and tables instead of columns and types (the fork doesn't really support the column types separately in the same way).

[vitaly-t]

Whatever the next version/branch, it must be in strict mode. Many projects will no longer accept public contributions that do not compile in strict mode, and rightfully so.

For example, the latest pg-promise that I maintain, gives you 100% strict mode compliance now. So it can be updated and used safely here.

[abenhamdine]

For clarity, I started #107 to continue the discussion about a new active project. Don't hesitate to comment it.