A cast in Laravel should only affect the type, but not the database intrinsics whether a column accepts `null` or not.
As an example, consider this table (Postgres syntax):
```sql
CREATE TABLE foo (
some_column jsonb
);
```
This will be generated as: `@property string|null $some_column`
When providing a the following casts on the model:
```php
protected $casts = [
'some_column' => 'array',
];
```
then the generated property changes to: `@property array $some_column`
However the DB still accepts `null`, but this can't be expressed via the casts.
This change will make the null "sticky" and generate: `@property array|null $some_column`
When running php artisan ide-helper:models below message was presented:
"Do you want to overwrite the existing model files? Choose no to write to _ide_helper_models.php instead? (Yes/No): (yes/no) [no]:"
This commit changes message to:
"Do you want to overwrite the existing model files? Choose no to write to _ide_helper_models.php instead? (yes/no) [no]:"
* Add nullable support
Fixes#407
* Add nullable to setProperty
Better do it like this to still be able to override the base type if wanted
* Cleanup nullableColumns between models iterations
Also rename it to nullableColumns since it contains multiple columns
* Fix formatting
* Fix#480 where tinyint is casts as bool
`tinyint` is classified by bool as doctrine/dbal, but it should not be so in our use case. `tinyint` is better PHPDoc'ed as int. If the user wants bool, he should use Eloquent's `$casts` property to do that.
* Pass PSR-2 check
* Remove comment as requested
Add support for models that override Eloquent's newCollection() with a
custom collection type. Do this by executing the relationship on the
model then executing that relationship's newCollection() method to see
what type of colletion class is returned.
Remove the now-unused
Barryvdh\LaravelIdeHelper\Console\ModelsCommand::getClassName() method.