It is to stop doing empty checks all over your codebase.
ConvertEmptyStringsToNull middleware for what!?
Hi all! I have many forms with many fields. I save data like this:
$model = new Model($request->all());
....
$model->save($banner);
After update to Laravel 5.4 I get error "Integrity constraint violation: 1048 Column 'field_name' cannot be null" because ConvertEmptyStringsToNull middleware convert empty filed to null. When user send empty string I don't need null value. I think ConvertEmptyStringsToNull is bad idea.
What purpose of ConvertEmptyStringsToNull in laravel?
Can you show example please?
You don't have to $request->all() you can request one at a time and check if null.
@jlrdw Do you mean i need replace this code
$model = new Model($request->all());
to this?
$fields = [];
if (!is_null($request->input('field1'))) {
$fields['field1'] = $request->input('field1');
}
if (!is_null($request->input('field2'))) {
$fields['field2'] = $request->input('field2');
}
...
if (!is_null($request->input('fieldN'))) {
$fields['fieldN'] = $request->input('fieldN');
}
$model = new Model($fields);
I use a custom function like
public static function fixValue($rvalue)
{
$rvalue = empty($rvalue) && !is_numeric($rvalue) ? NULL : trim(strip_tags($rvalue));
return $rvalue;
}
So I return the value if it exist, or if not I return NULL since NULL will have to be stored in the database in that field. I highly suggest you take some beginner php / mysql tutorials as this is basic stuff.
Note that's just one way, there are other techniques.
I use MySQL and I don't need to store NULL values in database.
https://dev.mysql.com/doc/refman/5.7/en/data-size.html
Declare columns to be NOT NULL if possible. It makes SQL operations faster... You also save some storage space ...
I have a big tables and space and speed is critical.
Then don't store nulls
I have a big tables and space and speed is critical.
How is storing "nothing" going to take up space? again I plea with you take some basic tutorials before you get in over your head in an advanced framework like laravel.
You can store an empty string or nothing is the point. Sometimes I also don't want null. But for a date field. If no date a 0000-00-00 is stored.
I don't like displaying 0000-00-00, in a case of a date I use null so if there's no date then nothing is displayed to user.
It's you that has to decide when to use null and when to use empty string.
How is storing "nothing" going to take up space?
This explain in https://dev.mysql.com/doc/refman/5.7/en/data-size.html
It's you that has to decide when to use null and when to use empty string.
Exactly! ConvertEmptyStringsToNull decides for me. It's not good.
@Kryak ConvertEmptyStringsToNull if for you to decide when you want a null. Sometimes you may want a 0 (zero) stored if a user didn't provide input. You are making way to much out of a simple thing.
ConvertEmptyStringsToNull decides for me. It's not good.
.. Well, don't use it then? o_O
.. Well, don't use it then? o_O
I remove this middleware in my project. It makes me sad. I choose Laravel because it good out of box but now it is not so.
I reformulate my question:
Anybody really need ConvertEmptyStringsToNull in laravel default middlewares?
@Kryak I wish they hadn't put that in, I like being in control of my request, as I showed earlier. I like to decide what to make null and what to make an empty string. But you don't have to use it is the point.
Gee... there are a lot of things you will end up modifying in the framework... Frankly, I would rather have nulls from requests than empty strings... lol
But hey, just take it out...
Like @jlrdw suggested, do some reading on the subject... I guess we just don't see why you are so hung up on null...
I guess we just don't see why you are so hung up on null...
ConvertEmptyStringsToNull broke it simple and powerful code:
$model = new Model($request->all());
I don't store null values in database until it is not necessary. Now I see that is not a problem for other laravel users. Thanks to all.
Its easier to deal with null values rather than empty strings in a lot of places
For instance
$variable = $object->attribute ?? 'default';
Sets the variable to a default value if it is null. The alternative is to test if null or empty string.
I do kind of wish the framework had a 'blessed' sanitiser - there are quite a few packages around, but it feels like it should really be part of the framework like validation is, eg:
$request->sanitize([
'username' => 'trim|lowercase',
'country' => 'trim|to_null',
]);
Its easier to deal with null values rather than empty strings in a lot of places
Of course. I can do new middleware ConvertNullToEmptyStrings ))) Problem is that NULL not equal EMPTY STRING in normal world. NULL - is nothing, undefined value. EMPTY STRING - is a string. ConvertEmptyStringsToNull is the same things as ConvertEmptyStringsToZero or ConvertEmptyStringsToArray or ConvertEmptyStringsToSomethingElse. If i need it i do it self but it should not be the default behavior of framework.
it feels like it should really be part of the framework like validation is, eg: $request->sanitize([ 'username' => 'trim|lowercase', 'country' => 'trim|to_null', ]);
Absolutely right!
Just remove the middelware if you dont want the null value ;)
Just remove the middelware if you dont want the null value ;)
I want to remove the middelware from laravel 5.5 :) Anybody else?
I really like this middleware! While I can understand Kryak's frustration, I think in most cases, it'll give the functionality most people would expect. It makes a text field work more like a checkbox where NOT checking the box doesn't send some sort of false value to the server, it just sends nothing, i.e. null.
An example of where I've found it useful is datetime fields. Let's say you have a blog and you want your Posts to have a published_at field. If you're not ready to publish a post, you'll likely enter nothing into the relevant text field.
Without the middleware, this would submit an empty string and so I'd end up with a Post where the published_at field now has the value 0000-00-00 00:00:00. If my site was then getting all Posts where published_at is less than "now", it'd get this Post that I originally intended to be unpublished. To get around this I'd need to manually check for an empty string before creating/updating the model (essentially doing what the middleware does for you).
With the middleware, the empty string will be converted to null and so my code that retrieves published Posts can be a lot cleaner.
To give some perspective this just brought down an entire system that uses it everywhere. I definitely think this was a bad call, also it took me hours for this to come up in a search, and only after I solved the issue.
When a user enters an empty field in a form, I expect an empty string, not a null value. When a field is not defined in a form. I'd expect a null value. Those are two different things. The ConvertEmptyStringsToNull middleware changes this definition and will give null in both cases and will break a lot of code. It might be a handy piece of middleware if your code does not care, but this should not be bundled with laravel by default.
ConvertEmptyStringsToNull middleware can be committed out.
How can we exclude this middleware from certain methods while keeping it the default for other routes ?
I have to agree with those above that ConvertEmptyStringsToNull is overly presumptuous. An empty string and a null are very different. If a programmer explicitly wants this behavior then that's fine, but it's a blurring of types that shouldn't be enabled by default. It could send unfamiliar programmers in circles for a long time.
We're at Laravel 9 at this point and I'm STILL having issues with this middleware. Particularly bad with validators, where one now needs to add "nullable" to all non required fields. And people here said the motivation was to "stop doing empty checks all over the codebase"?
@salveek Yep it's annoying. Have they added a way to specify which fields to convert and which ones not to convert?
I like using NULL for dates mainly.
Should we just create our own middleware, or is there a clean way to control this using something documented with Laravel?
Please or to participate in this conversation.