[exevp]

> In my experience this is just a very, very small percent of the cases. Most of the time I find myself doing pretty simple CRUD operations, and the boilerplate for the simple cases goes out of hand quickly, specially when running joins.

That's true, although the most frustrating percent of the cases :)

I think what KISS will eventually need is some simple toolbelt for the basic CRUD queries, e.g. expanding lists of column names, dealing with casing (snake_case to camelCase). So making the stuff you write 90% of the times easy without inventing a custom SQL abstraction.

MyBatis (which i mentioned in another comment) approached this for example with sql snippets one could re-use in queries.

KISS enables the same thing by allowing nesting of tagged sql strings. I guess time will show which additional helpers are needed to make the devs life easy/reduce the boilerplate for the simple queries.

[Seb-C]

> 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 rename properties.

[exevp]

> 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 necessarily need a powerful query builder but still end up writing a few handler functions. Shipping some common helpers with the framework might be handy.

[Seb-C]

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 *`?