Enhancing Laravel: Streamlining Database Transactions to Uphold DRY Principles

[rajentrivedi]

In the Laravel ecosystem, the ethos of Don't Repeat Yourself (DRY) is a guiding principle for efficient and maintainable code. However, when it comes to managing database transactions, developers often find themselves duplicating code by repeatedly implementing transaction handling mechanisms like DB::beginTransaction(), DB::rollBack(), and DB::commit() throughout their projects or

DB::transaction(function () {

});

This discussion aims to explore avenues within Laravel for streamlining database transactions to better adhere to the DRY principle. By identifying common patterns and pain points in transaction management, we can brainstorm potential enhancements or features that Laravel could incorporate to automate and simplify transaction handling.

[macropay-solutions]

    DB::transaction(function () {
    
    });

DRY does not mean that your repeating function calls are considered duplicate code. So why the above code should be considered duplicate code?

[Sophist-UK]

Providing that there is no significant performance hit by doing so, would it make sense for Laravel by default to start a database transaction the first time there is an update (or on the first database request) and do a commit when Laravel terminates normally and a rollback when Laravel terminates abnormally (through an exception or a non 200 return code)?

Since it is easy to come up with situations where you would want manual control of transactions, you would need some way for the App to turn off this functionality.

And for existing code with manual transactions you would want it to play nice without any code changes.

[ghost]

Assuming this will get any traction, the default should be off, so as it is now, requiring you to enable the feature if needed. Personally, I would not want such a default to be true.

[macropay-solutions]

What about nested transactions? How would that work with a builtin feature like that?

[Sophist-UK]

Having it off as default would preserve full backward compatibility.

You could have a switch to turn it on either in the App Service Container (like Model::shouldBeStrict etc.) or perhaps also in the routing classes so that you can choose specific routes to enable or disable this for.

[Sophist-UK]

I am not sure that it would work for nested transaction - it might depend on the implementation, or you might need to use explicit transactions in this event.