Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

  • sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    arrow-up
    2
    ·
    2 months ago

    Ah, I see. So you’re expecting to have one object for creation, updates, queries, etc.

    I work with something like that at work (SQLAlchemy in Python), and I honestly prefer the Diesel design. I build an object for exactly what I need, so I’ll have a handful of related types used for different purposes. In Python, we have a lot of “contains_eager” calls to ensure data isn’t lazy loaded, and it really clutters up the code. With Diesel, that’s not necessary because I just don’t include data that I don’t need for that operation. Then again, I’m not generally a fan of ORMs and prefer to write SQL, so that’s where I’m coming from.

    • nebeker@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      One of my main concerns with this is the potential for making a lot of separate calls to the DB for a complex data structure. Then again there are trade offs to any architecture.

      • sugar_in_your_tea@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        2 months ago

        Isn’t the reverse true? If you make separate models for each query, the ORM knows exactly what data you need, so it can fetch it all as once. If you use generic models, the ORM needs to guess, and many revert to lazy loading if it’s not sure (i.e. lots of queries).

        That’s at least my experience with SQLAlchemy, we put a lot of effort in to reduce those extra calls because we’re using complex, generalized structures.