/diesel

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a lightweight API for one-off inserts #789

Closed
sgrif opened this Issue Mar 9, 2017 · 0 comments

Comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@sgrif
@sgrif
Member

sgrif commented Mar 9, 2017

We allow tuples to be passed directly to .set for updates, which is nice when I just want to do a one-off update of a single column. It'd be nice to have a similarly lightweight API for inserts.

sgrif added a commit that referenced this issue Sep 15, 2017

@sgrif
Allow ad-hoc inserts using tuples 
This provides a more lightweight API for inserts that mirrors what is
possible with `.set` for updates. The implementation provided ensures
that all elements within the tuple are valid for the same table, and
that there's no funkiness like sticking an upsert value in there.
(Secret way to break Diesel -- It will totally allow you to stick a
`Vec` in there, and will generate invalid SQL as a result. We should fix
that one eventually, but it's pretty low priority)

One thing I would also like to allow is to allow mixing ad-hoc values
and `Insertable` structs. (See 10374a5
for rationale). I tried a naive approach where I moved the parens out
from the `InsertValues` impl on tuples, and into `InsertStatement`, but
that breaks PG upsert, so I'll need to spend more time on it. I've left
the test cases for that in place, but I will defer actually making them
pass for a later PR in order to keep the PR size and scope reasonable.

I expected to need more tests/compile-tests, but what's included here
felt like it pretty exhaustively tests everything.

Fixes #789
Loading status checks…
cd7f9fc

This was referenced Sep 15, 2017

Merged
Closed

sgrif added a commit that referenced this issue Sep 15, 2017

@sgrif
Allow ad-hoc inserts using tuples 
This provides a more lightweight API for inserts that mirrors what is
possible with `.set` for updates. The implementation provided ensures
that all elements within the tuple are valid for the same table, and
that there's no funkiness like sticking an upsert value in there.
(Secret way to break Diesel -- It will totally allow you to stick a
`Vec` in there, and will generate invalid SQL as a result. We should fix
that one eventually, but it's pretty low priority)

One thing I would also like to allow is to allow mixing ad-hoc values
and `Insertable` structs. (See 10374a5
for rationale). I tried a naive approach where I moved the parens out
from the `InsertValues` impl on tuples, and into `InsertStatement`, but
that breaks PG upsert, so I'll need to spend more time on it. I've left
the test cases for that in place, but I will defer actually making them
pass for a later PR in order to keep the PR size and scope reasonable.

I expected to need more tests/compile-tests, but what's included here
felt like it pretty exhaustively tests everything.

Fixes #789
8e8a3be

sgrif added a commit that referenced this issue Sep 18, 2017

@sgrif
Allow ad-hoc inserts using tuples 
This provides a more lightweight API for inserts that mirrors what is
possible with `.set` for updates. The implementation provided ensures
that all elements within the tuple are valid for the same table, and
that there's no funkiness like sticking an upsert value in there.
(Secret way to break Diesel -- It will totally allow you to stick a
`Vec` in there, and will generate invalid SQL as a result. We should fix
that one eventually, but it's pretty low priority)

One thing I would also like to allow is to allow mixing ad-hoc values
and `Insertable` structs. (See 10374a5
for rationale). I tried a naive approach where I moved the parens out
from the `InsertValues` impl on tuples, and into `InsertStatement`, but
that breaks PG upsert, so I'll need to spend more time on it. I've left
the test cases for that in place, but I will defer actually making them
pass for a later PR in order to keep the PR size and scope reasonable.

I expected to need more tests/compile-tests, but what's included here
felt like it pretty exhaustively tests everything.

Fixes #789
Loading status checks…
f73042f

sgrif added a commit that referenced this issue Sep 18, 2017

@sgrif
Allow ad-hoc inserts using tuples 
This provides a more lightweight API for inserts that mirrors what is
possible with `.set` for updates. The implementation provided ensures
that all elements within the tuple are valid for the same table, and
that there's no funkiness like sticking an upsert value in there.
(Secret way to break Diesel -- It will totally allow you to stick a
`Vec` in there, and will generate invalid SQL as a result. We should fix
that one eventually, but it's pretty low priority)

One thing I would also like to allow is to allow mixing ad-hoc values
and `Insertable` structs. (See 10374a5
for rationale). I tried a naive approach where I moved the parens out
from the `InsertValues` impl on tuples, and into `InsertStatement`, but
that breaks PG upsert, so I'll need to spend more time on it. I've left
the test cases for that in place, but I will defer actually making them
pass for a later PR in order to keep the PR size and scope reasonable.

I expected to need more tests/compile-tests, but what's included here
felt like it pretty exhaustively tests everything.

Fixes #789
Loading status checks…
c8d1772

sgrif added a commit that referenced this issue Sep 18, 2017

@sgrif
Allow ad-hoc inserts using tuples 
This provides a more lightweight API for inserts that mirrors what is
possible with `.set` for updates. The implementation provided ensures
that all elements within the tuple are valid for the same table, and
that there's no funkiness like sticking an upsert value in there.
(Secret way to break Diesel -- It will totally allow you to stick a
`Vec` in there, and will generate invalid SQL as a result. We should fix
that one eventually, but it's pretty low priority)

One thing I would also like to allow is to allow mixing ad-hoc values
and `Insertable` structs. (See 10374a5
for rationale). I tried a naive approach where I moved the parens out
from the `InsertValues` impl on tuples, and into `InsertStatement`, but
that breaks PG upsert, so I'll need to spend more time on it. I've left
the test cases for that in place, but I will defer actually making them
pass for a later PR in order to keep the PR size and scope reasonable.

I expected to need more tests/compile-tests, but what's included here
felt like it pretty exhaustively tests everything.

Fixes #789
Loading status checks…
fe2ebf7

@sgrif sgrif closed this in #1165 Sep 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment