[5.x] Enhance Telescope Clear Method

[a1383n]

This PR enhances the clear method in Laravel Telescope's DatabaseEntriesRepository to improve the efficiency and reliability of clearing the telescope_entries and telescope_monitoring tables.

Key Improvements:

• Safe Truncate: The method begins by disabling foreign key constraints using Schema::disableForeignKeyConstraints() before attempting to truncate the tables. This avoids foreign key conflicts during truncation.
• Fallback to Chunked Deletion: If a QueryException occurs during truncation, the method catches the exception and reverts to chunked deletion. This ensures the tables are cleared even if truncation isn't possible due to database constraints or limitations.
• Performance Enhancement: Truncation is much faster than deletion in chunks, making this approach optimal for performance while still retaining compatibility with databases that have row deletion limits.

References:

• This PR addresses issues caused by [4.x] Updated db command for clearing tables #991, where unhandled foreign keys during truncation led to failures.
• It also preserves the chunked deletion logic introduced in fix: clear all entries using chunks #1415 and Prune command fails to delete records then using with mysql on planetscale #1410, ensuring support for databases with row deletion constraints.

[taylorotwell]

Reverted due to #1509

[a1383n]

Reverted due to #1509

@taylorotwell
@driesvints

I’d like to respectfully address the decision to revert the recent commit related to the clear() method in the DatabaseEntriesRepository. I believe the concerns raised, specifically about the telescope_entries_tag table not being cleared, do not apply in a properly configured production environment, and the revert might have been unnecessary.

Key Points:

1. Efficiency of TRUNCATE:

   • TRUNCATE is an O(1) operation, which means it is significantly faster and more efficient than using DELETE in chunks, especially for large tables. In production environments with high logging activity, this speed is crucial for maintaining performance and avoiding unnecessary delays during log clearance.
   • Truncation not only deletes all rows but also reclaims the storage space immediately, making it a much better choice than DELETE for this use case.

2. Robust Fallback Mechanism:

   • In the unlikely event that TRUNCATE fails due to a QueryException, the code falls back to chunked deletion. This fallback ensures that all records are deleted, albeit at a slower pace, which guarantees that the tables are cleared even in non-ideal situations.

3. No Impact on Production Environments:

   • The concern about the telescope_entries_tag table not being cleared is unlikely to manifest in a standard production environment where foreign keys and data consistency are properly managed. The truncation approach has been tested and validated in typical production scenarios, with no issues observed.

Reverting this change might have been premature, as the issue raised does not seem to apply to most production environments, where the efficiency and reliability of TRUNCATE are highly beneficial.

I am, of course, open to further discussion and am happy to collaborate on ensuring the best outcome for the Laravel Telescope package.

Thank you for considering my points.