• QuazarOmega@lemy.lol
    link
    fedilink
    arrow-up
    8
    arrow-down
    6
    ·
    edit-2
    11 months ago

    Me trying to remember on whose output data having, count, sum, etc. work

    Once you know functions you would have no reason to go back.
    I propose we make SQL into this:

    const MAX_AMOUNT = 42, MIN_BATCHES = 2
    
    database
        .from(table)
        .where(
            (amount) => amount < MAX_AMOUNT,
            table.field3
        )
        .select(table.field1, table.field3)
        .group_by(table.field1)
        .having(
            (id) => count(id) >MIN_BATCHES
            table.field0
        )
    

    (Sorry for any glaring mistakes, I’m too lazy right now to know what I’m doing)

    …and I bet I just reinvented the wheel, maybe some JavaScript ORM?

    • expr@programming.dev
      link
      fedilink
      arrow-up
      6
      arrow-down
      2
      ·
      edit-2
      11 months ago

      Because you never learned SQL properly, from the sound of it.

      Also, ORMs produce trash queries and are never expressive enough.

      • emptyother@programming.dev
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        11 months ago

        ORMs produce good queries if you know what you do. Which requires proper knowledge of SQL, unfortunately.

      • QuazarOmega@lemy.lol
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        edit-2
        11 months ago

        Because you never learned SQL properly, from the sound of it.

        You might be right, though, to be fair, I also keep forgetting syntax of stuff when I don’t use it very often (read SQL (._.`))

        Also, ORMa produce trash queries and are never expressive enough.

        I meant to say that I would like the raw SQL syntax to be more similar to other programming languages to avoid needing to switch between thinking about different flows of logic

    • marcos@lemmy.world
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      11 months ago

      Well, if you lose the OOPism of those dots, we can talk.

      Anyway, I’m really against the “having” tag. You need another keyword so that you can apply your filter after the group by?

      • QuazarOmega@lemy.lol
        link
        fedilink
        arrow-up
        2
        ·
        11 months ago

        Well, if you lose the OOPism of those dots, we can talk.

        That’s a good point, I didn’t even think about it, maybe a more functional style would make more sense?

        • marcos@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          11 months ago

          Yes, I do. It’s a lot of effort and hidden functionality to try to paper over the fact that the statements do not compose.

      • Baby Shoggoth [she/her]@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        0
        ·
        11 months ago

        having is less annoying way of not doing needless/bug-prone repetition. if you select someCalculatedValue(someInput) as lol you can add having lol > 42 in mysql, whereas without (ie in pgsql) you’d need to do where someCalculatedValue(someInput) > 42, and make sure changes to that call stay in sync despite how far apart they are in a complex sql statement.

        • Doc Avid Mornington@midwest.social
          link
          fedilink
          English
          arrow-up
          1
          ·
          11 months ago

          Postgres has the having clause. If it didn’t, that wouldn’t work, as you can’t use aggregates in a where. If you have to make do without having, for some reason, you can use a subquery, something like select * from (select someCalculatedValue(someInput) as lol) as stuff where lol > 42, which is very verbose, but doesn’t cause the sync problem.

          Also, I don’t think they were saying the capability having gives is bad, but that a new query language should be designed such that you get that capability without it.

      • QuazarOmega@lemy.lol
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        11 months ago

        Thanks for the suggestion! It looks interesting, not quite what I expected looking at that file*, but that may very well be better

        Edit: other examples seem a bit more similar to mine, cool!

    • drathvedro@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      11 months ago

      No. The arrow function in where eliminates any possibility of using indexes. And how do you propose to deal with logical expressions without resorting to shit like .orWhereNot() and callback hell? And, most importantly, what about joins?