This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # aws (4)
- # beginners (16)
- # cider (9)
- # cljs-dev (3)
- # cljsrn (2)
- # clojure (46)
- # clojure-brasil (1)
- # clojure-spec (3)
- # clojure-uk (4)
- # clojurescript (46)
- # cursive (26)
- # duct (1)
- # emacs (31)
- # figwheel (1)
- # fulcro (9)
- # graalvm (21)
- # kaocha (1)
- # nyc (1)
- # off-topic (4)
- # pathom (6)
- # planck (45)
- # re-frame (2)
- # reagent (11)
- # ring (5)
- # rum (9)
- # spacemacs (2)
- # sql (60)
- # tools-deps (3)
[org.clojure/clojure "1.10.0"] [org.clojure/java.jdbc "0.7.9"] [org.xerial/sqlite-jdbc "188.8.131.52"]
how can i write a query that would give me (with those tables above) info about a report with info about all of the file pointers as a list
The newline broke things because you ended up calling
and that's an illegal SQL statement -- SQLite's error is less than helpful.
(jdbc/db-do-commands db " ")
-- :name get-all-reports -- :command :query -- :result :many SELECT r.id, r.blob, r.explanation, fp.start_line FROM REPORTS r LEFT JOIN FILE_POINTERS fp ON r.id == fp.report
SQL was made to optimize storage space and fit a formal description of relational data
my bigggest gripe with sql has always been that I couldn't represent "many of a thing"
which made me think that there might be some sql query i could do to manifest "many of a thing"
I'm not aware of any that document their internals well, I think they just do many queries or the reduce, depending on optimizations
You might be able to do something clever using the json features in postgres, I think a colleague did so, but can't recall the details.
(part of this is coming from a "wow it would be really cool to not have to figure out all my access patterns for mongo/dynamo to support a graphql schema"
There always going to have to be some domain-specific glue code when going from a table-centric view (sql) to a graph view (graphql)
We did a lot of work to get postgres to return the whole gql query in one, I believe it used the json features.
What ORMs do is exactly what @seancorfield mentioned. They post-process the resultset by reducing over it and transforming it into an Object hierarchy.
Yeah, because document stores are designed for horizontal scale out. In theory, you could build them to be optimal on many queries, but no one build vertically scaling DBs anymore