trashed() returning 'true' after Store()?

Asked

Viewed 56 times

2

I have a model Manifestation using SoftDeletingTrait to keep them inactive in the bank and in the ManifestationController I have the following method destroy():

$manifestation = Manifestation::findOrFail($id);
$manifestation->closedBy()->associate(Auth::user());
$manifestation->save(); // save para marcar o usuário que encerrou
$manifestation->delete();

And if soon after I use $manifestation->trashed(), he returns true, and so far everything is correct. However, I also have a method restore() in the controller, with the following:

$manifestation = Manifestation::withTrashed()->findOrFail($id);
$manifestation->closed_by_id = null;
$manifestation->save();
$manifestation->restore();

The problem is that if I use the $manifestation->trashed(), keep getting true as a result, even though the model is no longer inactive.

  1. This behavior is correct?
  2. Is there any way around and make the trashed() return false after the restore()?

If I’m not mistaken there must be a flag, as well as the exists class Eloquent which may possibly be changed, but I couldn’t find it. I could instead use the trashed, check whether the value of deleted_at is null, but I want to avoid doing so, unless it’s the last option.

Remarks:

  • It reappears in search results normally.
  • I’m using Laravel 4.2 and I can’t change.
  • 1

    Vitor strange, because it does not happen this, if you used restore() the trashed() returns false and used up delete() returns true, I just ran a test on an old code of mine. The exists is a boleano which returns true if there is the record in the database, in case your it will always exist as true, only false for new records.

1 answer

1


After the comment of Virgilio I figured out what caused the problem. I created another model with the same trait and controller and the same worked without problems, so the problem was in the model Manifestation.

What was making the result always be true was that was formatting the attribute deleted_at in a more readable format to be used in view using the command strftime, and that made him was never null, was the initial date (1 January 1970) even though it was null in the bank, and the trashed simply check this out (if the value is null).

To solve, it was only necessary to create a new attribute of another name by calling the deleted_at, format it only in the new attribute and use it from then on.

It was something similar to:

public function getDeletedAtAttribute($data){
  return strftime('%d/%m/%Y às %H:%M', strtotime($data));
}

After the correction:

# getDeletedAtAttribute() removido

public function getClosedAtAttribute(){
  $data = $this->deleted_at;
  return strftime('%d/%m/%Y às %H:%M', strtotime($data));
}
  • 1

    Congratulations and it was really cool his explanation +1; reinforcing the tip, never touch the pattern always has the possibility in the [tag:eloquent] to work the information.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.