Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
- Hi, welcome. My talk today is on an ORM I wrote called Ruby Preserves. My name's Craig Buchek and I'm an independent web developer. I've been doing Rails and Ruby since about 2006. I'm also a big fan of Agile, I do a podcast called This Agile Life, you can check that out.
So, I started writing an Ruby ORM last year and it's surprisingly small. So, I suppose you could call it a micro ORM. It's missing some features that most ORMs would have, but it has some features that other micro ORMs don't have, actually. So, I wanna make sure we know what an ORM is.
An ORM is an object relation mapper, so, an SQL database deals with relations, there's something called relational algebra, and Ruby deals with objects. And so, those two sides actually work differently, and an ORM brings those two sides together. There's a few caveats with that, there's something that people call an impedance mismatch because things don't always work the same.
One example is a tree structure. A tree structure in an object orient language is pretty simple, you must have pointers, or links, or contain has relationships. That's not so easy to do in SQL, there's a few different techniques. You have to map those two different techniques to go, to save things to a database or to pull 'em out of the database.
So, why would I write an ORM? Why would I tackle such a daunting task? First, I'm not really happy with any of the existing Ruby ORMs. I wanted to explore and learn. I've been interested in writing an ORM for a while. My colleague, Amos King, is in the audience, he often tells people, hey, you should write your own ORM.
And stupidly, I'd listen to him. Maybe I can learn enough to write my ideal ORM some day. They say if you wanna write something good, write one, throw it away, and then write a new one. So, in some ways, this is that. So, I'm gonna try to make mistakes and learn from them.
And hopefully, the second try will have a better architecture if I decide to do it that way. So, I just wanted to answer a few questions, ORMs are really complex 'cause if they have to be, how simple can we make one? What is the essence of an ORM? So, every ORM I've used has a DSL to help write SQL.
A DSL is a domain specific language. Usually, the problem is you usually end up having to write some SQL manually, yourself. That's called a leaky abstraction. That means the abstraction doesn't always work, sometimes, you have to go down to a lower level of abstraction.
So, what if we made the leaky abstraction leak all the way? And we just use SQL, we didn't use a DSL to help us write SQL. So, I started designing the ORM based on a few strong opinions. The thing that drives me most crazy about ActiveRecord is having to look in two places for things.
The relationships are defined in the model class, like the has many and the belongs to, and the attributes are defined in the database schema. So, I always hate when I have to go, when I'm trying to figure out how a model works, I have to look in those two different places.
I'm of the opinion that NoSQL is usually misguided. Most uses are not legitimate. I don't think most of us know or understand SQL long enough to know when we should reject it. I think the people that created SQL were pretty darn smart, I don't think I'm smarter than them when it comes to SQL and database stuff.
The other thing is Postgres can do just about anything you need, including most of what a new SQL database does. It still uses SQL, though. Sarah Mei has a great article on why never use MongoDB, and basically, the gist of it id you're going to paint yourself in a corner, but that corner, you're not gonna see until you're about a year down the road.
I was talking to someone at Stripe about this, they use MongoDB as their primary storage, and they ran into that problem, and what they're doing now is they actually consistently, constantly copy the data from MongoDB into a Postgres database for ad hoc queries.
So, how many of you have ever switched database vendors on a single project? All right, only a few hands. Was it just an easy change your database YML file? I don't see any hands on that one. So, ya ain't gonna need it. You're probably not gonna need it. Why are we preparing for something that's probably not gonna happen, and if it does, you're probably gonna have to do a lot more work anyway? These days, a developer work station is fast enough to run a full database system.
It makes sense to do all your development in the same way as production, so if you're using Postgres in production, you should try, if you possibly can, to use Postgres in dev. So, this is definitely, with current hardware, this is definitely feasible for Postgres in my SQL.
If you use an Oracle or SQL server, that may or may not be feasible. That's probably more due to licensing than the hardware abilities. There are some express versions that probably work though. And even if you do change databases, it's never easy unless your app is really simple, which means you probably didn't need to change the database for any reason.
So, who loves ActiveRecord? Raise your hand. All right, a dozen or so. Who hates ActiveRecord? All right, about a dozen or so. Who raised their hand both times? All right, a few. I'm mostly in the hate camp. But we have to deal with it. Who's mainly had to type in SQL in an ActiveRecord class? Yeah, that's like a couple dozen.
So, ActiveRecord is a leaky abstraction. SQL leaked up in the upper layers. But ActiveRecord's the 800 pound gorilla, every Rubyist knows it, it's well tested. Frankly, it's just easy to start using it. You don't even have to think about it if you're using Rails.
[ ... ]
Nota: se han omitido las otras 2.765 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.