Soft Deleting A User And Their Profile

I'm just thinking aloud but wouldn't you just set the Profile to deleted when you soft_delete the User?

Sadly you can't, What you can do is something like this

public function destroy($id, ProfileRepository $profileRepository)
{
    $user = User::findOrFail($id);

    $profileRepository->destroy($user->profile_id);

    $user->delete();

    return redirect('users');
}

I'm just asking to learn and understand but why do you need to findOrFail before you delete in this instance. Also, does it matter if you soft delete the profile before the actual user? I have a userRepository which is not what you are doing.

So you don't have a profileRepository?

@xtremer360 The order doesn't matter when you soft delete, since it's simply update query.

You can do it easily during deleted event. However, do you access profiles other than through the user model?

@bobbybouwmann I don't. Is this a good time to have one then?

@JarekTkaczyk What do you mean do I access the profiles other than through User model?

If you use the repository pattern it common to use it on all your models

@xtremer360 Why would you do this:

$profile = Profile::find($someId);

instead of this?

$user = User::find($someId);
$user->profile->something

Red this

That said, in fact it doesn't matter if profile is soft deleted or not.

Anyway, you can chain soft deleting during deleted event (ofc profile must use soft deletes as well).

@JarekTkaczyk How would I chain soft deleting for my profile then? I'm just curioius since I have a userRepository to delete the user.

If you only access the profile through the user model you wont need to mark it as deleted as its inaccessible if the user is deleted.

@xtremer360 raw eloquent:

// user
protected static function boot()
{
    parent::boot();
    
    static::deleted(function ($user) {
        $user->profile->delete();
    });
}

Better would be using observer, but it doesn't matter.

Now, since you're using repository, there's no need for the above. You probably have a method for deleting user in your repo, so just delete the profile along with user.

@JarekTkaczyk

This is what I currently have for my UserRepository. Is this correct?

<?php

namespace App\Repositories\Users;

use App\User;
use App\Repositories\EloquentRepository;

class EloquentUserRepository extends EloquentRepository implements UserRepository {

    public function __construct(User $model)
    {
        parent::__construct($model);
    }

    /**
     * @param integer $id
     * @return mixed|void
     */
    public function delete($id)
    {
        $user = User::findOrFail($id);

        $user->delete($user);
    }
}

@xtremer360 Apart from calling User::findOrFail instead of (probably) $this->user->findOrFail, you need to also delete its profile. That's all

@JarekTkaczyk

So your saying something more like this. Double check I added it the rest.

<?php

namespace App\Repositories\Users;

use App\User;
use App\Repositories\EloquentRepository;

class EloquentUserRepository extends EloquentRepository implements UserRepository {

    protected $user;

    public function __construct(User $user)
    {
        parent::__construct($user);
        $this->user = $user;
    }

    /**
     * @param integer $id
     * @return mixed|void
     */
    public function delete($id)
    {
        $user = $this->user->findOrFail($id);

        $this->user->delete($user);

        $this->user->profile->delete($user);
    }
}

This should be sufficient.

public function delete($id)
{
    $user = $this->user->findOrFail($id);

    $user->delete();
    $user->profile->delete();
}

@deringer So I don't need a repository function for delete?

@xtremer360 I’m not sure why you need to soft-delete the profile at all. If you soft-delete the user, then any of that user’s associated data (including profile) would be inaccessible.

That is a good point.

@xtremer360 I would suggest not on the profile itself, no. You can handle deleting the profile in the same place as deleting the user, you could use a model observer, or depending on the complexity of other tasks that might need to take place when you delete a user, by firing an event.

(Soft) deleting the profile itself serves only as a tidy up process at this point. If you were using foreign key constraints with cascading deletes in your DB, rather than using the application to manage deleted items, then deleting the user would also trigger the deletion of any relationships.

It may not make sense necessarily to delete the profile when you delete the user now, but at a later time, you might want to access the profile directly, without hitting the user. In this instance, you probably don't want to be accessing profiles of deleted users.

Lets say you create the profile at the same time you create the user. That holding true, wouldn't you want to also remove the profile at the same time you remove a user? It's only one extra line, so why not?

So since there's been a lot of posts in here and I feel as if people are giving me different paths to go in its leaving me in a state of confusion. So since I have a usersRepository but not profileRepository. I think I should handle both the creation and deletion of a user in the same way in reference to handling the users profile as well. Here's a few questions I'm asking.

1. Do I need a profileRepository?
2. Do I delete the profile in the UsersController or userRepository.
3. Is this something that I should just use a model event for in the User model.

Can I get any more replies to this post?

Is there any time where you would be deleting the profile independently of the user? That should help you choose the best direction.

What reasoning do you have behind using repositories? I tend to use repositories for any read operations I use more than once only and use Eloquent models for write operations in most of my projects.

Like the other guys said, there really should be no reason you need to delete the user's profile. So long as the user is not accessible, his associated data (his one-to-one data anyway) should not be accessible.

If you are looking for the correct answer though, triggers would probably be your best bet. This requires no code intervention, so it would save you from having to keep the two models' "deleted" status in sync.

create trigger soft_delete after update on users
for each row
update user_profile set deleted_at = new.deleted_at where user_id = new.id

All that would happen here, is when the user table's deleted_at column is updated, it keeps the associated row in user_profile's deleted_at column in sync. This will work both directions (deleting and restoring). You could then remove all your code that involves deleting the two models and stick to simply $user->delete() and $user->restore()

@Jeffberry nice . here is the laravel way then ;) -> wrap that in a migration

<?php

use Illuminate\Database\Migrations\Migration;

class CreateSoftDeleteTrigger extends Migration {

     public function up()

     {

     DB::unprepared('
          create trigger soft_delete after update on users 
          for each row
          update user_profile set deleted_at = new.deleted_at where user_id = new.id
          ');
     }

     public function down()
     {
          DB::unprepared('DROP TRIGGER `soft_delete `');
     }
  }

@deringer @martinbean @JarekTkaczyk

Okay so I've decided to take the advice and I'm just deleting a user and not their profile because after really thinking about the only time a profile can be accessed is by a "super admin" can view profiles of users even if they have been soft deleted. Now here's an extention on this. When should I have it create the profile when the user is created. In the controller or use a model event and put it in there or put it inside the userRepository for creation.

create trigger profile_create after insert on users 
for each row
insert into user_profile (user_id) values (new.id)

;) This isn't as useful as the "update" trigger because most likely this should (and would) only happen once in your system, whereas deleting and restoring could theoretically happen an infinite number of times. However, I still suggest it here -- often times developers get too caved into their framework and think everything should and could be done through the framework. Theoretically it can. But you also have all these other tools making your website live (apache, sql, etc.) so why not use each one for what they're actually meant for? Offload your database work to the database.

Where this would also fall short is the fact that it would be inserting a blank profile, whereas if you were to create the profile in the UserRepository along with the user creation, you would have your attributes there to populate the profile with. So, I would suggest the repository method -- whatever you do the idea is just to stay consistent and make sure everything kind of funnels through the same system(s).