Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries • Hacker News Board

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#121

Post by gmac » Fri, Sep 04, 2020, 9:33 AM UTC

intellix wrote: post #96

gmac wrote: post #75

Earlier quoted context omitted.

My own TypeScript non-ORM, Zapatos, shares much of the same design philosophy (and indeed a sql`...` tagged template function): https://jawj.github.io/zapatos/ Previous discussion: https://news.ycombinator.com/item?id=23273543

thought this looked awesome when I saw it. Was waiting for a little more traction, my project to calm down and perhaps some GQL helpers to appear before jumping on board (not requesting them but just naturally picked up by the community)

Glad to hear it! Presumably GQL is GraphQL, which so far I have let completely pass me by. How would those helpers look, roughly?

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#122

Post by mqus » Fri, Sep 04, 2020, 9:47 AM UTC

Seb-C wrote: post #108

mqus wrote: post #81

Earlier quoted context omitted.

What do you think about ORMs like Androids Room[1], where you do specify your own queries with sql (by annotating abstract methods) and can bring your own model and the ORM creates the database schema in the database and gives you access to easy insertion methods. I don't know how Room does it but darts floor library(which is similar)[2] then generates the code that is necessary, in addition to a very slim runtime la…

Thanks. I do not have experience with Room, but I usually prefer to control and know what is happening in my schema. For example, if your schema is automatically handled, how do you both rename and change the type of a column without losing data? Would it perform a delete and a create?

Only the creation is handled automatically. Room helps with migrations by enforcing a database version but you will have to write the migration code(sql) yourself.

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#123

Post by hv42 » Fri, Sep 04, 2020, 8:41 PM UTC

timmy-turner wrote: post #48

When using raw SQL in strings, I really miss the automatic formatting that is provided for HTML, TSX and TS with prettier. Raw SQL query strings also do not compose well and I miss auto completion when writing them (yes, I'm a spoiled kid after so much Typescript usage). As with everybody else, I didn't like existing ORM/builder approaches, so I built and use my own with type-inference: https://github.com/hoeck/types…

You should be able to do this with IntelliJ e.g. where you can inject a language into a string. This is quite handy as you can reformat and open the string in a separate editor if needed.

The caveat is that it does not work well if you are composing the SQL queries from multiple small parts.

see https://www.jetbrains.com/help/idea/running-injected-sql-sta...

I suppose that other editors or IDE can do similar things.

Re: Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

#124

Post by Seb-C » Wed, Sep 16, 2020, 4:14 AM UTC

exevp wrote: post #118

Seb-C wrote: post #109

Earlier quoted context omitted.

> expanding lists of column names I am not sure about what do you mean here? > dealing with casing (snake_case to camelCase) This is one of the opinionated parts of kiss-orm I guess, because I specifically do not want to implement this. I think having consistency in the naming of the properties/columns is more important. I would rather break the naming convention by having snake_case properties than automagically ren…

> I am not sure about what do you mean here? Given i have defined the columns of interest in my data objects anyways... class User { name = null; email = null; } ... i wouldn't necessarily have to repeat them when writing my SQL: sql`SELECT ${Object.getOwnPropertyNames(new User).map(camelCase).join(', ')} FROM users` Of course using a better helper function. There's a few repetitive tasks when writing SQL where don't…

I see what you mean. Indeed, more helpers would be ... helpful I guess, but for now I only implement what I really need and feel like is necessary.

For your specific example, what is wrong with `SELECT *`?