Anton Bachin
Anton Bachin
To continue, AFAICT [Rails](https://api.rubyonrails.org/classes/ActionDispatch/Flash.html) recommends `:notice` and `:alert` but does not enforce that this is the possible key set, and there is no ordering between them like in Django.
Laravel Livewire Flash [appears](https://laravel-livewire.com/docs/2.x/flash-messages) to allow any key. In particular, I found an interesting example that sent both a message-to-display and styles for it using [two custom keys](https://ryangjchandler.co.uk/posts/flashing-banner-messages-in-your-laravel-jetstream-and-livewire-applications#flashing-a-message): ```php public...
@tmattio In summary it appears that all frameworks you mentioned, plus Laravel and Flask, allow custom categories. At least Flask explicitly allows having no category. Most of the frameworks have...
> I would suggest `?transaction: true` is the default mode and users can opt out. I can't think of any use cases that would need to be performed without a...
Another use case where you don't want a transaction at `Dream.sql` is when you want to grab a connection from the pool (what `Dream.sql` does) and hold on to it...
> Take a look at how ecto does it for example https://hexdocs.pm/ecto/Ecto.Multi.html As far as I can tell, the `transaction` function in the Multi docs is both getting a connection...
Absolutely agree with not doing it by default. I haven't turned Dream yet into a kind of possible "Apache 1997" that lists files etc. (or even respects `.htaccess`), but we...
I haven't had a chance to look into this, whether it occurs on other systems, etc. However, it is indeed the Dream convention that, by default, client-side errors are reported...
It looks like an unhandled ECONNRESET exception is being treated as a server-side error, which in a way, it is (an error within Dream itself, for not handling the exception...
I understood this issue only on the last line of the comment :) It's about having `node` ready for a native app to call into, so you can use various...