ROM
Sequel
Our great sponsors
ROM | Sequel | |
---|---|---|
4 | 21 | |
1,998 | 4,646 | |
0.3% | - | |
9.0 | 9.0 | |
about 2 months ago | 6 days ago | |
Ruby | Ruby | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ROM
-
Rails is not written in Ruby
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/
-
Catching up on things
Better gems. dry-rb, ROM, and Hanami are doing interesting stuff. I also hear web_pipe is popular?
-
10 Years of Open Source
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.
-
Best of (Ruby) Gems Series - What's Next? What's Hot?
Ruby Object Mapper
Sequel
-
I need to write a database query language. I have a blank sheet of paper.
Sequel
-
To Thread or Not to Thread: An In-Depth Look at Ruby’s Execution Models
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).
-
Ask HN: What are some examples of elegant software?
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.
-
"ORMs have a special place in my heart, not entirely unlike Brutus and Caesar: a dear friend who betrays you and leaves you to die a slow, painful death." – Taming SQL and ORMs with sqlc
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.
- Migrating from SQLite to PostgreSQL
-
It is OK for your open source project not to have a public bug tracker
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
-
Roda: Simplicity, Reliability, Extensibility & Performance by Jeremy Evans
Sequel
-
Where is Ruby Headed in 2021?
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.
-
Async Ruby
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.
-
Little known vulnerability with SQL wrappers
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.
What are some alternatives?
ActiveRecord
DataMapper
Hanami::Model - Ruby persistence framework with entities and repositories
Redis-Objects - Map Redis types directly to Ruby objects
Ohm - Object-Hash Mapping for Redis
Mongoid - Ruby ODM framework for MongoDB
NoBrainer - Ruby ORM for RethinkDB
Async Ruby - An awesome asynchronous event-driven reactor for Ruby.