Mention db-postgres/async-postgres in the docs

[rattrayalex]

See this hn thread: https://news.ycombinator.com/item?id=27238671

People seem to think that threaded Rails isn't worthwhile because pg is blocking, but you have solved the problem with async-postgres (which is awesome!).

Since falcon isn't too useful with rails if you're using a blocking db driver, it might be worth mentioning their use in the rails integration guide (along with any other async versions of common libraries needed to make threaded ruby worthwhile).

[ioquatix]

I have archived async-postgres and async-mysql and linked to the respective db- gems.

I'll follow up with further changes/improvements to the documentation.

[rattrayalex]

Oh ok great!

[doits]

I just read this comment on HN:

On this topic, a warning for anyone trying to implement async rails with postgres: beware. Connections are per-thread in the ‘pg’ gem (and every other driver I’ve used), so one client’s connection may commit/abort another client’s transaction, and they end up stomping all over each other. Which you will only observe under load.

Is this a problem for falcon in combinaton with rails and the pg gem, too?

[ioquatix]

I would not recommend combining AR and Falcon at this time, because AR connection state is per-thread. There is work to correct this deficiency. https://github.com/rails/rails/issues/42271

I would recommend using the db gem: https://github.com/socketry/db which is as fast if not slightly more efficient than AR.

[rattrayalex]

Bit of an aside, I imagine people visiting the db readme/homepage might want to be able to get an idea at a glance of how it compares to AR, or other existing gems. My impression is "it's a totally different thing: you get none of the AR abstractions, you just connect to the db and write sql" but I may be way off.

[ioquatix]

For data modelling we have https://github.com/socketry/db-model I will cross link these projects. For migrations we have https://github.com/socketry/db-migrate

Both projects are immature and require more work but they both do work and I'm using them in production.

[doits]

I would not recommend combining AR and Falcon at this time, because AR connection state is per-thread. There is work to correct this deficiency. rails/rails#42271

I would recommend using the db gem: https://github.com/socketry/db which is as fast if not slightly more efficient than AR.

Thanks for the answer. Guess the I am not migrating a bigger legacy Rails app to falcon then yet, since I'm stuck with active record and therefore cannot use the db gems (until active record has support for them afaik).

[ioquatix]

Yes, well if AR support for fibers is important you should voice your support on the relevant issue :)

[Drenmi]

Does Falcon work well with Jeremy Evans' Sequel?

A question that's bit of an aside, but not too far off what's being discussed here. 🙂

I took a look at Sequel's default connection pool implementation, and it seems to use thread locals, which should also be fiber locals, but figured maybe someone has tried it and had proper confirmation.