ROM VS Sequel

Just wanted to say that the authors libraries, especially ROM [0], are incredible and have played a huge influence on me as a developer. I learned a lot using and diving through the code.

[0]: https://rom-rb.org/

Better gems. dry-rb, ROM, and Hanami are doing interesting stuff. I also hear web_pipe is popular?

This is exactly how I ended up contributing to DataMapper, then joining the core team, then releasing Virtus, then working on DataMapper 2.0, then turning it into rom-rb, then joining dry-rb and building 1.25 library / month on average for about 2 years or so to eventually join Hanami team...and, yeah, it's been kinda nuts now when I look back.

Ruby Object Mapper

Sequel

Definitely not a pool as we understand it today, i.e. checking out connections to the requester thread so that it can be used exclusively. I'm imagining that a ractor-friendly db pool would work way differently, i.e. "relaying" the SQL to a "proxy" connection, and from there to a fixed (or not?) pool of ractor workers, each holding its own connection exclusively. I'm over-simplifying perhaps (i.e. transactions would have to be "sticky", so you'd have to make sure you're communicating with the right worker), but bottom line, I agree with the necessary "heavy refactoring" for most of the popular db pools (I'd imagine it'd be simpler in sequel, which already has many different implementations), but I'd be hopeful the result wouldn't be less usable (some more "low-level" APIs would probably have to change though).

Sequel [1], the Ruby ORM. It's rock-solid, provides similar abstractions to Active Record but feels much better thought out, and it has great docs.

Also, at any point in time, it's likely to have zero open issues and zero open pull requests, which is pretty impressive for a project of its size.

[1]: https://github.com/jeremyevans/sequel

The most excellent ORM I've ever worked with was sequel for ruby. The only time I felt the tool wasn't working against me, and gave me access to all those advanced db features ORM are so good at hiding from you.

As a developer, though, it's a bit problematic for users reporting issues. Yes, it is beneficial, I get it, but ... I just lack the time to really go towards fixing most of the problems. I even have my own bug reports for my own code and many of these just are never resolved. It's just not manageable after a certain amount, and if you have too many projects. And when you lack time, you don't really go through the issues either, so they just compound without ever being resolved. Some projects handle issue request really very well (jeremy's sequel, for instance https://github.com/jeremyevans/sequel), but it takes a lot of discipline to do so too. I don't have that discipline, so it's all just more and more on the todo list ... :P

Sequel

I've never used Rails. I used Sinatra in the early days and over the last 8 years I've used Roda[0] and Sequel[1].

Our stack is front-end heavy with a very mature JS framework and the back-end is mostly an API server. Databases range from SQLite to Postgres.

Development is usually done on SQLite and staging / production on Postgres. Quite a few projects with SQLite DB in production as well.

[0]: https://roda.jeremyevans.net

[1]: https://sequel.jeremyevans.net

It seems that Active Record compatibility is being discussed here. It's kind of cool that all it took for Sequel to be async-compatible was to replace Thread.current with Fiber.current.

The problem that exposes is that of mass assignment. For example, the Ruby ORM library Sequel goes to some lengths to deal with it - but most popular frameworks are in a similar boat.