This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-20
Channels
- # aws-lambda (7)
- # beginners (113)
- # boot (17)
- # cider (4)
- # cljs-dev (4)
- # clojure (65)
- # clojure-greece (3)
- # clojure-italy (7)
- # clojure-russia (10)
- # clojure-spec (37)
- # clojure-uk (20)
- # clojurescript (76)
- # community-development (2)
- # cursive (24)
- # data-science (9)
- # datomic (9)
- # emacs (1)
- # fulcro (2)
- # graphql (11)
- # hoplon (13)
- # juxt (15)
- # leiningen (1)
- # off-topic (36)
- # om (1)
- # onyx (59)
- # parinfer (41)
- # pedestal (7)
- # portkey (60)
- # protorepl (4)
- # re-frame (345)
- # reagent (7)
- # ring-swagger (16)
- # shadow-cljs (121)
- # spacemacs (30)
- # sql (6)
- # uncomplicate (2)
- # unrepl (9)
- # vim (13)
- # yada (2)
do you know guys of anything like 'parameterized views' in SQL (in the sense of views that accept other relations as parameters), either in the industry or in research?
I've really come to think of the query part of SQL as an expression-based language (similar to lambda calculus), in which the values are relations, and the basic operations are joining, filtering, projecting etc. So I find SQL to be like a lambda-calculus language that doesn't have functions, expect maybe for views which are like 0-arity functions. That's too bad!
For example: on a recent project I did with a significant part SQL, I've really missed such a feature, especially for aggregations - e.g I'd like to be able to define a view which computes the age distribution of a set of persons, which would precisely be parameterized by any relations of person, allowing to compose the aggregating logic with any filtering logic.
Does this resonate with anyone here? I'd love to find projects or articles on this topic, but don't know where to look.
@U11SJ6Q0K Maybe temporary stored procedures then - I wouldn't want them to be stored globally / durably, just like I prefer temporary views to regular views
You'd get better perf by having stored (materialized) views.
there's a lot of overhead in creating queries/views just to throw them away
@U07TDTQNL I'm not yet down to the current engineering details of popular database engines 🙂 right now I'm just wondering what prior work exists about the general concept
What's more, on my current project, I've been fine with the overhead of temporary views (Postgresql). Especially if I only have to pay the price of that overhead once per long-running connection.
So materialized views are pretty cool. You define a view in the terms of a query. The DB then creates a fake table, whenever data is updated that would change the result of that query it updates the view automatically.
So it's a great way to reduce query times since it works like a cache for queries and for bits of queries that are compute heavy
http://www.revsys.com/blog/2006/jan/03/when-to-use-a-materialized-view-in-postgresql/
Automatically? Is that a new feature. At least in pg 9.5 you need to manually refresh materialized views.
This is completely serious -- not trolling at all. So I have been spending quite a bit of time binding a scala lib in Clojure lately -- and I kinda like Scala's type system for part of the work. There's also Scala.js which mjirrors cljs nicely. I'm wondering if anyone has experience coding in clojure + scala, where for the more "dynamic / situated" parts of the code, you use clojure, and the more "compiler / theorem prover" part, you implement it in scala. (Yes, I knowa bout spec / core.typed, but I'm really looking for a haskell-like type system.)
The main obstacles right now are: 1. A lot of my code is *.cljc ; I'm not sure how it's goingto work with scala + scala.js, as I'll need cljs + scala.js to play nicely in addition to clj + scala (which I already sort of have placing nicely.) 2. sexp editing is great, scala syntax breaks alot of that
@qqq Scala.js javascript interop is pretty nice actually. https://www.scala-js.org/doc/interoperability/export-to-javascript.html, https://www.scala-js.org/doc/interoperability/index.html.
Avoid Long, since that's not actually a JS type though. You can marshall everything around using native JS types. Trying to actually use native Scala types would probably be more hassle than it's worth
I did a lot of work on the scala.js dom library, generally if you can expose a nice interface for Javascript on the clojurescript side, you can do a pretty good job of strapping some typesafety to it on the Scala.js side, the same is true exposing Scala.js to JS
An observation of mine: #clojurescript seems much more active than #clojure. That's kind of cool. I'm not sure if it indicates that people simply need more help with it, or that front end in clojure is becoming more popular.
Also, there's a lot of JS on the backend now, with node and such. I assume it's just as viable to write backend cljs?
There is lumo for that: https://github.com/anmonteiro/lumo
I haven't played with it that much, but it looks neat for writing system scripts in cljs.
Thank you for taking this to #off-topic -- much appreciated!
And there's a #parinfer channel here, if you need it!
Parinfer was a little jarring at first while I was still learning syntax, but now I’d never switch back
https://gist.github.com/anonymous/62370f0f33fd16eaca282d6934c8b165 <-- how do I tell 'lein' to open up a nrepl on a particular port? googling brings up "lein connect .... " which isa bout lein acting as a CLIENT, but not a SERVER of nrepl