-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
implement json_object #4230
implement json_object #4230
Conversation
@weiznich what value should i pass it in |
@valkrypton I would suggest to just define a new column with the type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for open the PR!
I have some comments about the type signature and also request the other variant of this function
/// assert_eq!(expected,json); | ||
/// | ||
/// let json = diesel::select(json_object(vec!["hello","world","John","Doe"])).get_result::<Value>(connection)?; | ||
/// let expected:Value = serde_json::from_str(r#"{"hello":"world","John":"Doe"}"#).unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we use the serde_json::json! macro instead to construct the expected values?
/// # Ok(()) | ||
/// # } | ||
/// ``` | ||
fn json_object(text_array:Array<Text>)->Json; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Arrays in diesel are always generate arrays with nullable elements, with will make impossible to use this methods with array columns from tables. But this method breaks if we pass a array to them.
I would like @weiznich opinion here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would just accept both variants here. That might require an additional helper trait that is implemented for both Array<Text>
and Array<Nullable<Text>>
. Additionally what's about Nullable<Array<_>>
here?
@@ -1423,3 +1423,38 @@ define_sql_function! { | |||
/// ``` | |||
fn array_upper<Arr: ArrayOrNullableArray + SingleValue>(array: Arr, dimension: Integer) -> Nullable<Integer>; | |||
} | |||
|
|||
define_sql_function! { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function also support a form jsonb_object(keys text[], values text[])
, whitch takes keys and values pairwise from two separate arrays. Could you implement that too?
You can use #[sql_name ="..."]
like in array_to_string definition and you also need to add some docs in the base function (exemple)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes sure ill implement that too
@guissalustiano can you take a look at the type signature now? |
Sure! A signature like We also would like to support an Could you also please remove the extra files in the commit? You can keep the branch out-of-date, don't worry, or use rebase to avoid showing the news commits in your PR |
@guissalustiano take a look now, also i tried but couldn't figure out how to remove the extra files in the commit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a comment explaining how to get the right function signature. Hopefully that helps to cleanup the confusion there.
Also I would like to see some cleanup of the changes in this PR. The diff looks really wired, it seems like there is some half broken merge in there. Let me know if you need help to figure out how to solve that.
/// # Ok(()) | ||
/// # } | ||
/// ``` | ||
fn json_object<Arr:MaybeNullableValue<Array<Nullable<Text>>>>(text_array:Arr) -> Nullable<Json>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry but this is still not correct. The correct signature would be:
fn json_object<Arr:MaybeNullableValue<Array<Nullable<Text>>>>(text_array:Arr) -> Nullable<Json>; | |
fn json_object<Arr:ArrayOrNullableArray + MaybeNullableValue<Json>>(text_array:Arr) -> Arr::Out where Arr::Inner: TextOrNullableText; |
To explain the bounds:
Arr: ArrayOrNullableArray
says the input type is eitherArray<T>
orNullable<Array<T>>
Arr: MaybeNullableValue<Json>
says that the output values has the same nullability as the input value. That meansNullable<Array<T>>
evaluates toNullable<Json>
andArray<T>
evaluates toJson
via theArr::Out
return type.Arr::Inner: TextOrNullableText
says that the inner type of the array is eitherText
orNullable<Text>
Now the bad thing is that the declare_sql_function!()
macro does not support where clauses, so we need to have a new helper trait for this. For that we need to declare:
trait TextArrayOrNullableTextArray {}
and implement it for the following types:
Array<Text>
Nullable<Array<Text>>
Array<Nullable<Text>>
Nullable<Array<Nullable<Text>>>
(which essentially only lists the supported argument types)
That gives us then the following function signature:
fn json_object<Arr:MaybeNullableValue<Array<Nullable<Text>>>>(text_array:Arr) -> Nullable<Json>; | |
fn json_object<Arr:TextArrayOrNullableTextArray + MaybeNullableValue<Json>>>(text_array:Arr) -> Arr:Out; |
``
Thanks for the detailed explanation, i appreciate it. |
ce549b0
to
3340b6f
Compare
* Add `#[diagnostic::on_unimplemented]` for new helper trait * Fix formatting
3340b6f
to
24612ba
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update. The signature looks good now.
I just rebased this PR again to resolve the merge conflicts, but the history already looked right before that. So either it was a github issue before or you already fixed it 🙏
I also added a #[diagnostic::on_unimplemented]
attribute to the new helper trait to improve the compiler error message if some user passes in a wrong typed value.
added support for
json_object
under #4216