Fork me on GitHub

Is there a channel to discuss database approaches? Sql, nosql, Datomic, data mapping etc?


There's #sql and there's also #datomic and #honeysql


(I'm active in two of those)


I think #sql is the most general...


I'm looking for a map that when you get, if the key isn't there, should block until the key is added. does this exist or is there an easy way to create it?


@orestis if you're new to databases, #postgresql on freenode is a really solid place to level up with experts. some of the regulars maintain popular ORMs including DBI.


@matt220 I’m not exactly new, but I don’t think I ever dedicated any serious amounts of thought to relational modeling. Hammock time, if you will.

Hendrik Poernama12:05:35

@wei not sure if it already exists, but you can extend ILookup


it's a way to split a namespace across multiple files


one that has turned out not to be popular


I’m trying to use pprint with GraalVM and this trips it up it seems


try AOT compling it beforehand maybe


clojure.core loads too, but is AOT compiled


My approach is to create an uberjar with aot all and feed that jar to native-image.


with -H:+ReportUnsupportedElementsAtRuntime pprint and tools.cli seem to just work... which is contraintuitive because then I would expect an error at runtime


But maybe the clj file is also in the uberjar which may cause the error in the first place?


There are some things GraalVM can't do in native image. Like creating dynamic classes, but I don't know why that would be needed for pprint.


I don’t know. I removed the .clj files from the uberjar now but it still doesn’t work without the above mentioned option.


Ah, there are multiple issues there. But with the above mentioned option it all works fine at runtime…


Maybe because pp rely upon reflection and it’s not supported by graal


@orestis gotcha! so, my conclusions from hammock time are usually around: what structure best supports accurate/efficient query?


Is there a way to run a clojure code under some context. I am writing a wrapper for FoundationDB. The problem is that in java code you can write anything in lambda and it will work under a transaction. But in Clojure I want to write a similar thing where you can pass the actions you want to do in some sort of do block. Problem is functions in action block require tr and hence I can't put it in #() and pass it there. Also I think Clojure macros doesn't support reify and only applicable to primitive that makes macros not possible. I think I am approaching it the wrong way.

private static void setVal(TransactionContext db, final String key, String value) { tr) -> { tr.set(key, value); });

(defn set-val [db key value]
 (.run db
   (apply [this tr]
    (.set tr key value)))))

;; desired code
(defn tr! [db actions]
 (.run db
   (apply [this tr]
    (actions))))) ;; actions need tr as a parameter in the declaration itself
` Something like carmine does at :
  (car/set "foo" "bar"))


If you want to achieve something like Carmine, I recommend that you look at how Carmine does it 🙂


that basic idea is a with-context that binds a dynamic variable *context* to a new local context:


the commands like ping etc then uses the local binding for the *context* var


but personally I prefer if the macro sets up a named variable that you explicitly pass in (like your current apply function), rather than having implicit contexts, because it can make testing and mocking easier and to me it makes the code more readable


Thanks a lot for the pointers. I used the same approach. I read somewhere that reify doesn't work with macro. It works like normal code generation.


@orestis as far as ORM per se, i don't like them, but i recognize that the product-space is polluted. what i recommend is an object-mapper, so you can conveniently work with language-native structures like dates/collections/strings/numbers as such. i rather like how jdbc in clojure sticks to simple vectors and maps.


Walkable is definitely on my list!


I am burned by the usual ORMs like Django, but OTOH something like Elixir’s Ecto is much more palatable.


i'll check out walkable. that looks neat. i sure get a lot out of jdbc though.


@wei I have not heard of such a thing, but am I right in thinking that this must be a mutable data structure? If it is immutable, then how would a key become added to it after you called a blocking get with that map?


thanks @andy.fingerhut, I was thinking it would be an atom or perhaps a map of channels. would prefer something simple. (for context, looking for a data structure that blocks on get when the key is not there, but returns immediately when it is)


If you want a static set of keys, then a Clojure map of that constant set of keys, each with an associated data value that is a channel, sounds workable with little or no new code to develop, but I do not see how to make that work if you want a set of keys that changes dynamically over time, e.g. that you do a get on for a key K that does not exist in the map at the time of the get, but some other thread does an assoc later with key K.


I have not used Clojure's add-watch before, but it might be possible to implement your idea with it.


add-watch seems like it might work. I was originally thinking one of the compound core.async structures like mix or pub sub, but I haven't used them before so not sure if it's a good fit


has anyone used clucy A Clojure interface to the Lucene search engine


I would like to do a full text search on data structure like this [{:key "key" :value "large text"} {} ...] on the value, I want to create the index and add the clojure map to the index everytime I get http search request, is that efficient


Yes @huthayfa.ainqawi I've used it. I keep the index in ram and it is instant.


@mfikes do you mean the index creation is instant or the search is instant. if I don't wanna keep the index in the ram after the session end, is it still okay to use this library ?


@huthayfa.ainqawi Index creation takes a while. It is the search that is instant.


anyone come across amazonica and eastwood not playing nicely? What's the best way of disabling wrong-arity for the entire library. Amazonica takes varargs everywhere 😕 Example error:

test/com/unbounce/yopa/integration_tests.clj:67:28: wrong-arity: Function on var #' called with 8 args, but it is only known to take one of the following args: [receive-message-request]  [string]


@rymndhng Did you ask in the #eastwood channel?


You can easily disable wrong-arity (or any other type of warning) globally from the Eastwood command line, or REPL function invocation (whichever you happen to use), but that would disable it for the rest of your project, too.


You could invoke Eastwood separately on different groups of namespaces with different options, too.


I have forgotten the details at the moment, but I know there is a thing that some functions and macros do to document their arguments in some :arglist or :arglists metadata on the Var, and some try to make that nice for humans, but not useful for programmatic parsing, which I believe can cause incorrect wrong-arity warnings


Ah, I wrote a section in the Eastwood docs for each kind of warning, explaining some details about it. Here is the one for wrong-arity, explaining one way to make a config file for Eastwood to change the :arglists metadata it uses for a Var, other than the one the author wrote for it.