Skip to content
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

null in body params is not the same as undef #78

Open
bensinober opened this issue Aug 30, 2019 · 3 comments
Open

null in body params is not the same as undef #78

bensinober opened this issue Aug 30, 2019 · 3 comments

Comments

@bensinober
Copy link
Contributor

Thanks for this great and simple descriptive API!

I am thinking that the following code:

foreach my $p (@$declared) {
my $name = $p->name;
my $value = $params{$name};
if (not $p->validate(\$value)) {
$p->required ? return : next;
}
$value //= $p->default if defined $p->default;
next if not defined($value);
$self->{'raisin.declared_params'}{$name} = $value;
}

will filter out also defined null values in JSON body, which makes it difficult to define optional params that can be null, meaning a typical PUT or PATCH request to "unset" a value. Say, you have a DB column that needs to be NULLed.
Of course, you still get the "undef"s from req->raisin_parameters, so it can easily be circumvented, but I am still unsure why "undef"s should be removed from declared_params and params?

Is line 34 actually neccessary, is my point.

@khrt
Copy link
Owner

khrt commented Aug 30, 2019

Right, the way it's implemented right now doesn't make much sense and might be fixed.

polettix added a commit to polettix/Raisin that referenced this issue Oct 3, 2019
@meylingtaing
Copy link

Hi! I'm currently using this perl module for a project, and I ran into this issue. We need to be able to differentiate between passing a parameter with value undef, and not passing that parameter at all. What needs to happen to get this fix worked on?

@khrt
Copy link
Owner

khrt commented Aug 31, 2020

Hi @meylingtaing, at the moment I do have much time to work on this.

There is a work-in-progress polettix@48a9e86 stared by @polettix, maybe it can be adopted somehow.

I'll try to do my best to resolve the issue, but unfortunately cannot give you any estimates on this.

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

No branches or pull requests

3 participants