-1

Here is a simplified version of what is happening:

  1. The user completes a form.

  2. When storing the form, the row id is stored in the session.

  3. The user then logs in.

  4. The event of a user logging in is caught and the correct row (id taken from session) is then updated with the users id.

Now if the user only completes step 1 and step 2 then abandons the process because they do not want to log in the database is left with rows of data not attributed to a user.

I need to remove these rows.

What would be the best way to achieve this?

  1. Is there a way to do a database transaction that runs across requests, so it can be started before login and committed after log in?

  2. Would a cleanup script running every so often be best, finding no user attributed rows and deleting them?

Or is there another way?

panthro
  • 22,779
  • 66
  • 183
  • 324
  • 1
    Personally I would go with the 'clean up script' solution. Just write a light weight command and execute if every 30 minutes/1 hour by adding it to your console kernel. – JiFus Mar 13 '19 at 17:11
  • 1
    you can make a default id for those situations. and attach it to every row that is missing the variable in the session. that way you can delete every row with that id. – GabMic Mar 13 '19 at 17:12
  • 1
    Is there any reason why you can not store all form data in session between step 1 and step 2? – Harven Mar 13 '19 at 17:58
  • @Harven it's a massive amount of data, which, correct me if I am wrong, is not good to store large amounts of text in the session? – panthro Mar 13 '19 at 18:53
  • 1
    @panthro Yes, it is not a good practice to store too much data in session. Still you can store your data in temporary file (take a look at **sys_get_temp_dir** method) and then, save a path to your file in session. – Harven Mar 13 '19 at 19:08
  • 1
    Something to consider, although I doubt this would happen much but if the script happens to run between the person submitting the form and logging in wouldn't that potentially wipe out their row? You might want to run it every hour and only delete 60 minutes back to try to prevent it. – Webtect Mar 13 '19 at 19:41

1 Answers1

1

I would create a cleanup script using the scheduler, see basic idea below:

// app\Console\Kernel.php

protected function schedule(Schedule $schedule)
    {
        $schedule->call(function () {
            // Query all records that havent changed in an x-amount of time
            // and remove them.
        })->everyDay();
    }

Then you simply add the following CRON-script to your server:

* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1

And the Artisan helper will call your scheduler every minute and run each task depending on its interval.

Since you cant tell if a user is ever coming back, including the fact that the Laravel session will likely clean itself up very soon (default lifetime is 120 minutes i believe), there wont be any other trigger to remove a particular record from your database.

Flame
  • 6,663
  • 3
  • 33
  • 53