6 ms·

Personally, in developing quite a lot of different data-backed apps, I've never really found the problem ORMs are solving to be a hugely significant one; it see

• MartinCron 15y ago
  I'm definitely an old-school code-sql-by-hand guy and I used an ORM (Entity Framework 4.0 Code-First) for the first time for my startup project, a data-intensive online strategy game. I've found that for many things, it's so much faster in terms of dev time, especially with the super-cool code-first approach, to get things out there and working using the ORM. I can create a new fully-functioning and reliably-working repository class, along with its test double, in around a minute. Really. Of course, I have found that I've had to replace bits of it with hand-coded SQL for performance reasons. But I've decided to stick this general approach for now because I don't need to substantially rearchitect everything, I can just replace the very few bits that have proven to be an actual performance bottleneck, and keep the development speed for the many places where runtime speed just doesn't matter as much.
  • smhinsey 15y ago
    I don't mean to start an argument over which ORM you want to go with, but you might want to give this a look, if you're interested in being able to quickly iterate on a data model and still have test coverage: http://wiki.fluentnhibernate.org/Persistence_specification_testing http://wiki.fluentnhibernate.org/Persistence_specification_t....
    • MartinCron 15y ago
      Cool. Thanks for sharing.
      • smhinsey 15y ago
        No problem. Do you have any info about your startup? I have been working on a similar idea as a back-burner thing for years but I'm in the process of doing a different startup, so I think it'll stay there.
        • MartinCron 15y ago
          http://victorsunited.com http://victorsunited.com It's a turn-based, (largely) asynchronous, strategic conquest game that uses the same ruleset as a classic board game that you probably played when you were a kid. The idea is to create a social game that you're not embarrassed to play. You know the trend of people getting together in bars to play Settlers of Catan for hours on Friday nights? We're trying to make a game that same people would want to play for a few minutes at a time from their office on Monday morning. I've got a half-written article about how we're doing some cool continuous deployment stuff that I plan on sharing with HN soon. In the meantime, any and all feedback is welcome.
          • sixtofour 15y ago
            Looking forward to the continuous deployment article.
          • Egregore 15y ago
            I was interested in your game, I played Galaxy PBEM some time ago, but you have few flaws: 1. You assume that everybody played board game, which I haven't, so you don't have an easy introduction for a new player. 2. You have single player game, but you set up a high barrier to try it, I don't understand why you need logging in when a cookie will be enough.
            • MartinCron 15y ago
• ianterrell 15y ago
  It's hard to believe this isn't just trolling. Writing a large app directly using SQL is not "hard," but A) it's exceptionally boring, B)it necessitates mental context shifting from your app language to SQL, and C) it requires you to think about nuts and bolts routine below-your-paygrade solved concerns like SQL injection, transaction management, type casting, etc. Two more points: I've never seen a large app that either didn't use a popular ORM or didn't end up REINVENTING large chunks of functionality ORMs provide. Good developers write DRY code, and SQL everywhere leads to, eventually, some library that looks remarkably like... an ORM... Finally, in the case of large web applications (since that's HN's bread and butter), an ORM'd app will not need a "very substantial rearchitecting" to get rid of the ORM. That statement is patently absurd. Early in its life, for scaling (always, IF it becomes necessary) what it will need is dropping down to SQL to tune some aspects of some pages. Architect for doomsday if you like (or, conversely, if you need extra hours to bill) -- or architect to ship.
  • tieTYT 15y ago
    There are libraries out there that already reinvent the large chunks of functionality ORMs provide without requiring you to use an actual ORM. I think the middle ground is the best way to go here. Avoid ORMs, avoid native SQL, meet somewhere in the middle.
    • ryeguy 15y ago
      Like what?
      • rubashov 15y ago
        Perl has Fey. http://search.cpan.org/perldoc?Fey http://search.cpan.org/perldoc?Fey As ORMs go Fey::ORM (built on top of Fey) is good. It's easy to get under the hood and make it do exactly what you want. http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro http://search.cpan.org/perldoc?Fey::ORM::Manual::Intro
  • MartinCron 15y ago
    A) it's exceptionally boring Perhaps as a result of it being so exceptionally boring that it's so error-prone. If you forget to wire something up by hand (especially if its nullable) and don't notice while you're coding, it can be one of those subtle little bugs that lingers in the background until it really bites you. Also, you forgot: D) Difficult and time-consuming to create test automation for.
• rapind 15y ago
  It's not that SQL is hard, it's that it becomes very redundant very quickly. That being said, I use ORMs all the time, but have never really been a massive fan. There's always going to be a little bit of mismatch because object != relational. I find myself attracted to document databases simply because it feels like there's less of a disconnect between objects and documents. I do remember an ORM called iBATIS that wasn't too bad though. It actually made my classes look cleaner and didn't treat SQL like a red headed stepchild. These days, working with ARel doesn't make me feel too dirty.
• Spyro7 15y ago
  I have worked with ORMs and with raw SQL. In my personal experience, using raw SQL exclusively becomes time consuming when you need to make the jump between the raw sql results and objects. With a well designed ORM, it should be possible to have the best of both worlds. One of the features that I value in Django's builtin ORM is the ability to almost seamlessly drop down to raw SQL when needed: https://docs.djangoproject.com/en/dev/topics/db/sql/ https://docs.djangoproject.com/en/dev/topics/db/sql/
  • Swannie 15y ago
    "using raw SQL exclusively becomes time consuming when you need to make the jump between the raw sql results and objects" I don't find that to be true. You write the SQL, you've already written your Objects, you write a 2-3 line row -> object(s) mapper (supported by your own utils, or something like Spring). You have clear control and mapping between SQL and Object. This said, I like what I've seen and used of the Django ORM so far, but then my application has not been anywhere close to as complex as the "day job" RDBMS.
    • Zvez 15y ago
      If you have entity with 10 fields and 5 nested collections (which may also have more nested objects) and you need load full object for edit (and save it after), it will be more than '2-3 line'
• encoderer 15y ago
  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.
• ubernostrum 15y ago
  The problem with writing all your SQL "by hand" is that it's needless code duplication. Set aside databases for a moment. Let's say that instead we're going to generate a bunch of different types of documents, all in the same output format (PostScript or LaTeX or HTML or whatever). Which approach would you take to this problem? A) For each type of document, manually write out the necessary code from scratch, starting over again each time, or B) Write some general-purpose libraries which understand the output format and expose an API that you can call programmatically to generate the documents? I don't think anyone would choose (A) in this case. But many people do choose, and pride themselves on choosing it, as soon as we change from any other use case to generating database queries. Why do we suddenly have to throw away everything we know about writing libraries and avoiding duplication, just to pretend that typing out some SQL makes us "real programmers"? ORM, in essence, is nothing more than this: a convenient API you can call to do database queries. Why should it be so different?
  • MrMan 15y ago
    shocking vote up
• cageface 15y ago
  I was forced to port an existing in-house web app from Postgres to Oracle. Thanks to ActiveRecord I just made some tweaks to the db config file and didn't have to touch a line of code. Of course, it's not always this easy but a good ORM can buy you a lot of portability.