Insert/Update/... without having to manually specify the column names

[omid]

Is it possible to insert or update or ... by not manually mentioning all the columns and get the input from a struct?
If not, is there any plan to add this feature?

For example, instead of:

sqlx::query_as("INSERT INTO todo (description, done) VALUES ($1, $2)")
.bind(&todo.description)
.bind(todo.done)
.await?;

Something like:

//  (table name, struct)
sqlx::insert_by("todo", todo)
.await?;

Or a macro to generate all for us, something like:

//  (table name, struct)
sqlx::replace_by!("todo", todo)
.await?;

[abonander]

This is starting to encroach on ORM territory which I'm wary about.

What happens if todo has columns with default values? The macro would have to enforce that the struct's fields match all columns of the table, or just non-defaulted columns.

[omid]

Thanks @abonander, you are right, it can end to having an ORM, but not with this issue alone.
My request is not for _query_ing, it's about the update queries (insert, update, delete, ...).

There are a lot of WH questions we can ask. Sure we can define some default behaviours and maybe add the possibility to customize them.

As far as I can remember, it's a project basically for launchbadge company, I mean you are using it in production.
How do you really write the update queries? Mention the whole column names in the query and bind all the values one by one?
So something like this at last?

sqlx::query_as("INSERT INTO todo (description, done) VALUES ($1, $2)")
.bind(&todo.description)
.bind(todo.done)
.await?;

[abonander]

Yes, we do just write the queries. Oftentimes we need either ON CONFLICT or RETURNING clauses and those aren't handled by DSLs very well.

[dragonnn]

@omid maybe https://github.com/NyxCode/ormx would be something for you :).

[omid]

@dragonnn thanks, that looks promising, will check that as soon as I find a free time 👍

[3tilley]

Hello,

I'd like to resurface this for three reasons:

1. From a new user's PoV it's weird that you can query_as! straight into a type, but can't insert that type ergonomically. I spent a long time looking for the corresponding method because it seemed like it had to exist!
2. ormx and takes the same compile checked philosophy, but it's no longer maintained. It's not currently possible to use sqlx and ormx together
3. Some APIs pass a sqlx connection (like sqlx::PgPool) as a dependency-injected parameter because of the ubiquity of sqlx. You're victims of your own success here, and it means that you can't easily use a different library with more opinionated "ORM-ness`

I'm totally fine with the philosophy of "not an ORM", but I think type-safe serialising that's also ergonomic seems like it wouldn't be at odds with this position. After all, if not the query_as! macro wouldn't exist.

Aside from the work required, do you have any issues with the idea?