4 ms·

I don't know how I could manage deployments as effectively as I do today without Migrations. And i don't know how I could ever write DB functions more clever t

I don't know how I could manage deployments as effectively as I do today without Migrations. And i don't know how I could ever write DB functions more clever than, say, the ones DataMapper gives me. And I don't know how anybody could prefer "Select * from TableOne Inner Join TableTwo using(SomeCol) Inner Join TableThree using(OtherCol) where TableOne.foo = ? and TableOne.bar = ?" to, say, ORMs at their best: result = TableOne.findByFooAndBar("foo", "bar");

jasonlotito 15y ago
> result = TableOne.findByFooAndBar("foo", "bar"); This doesn't give me the same information as the SQL. This, for example, doesn't tell me it's doing an Inner Join on two tables. Being that I know the query you are replicating here, I can assume either it's automatically joining all tables that are related to the table I'm calling. In which case, how do I get a result while only joining specific tables (or none), or the more likely case, it's not doing any join, and waiting until I actually call the object, whereby it performs the query on the table. Simply put, the SQL query tells me exactly what is being called. The ORM does not, and hides away what it's doing. Granted, this is your example, but it's also easy to find this same style in ORMs in the wild. I'm on the bench about ORMs myself. I use one, and enjoy it's use. However, it's also annoying because I'm comfortable with SQL and can whip up a query faster than I can wrestle the ORM to do what I want.
- encoderer 15y ago
  It's about convention over configuration. Learn a few conventions (not hard) and there you go. In some ORM's, the magic findByX functions will do no joins -- in others it will do all joins. And learning which is quite easy. And almost universarlly, the findByFooAndBar type magic methods are not the most commonly used feature because often you need complex conditionals (let alone complex joins). But when you do need just a quick record, it's wonderfully easy. You can get cozy with an ORM in an afternoon. After that, you've got nothing ahead of you but timesaves. Sure, sometimes the ORM abstraction will break or you'll find yourself fighting it. So at that point you use the ORMs connection manager to execute some raw SQL and be on your way. Your argument, to me sounds as wrong as if you said "I don't like MVC frameworks. Without a frameowork, I know that when I go to www.example.com/path/to/index.php I know exactly what is being called. But in an MVC, www.example.com/path/to could be anything! The routing engine and framework hides away what it's doing. But I use it because it's not really as opaque as you portray, and it saves me SO. MUCH. TIME. And once you learn convention, the ORM makes it EASIER to grok any codebase that uses it than it would if they used straight SQL. Anyway, as always, YMMV and I respect your fence-riding. I've used some unfortunate ORM's before (CakePHP I'm looking at you! Adopt Doctrine!) where instead of writing a simple query I'm stuck crafting some insane nested dictionary structure.
  - artmageddon 15y ago
    Do you recommend any particular good (free preferably) ORMs to practice with? Never used one before in my day to day job :(
    - encoderer 15y ago
      Really I'd find the best one for whatever language you're strongest with. My absolute favorite, bar none, is Ruby's DataMapper. In PHP, the best ORM project is certainly Doctrine. Doctrine can be a little overwhelming at first, but it's worth it. However if you found yourself just not pursuing it because of its complexity, I've found that the Kohana framework has a quaint, easy to use ORM. Not a bad start. In Python, SQLAlchemy is great. In .Net obviously LINQ.
      - Johngibb 15y ago
        .NET also has NHibernate. I'm not intimately familiar with the pros/cons of LINQ to SQL vs NHibernate, but I believe it gives you a lot more control over things like pre-loading associations, etc (while requiring a lot more configuration).
        stonemetal 15y ago
        One con of LINQ to SQL is that it only supports MS's DBs. LINQ to Entities is the more flexible version. Though you have to go whole hog and use Entity Framework. There is also a active record implementation for .NET called castle active record.
        notJim 15y ago
        > One con of LINQ to SQL is that it only supports MS's DBs. This is not true for Entity Framework (which is essentially the newest iteration of Linq2Sql.) I have successfully used EF with SQLite in production, and it appears to have a MySQL driver as well (I honestly don't know how well the MySQL driver works.)

jasonlotito 15y ago

> result = TableOne.findByFooAndBar("foo", "bar"); This doesn't give me the same information as the SQL. This, for example, doesn't tell me it's doing an Inner Join on two tables. Being that I know the query you are replicating here, I can assume either it's automatically joining all tables that are related to the table I'm calling. In which case, how do I get a result while only joining specific tables (or none), or the more likely case, it's not doing any join, and waiting until I actually call the object, whereby it performs the query on the table. Simply put, the SQL query tells me exactly what is being called. The ORM does not, and hides away what it's doing. Granted, this is your example, but it's also easy to find this same style in ORMs in the wild. I'm on the bench about ORMs myself. I use one, and enjoy it's use. However, it's also annoying because I'm comfortable with SQL and can whip up a query faster than I can wrestle the ORM to do what I want.

encoderer 15y ago
It's about convention over configuration. Learn a few conventions (not hard) and there you go. In some ORM's, the magic findByX functions will do no joins -- in others it will do all joins. And learning which is quite easy. And almost universarlly, the findByFooAndBar type magic methods are not the most commonly used feature because often you need complex conditionals (let alone complex joins). But when you do need just a quick record, it's wonderfully easy. You can get cozy with an ORM in an afternoon. After that, you've got nothing ahead of you but timesaves. Sure, sometimes the ORM abstraction will break or you'll find yourself fighting it. So at that point you use the ORMs connection manager to execute some raw SQL and be on your way. Your argument, to me sounds as wrong as if you said "I don't like MVC frameworks. Without a frameowork, I know that when I go to www.example.com/path/to/index.php I know exactly what is being called. But in an MVC, www.example.com/path/to could be anything! The routing engine and framework hides away what it's doing. But I use it because it's not really as opaque as you portray, and it saves me SO. MUCH. TIME. And once you learn convention, the ORM makes it EASIER to grok any codebase that uses it than it would if they used straight SQL. Anyway, as always, YMMV and I respect your fence-riding. I've used some unfortunate ORM's before (CakePHP I'm looking at you! Adopt Doctrine!) where instead of writing a simple query I'm stuck crafting some insane nested dictionary structure.
- artmageddon 15y ago
  Do you recommend any particular good (free preferably) ORMs to practice with? Never used one before in my day to day job :(
  - encoderer 15y ago
    Really I'd find the best one for whatever language you're strongest with. My absolute favorite, bar none, is Ruby's DataMapper. In PHP, the best ORM project is certainly Doctrine. Doctrine can be a little overwhelming at first, but it's worth it. However if you found yourself just not pursuing it because of its complexity, I've found that the Kohana framework has a quaint, easy to use ORM. Not a bad start. In Python, SQLAlchemy is great. In .Net obviously LINQ.
    - Johngibb 15y ago
      .NET also has NHibernate. I'm not intimately familiar with the pros/cons of LINQ to SQL vs NHibernate, but I believe it gives you a lot more control over things like pre-loading associations, etc (while requiring a lot more configuration).
      - stonemetal 15y ago
        One con of LINQ to SQL is that it only supports MS's DBs. LINQ to Entities is the more flexible version. Though you have to go whole hog and use Entity Framework. There is also a active record implementation for .NET called castle active record.
        notJim 15y ago
        > One con of LINQ to SQL is that it only supports MS's DBs. This is not true for Entity Framework (which is essentially the newest iteration of Linq2Sql.) I have successfully used EF with SQLite in production, and it appears to have a MySQL driver as well (I honestly don't know how well the MySQL driver works.)