Skip to content

Commit eb75d09

Browse files
committed
Add a note to README about Puma plugin and using Puma in development
1 parent 9fa95c5 commit eb75d09

File tree

1 file changed

+6
-0
lines changed

1 file changed

+6
-0
lines changed

README.md

+6
Original file line numberDiff line numberDiff line change
@@ -440,6 +440,12 @@ plugin :solid_queue
440440
```
441441
to your `puma.rb` configuration.
442442

443+
If you're using Puma in development but you don't want to use Solid Queue in development, make sure you avoid the plugin being used, for example using an environment variable like this:
444+
```ruby
445+
plugin :solid_queue if ENV["SOLID_QUEUE_IN_PUMA"]
446+
```
447+
that you set in production only. This is what Rails 8's default Puma config looks like. Otherwise, if you're using Puma in development but not Solid Queue, starting Pumna would start also Solid Queue supervisor and it'll most likely fail because it won't be properly configured.
448+
443449

444450
## Jobs and transactional integrity
445451
:warning: Having your jobs in the same ACID-compliant database as your application data enables a powerful yet sharp tool: taking advantage of transactional integrity to ensure some action in your app is not committed unless your job is also committed and vice versa, and ensuring that your job won't be enqueued until the transaction within which you're enqueuing it is committed. This can be very powerful and useful, but it can also backfire if you base some of your logic on this behaviour, and in the future, you move to another active job backend, or if you simply move Solid Queue to its own database, and suddenly the behaviour changes under you. Because this can be quite tricky and many people shouldn't need to worry about it, by default Solid Queue is configured in a different database as the main app.

0 commit comments

Comments
 (0)