1. 10
  1.  

  2. 6

    One of the nice thing about Ecto over in Elixir is that is forces you to load associations, thereby avoiding some of the crazy stuff ORMs like ActiveRecord might let you do if you aren’t vigilant.

    Sometimes, explicit tools are better.

    1. 2

      The only thing you can achieve using lazy loading in a web application is extra database calls you could avoid.

      There are exceptions. If the customer.orders would be used in a view partial, and that partial has already been rendered and cached on a previous request, lazy loading means that you don’t have to load the orders at all during this request. It’s “load ’em if you need ’em.”

      But on the whole, I agree with the author. N+1 problems are easy to create and time-consuming to prevent in Rails. And I speculate that partial caching (which requires a key-val store and some configuration) is only needed because Rails views are slow. See Phoenix for comparison, where views are fast and Ecto doesn’t support lazy loading. http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io-lists-in-phoenix/

      1. 1

        It’s impractical in popular imperative languages, but I’d really like to write the same queries + data use in template that I do now, but have the framework/compiler kick off anything query it knows I’ll use the result of in a background thread that doesn’t block unless the template wants to start using the data before the database is done sending it. It’d be a great little speed improvement for nearly every request, but not so nice that I want to see anything more in my code than maybe a couple characters of syntax or a single type wrapper to do it.

        1. 1

          In [a desktop app] scenario lazy loading is very convenient and makes sense.

          When it does not is in a web application. That’s because the context will not exist during more than one user interaction. It’s just not possible.

          Is that so? In WebObjects/EOF, you had an EOEditingContext associated with your WOSession object, and you could mess around with the data in the EOEditingContext as much as you liked while the WOSession was around. Do Hibernate et al somehow stop you from having long-lived context objects? So you have to create new contexts and do all the stuff in one request? What about multi-step actions where you might want to roll back the whole thing after a series of user actions?

          1. 1

            Lazy loading is better than loading null which is what this page seems to propose as an alternative. Better to have a poorly-performing N+1 query than have your page just error. Also lazy loading doesn’t necessitate an N+1 query - more often you’d load the whole collection as soon as it’s accessed, making it 1+1 queries.

            You can have different representations for customer and customer-with-orders, but that’s not free. Or you can always do the load, but most of the time you want a customer you don’t want their orders.

            ORMs, lazy loading and web applications are a great fit when ease of development and correctness is more important than performance, which is probably 95% of the time.