Separate raw value representations of postgresql and mysql backend #2134
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
weiznich
force-pushed
the
feature/pg_dynamic_value
branch
3 times, most recently
from
a9ebb3a
to
870b503
Compare
JohnTitor
reviewed
Aug 4, 2019
weiznich
force-pushed
the
feature/pg_dynamic_value
branch
from
870b503
to
e6b0be8
Compare
|
All remaining build failures are fixed by #2131 |
JohnTitor
approved these changes
Aug 5, 2019
weiznich
force-pushed
the
feature/pg_dynamic_value
branch
from
e6b0be8
to
c2776c1
Compare
|
@sgrif Stated that he has some comments on this. |
This commit separates the raw value representation of the mysql and postgresql backend from raw `&[u8]` to specific types that could hold additional information. To avoid code duplication for commonly used types an additional trait (`BinaryRawValue`) is introduced, which is basically equivalent to `AsRef<[u8]>` but has the existing `HasRawValue` trait as super trait. This is required to workaround some higher ranked life time issues in rustc. Additionally some type information are added to the postgresql value type. Those information may allow to do dynamic type conversations in future diesel versions.
We don't look at the oid's internally and won't do that any time soon. So document that behaviour and simplify the code.
weiznich
force-pushed
the
feature/pg_dynamic_value
branch
from
f6c9719
to
d602574
Compare
|
@sgrif I've done the changes we have discussed some weeks ago. |
weiznich
force-pushed
the
feature/pg_dynamic_value
branch
from
662b13a
to
495f46e
Compare
|
@JohnTitor Would it possible to get a final review on this (assuming that the CI now succeeds)? |
This was referenced Oct 10, 2019
sgrif
added a commit
that referenced
this pull request
Dec 13, 2019
This was originally included in #2134 with the following comment: > Additionally some type information are added to the postgresql value > type. Those information may allow to do dynamic type conversations in > future diesel versions. While this may be useful in the future, we should wait until we have a concrete use case for doing so. At the moment this means we have to thread a `PgConnection` through various types that otherwise wouldn't need to carry it, and are stabilizing an API that we aren't even sure if/how we want to eventually use. Given that every use of `PgConnection` complicates providing an async implementation, we should be more conservative about speculative APIs like this.
sgrif
added a commit
that referenced
this pull request
Dec 13, 2019
This was originally included in #2134 with the following comment: > Additionally some type information are added to the postgresql value > type. Those information may allow to do dynamic type conversations in > future diesel versions. While this may be useful in the future, we should wait until we have a concrete use case for doing so. At the moment this means we have to thread a `PgConnection` through various types that otherwise wouldn't need to carry it, and are stabilizing an API that we aren't even sure if/how we want to eventually use. Given that every use of `PgConnection` complicates providing an async implementation, we should be more conservative about speculative APIs like this.
h-michael
pushed a commit
to h-michael/diesel
that referenced
this pull request
Dec 21, 2019
This was originally included in diesel-rs#2134 with the following comment: > Additionally some type information are added to the postgresql value > type. Those information may allow to do dynamic type conversations in > future diesel versions. While this may be useful in the future, we should wait until we have a concrete use case for doing so. At the moment this means we have to thread a `PgConnection` through various types that otherwise wouldn't need to carry it, and are stabilizing an API that we aren't even sure if/how we want to eventually use. Given that every use of `PgConnection` complicates providing an async implementation, we should be more conservative about speculative APIs like this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit separates the raw value representation of the mysql and
postgresql backend from raw
&[u8]to specific types that could holdadditional information. To avoid code duplication for commonly used
types an additional trait (
BinaryRawValue) is introduced, which isbasically equivalent to
AsRef<[u8]>but has the existingHasRawValuetrait as super trait. This is required to workaroundsome higher ranked life time issues in rustc.
Additionally some type information are added to the postgresql value
type. Those information may allow to do dynamic type conversations in
future diesel versions.
Basically a improved reimplementation of #1833 on top of #1976. As @sgrif stated there this PR keeps the common impl's in place by adding a
BinaryRawValuetrait.That said: I'm not super sure if the newly added public types/functions have meaningful names or if we should choose something different.
cc @pgab