[Bug] Cannot update data model after 4.1.44 update #3713
Comments
|
I'm encountering the same issue after upgrade to 4.1.44 too. (Integrity constraint violation: 1048 Column 'user_id' cannot be null) For my code, it is this: [
'name' => 'user',
'type' => 'relationship',
'entity' => 'user',
'attribute' => 'full_form_description',
'model' => User::class,
'placeholder' => 'Search a user',
'minimum_input_length' => 1,
'tab' => 'User Filled',
'attributes' => ['disabled' => 'disabled'],
'ajax' => true,
],Hope it helps in the investigation. Before 4.1.44 it works fine |
|
@kitzberger can you let me know how you are setting up the saving process ? From my understanding you are using model I've setup an public function user() {
return $this->belongsTo('App\Models\User','user_id'); //user_id is not nullable in database
}I've setup the creating event: public static function boot() {
parent::boot();
static::creating(function($item) {
$item->user_id = backpack_user()->id;
});
}
It correctly saves in the database:
Same for the update process. @ziming I could not fully test your scenario but I tested with: $this->crud->addField([
'name' => 'user',
'type' => 'relationship',
'entity' => 'user',
'attribute' => 'name',
]);Same result, user_id is properly saved in the database. Let me know, |
|
Hi @pxpm, |
|
@kitzberger any chance you don't have user_id in your fillable model property? Best, |
|
@pxpm, |
|
I tought the problem might be that, but I'v just tested without I am concerned that something might be slipping me here. Any chance your project is open-source so I can try to reproduce it there ? If not, can you share a little bit of the stack trace that lead to the error ? Any chance that Can you try to see the full query with the bindings ? You can add this snippet in your DB::listen(function($query) {
Log::info(
$query->sql,
$query->bindings,
$query->time
);
});Thanks @kitzberger for the time spent here helping me to debug this. Best, |
|
@pxpm, unfortunately I cannot publish the source of our application ;-/ But here's the log file you requested. I've stripped it down to the relevant parts: |
|
I think Iam having the similar issue. When I have field which is disabled it writes empty string to database instead of omitting it from query. Not sure, but maybe this #3643 is what is causing that? |
|
@GregaUNK I am almost sure that PR is not causing that kind of issues. The only difference there is if the function is not present in model, we don't call it. Otherwise we would call it even if not present and raising an error. Disabled inputs don't get submitted by the browser, you could try dd() your request to check what is passing after form submission. @kitzberger From what seems this is what is happening:
My guess is something you are doing is trying to query the database again to update the issue That second time you are attempting to update the On my tests I only get the first DB query like you with Let me know, |
|
@pxpm then it has to be something else... I have many disabled fields. Everything worked till 4.1.43. Now I have a problem with these fields. If the field is disabled and you save/update the record it overrides value in table with NULL. Any clue what could be wrong? Should I open a new issue about this? |
|
Hmm maybe it will be helpful to share my update method too to give more context public function update(UpdateRequest $request)
{
$this->removeReadOnlyRequestFields();
// your additional operations before save here
$redirect_location = $this->traitUpdate();
// your additional operations after save here
// use $this->data['entry'] or $this->crud->entry
return $redirect_location;
}
/**
* This method is mainly used by the update method to remove fields that shouldn't be edited.
*/
private function removeReadOnlyRequestFields()
{
$fieldsToRemove = [
'field_name_one'
];
$this->crud->removeFields($fieldsToRemove);
} |
|
@ziming / @GregaUNK / @kitzberger , maybe one of you can help us track this down the old-fashioned way 😅 By undoing the changes one-by one and seeing if that fixes it. It shouldn't be that time-consuming if there's a clear broken behaviour between .43 and .44. Can any of you guys help us out? Here's a diff between 4.1.43 and 4.1.44. Let me strip that down even more, functionality changes have only been done in:
And out of those, I think the only ones that could (maybe... somehow) affect this are:
Any chance one of you can undo each of these in your code, one by one, see if that one particular change fixes the problem? |
|
@tabacitu, sure. I've done that already, see previous post:
|
|
Hello guys. So, I could reproduce @GregaUNK and @ziming issues, but I dunnot how it worked before and now it's not working. The problem about the disabled fields is the fact that the I tracked it down to where we get the form data: After we get all the fields that are relations, later in: we try to relate the values. Value isnull, so we set the value to null in database, like if you have a regular select and remove the previous selected item. But in your case there is no value at all, so we should not touch that relations.
I've created #3747 that will fix this issue for single selects, but not totally because of the multiple ones, more info in the PR thread, but I am still not able to find out any change from About @kitzberger issue I am still not able to find out how they could related, because the change was in I will keep digging on this. Best, |
|
Sorry to be so late to the party, guys! I've been in caveman-mode working on the next big thing for Backpack. I'm pretty sure you'll love it too, super-excited to get it out the door by the end of the month. @pxpm if the problem is #3705 I propose:
Sounds like the fastest & safest solution. Let's talk a bit in #3705 please 🙏 I need your experience on this to make this judgement call. |
|
Hi guys, First of all thanks lot for the patience (and for pitching in of course). We've decided to:
Again, thanks a lot for the help. And sorry it took quite a while. Cheers! |
Originally posted by @kitzberger in #3705 (comment)
Not sure if this is related to this patch: but after upgrading to 4.1.44 we cannot update our data model any longer.
Our scenario is:
backpack_user()->idWith 4.1.44 there's an exception when trying to update the model in the DB:
The text was updated successfully, but these errors were encountered: