Marco Deleu

According to this explanation https://github.com/orgs/community/discussions/25161#discussioncomment-3246673 this "bug" is by design. Apparently when we make the `on: pull-request` actions, it will automatically use the `synchronize` event which will always consider all...

I will give it a try again and report back later today, but my untrustworthy memory says I did manage to run the scenario with docker build normally.

I'd like to chime in on this since it **seems like** it may heavily affect me. > The only issue I can think of if tests within a TestCase change...

> @taylorotwell Possibly because everyone uses `RefreshDatabase`. But in some reason I prefer `DatabaseTruncation`, so I critically encountered the problem. @mpyw If this problem mainly affects `DatabaseTruncation`, can't it be...

> If the approach is to disconnect all database during tearDown, this have been proposed and rejected, also potentially impacts performance (since we only disconnect database connectio via `RefreshDatabase` and...

Seems like a breaking change since my `configureIsolationLevel` method wouldn't be called after doing a patch update? https://github.com/cgauge/laravel-aurora-connector/blob/main/src/AuroraConnector.php#L48

The way I handle this sort of issue is to configure my local container to run with the `nobody` user, which matches the FPM configration that Bref ships. With `docker...

My take on this is that the behavior of the adapter is to casually adjust Laravel's default installation for a quick drop-in replacement for Lambda. If you're deploying your project...

hey @tillkruss can you expand a little on why you want to create configurable runtime dynamic variables with a worse user-experience for users instead of implementing a better default value?

> @deleugpn: I may simply not understand the use-case and this change looks like a potential breaking-change to me. What can I explain that would help you understand the use-case...