Hi Colin, no worries, responses below-
On Thu, Mar 5, 2015 at 2:31 PM, Colin Yates colin.ya...@gmail.com wrote:
Hi Jonah,
Coffee consumed, post read - thoughts emerging:
- so the 'context' is essentially a service registry as well as
run-time state?
More the latter- about transient,
Hi Jonah,
Coffee consumed, post read - thoughts emerging:
- so the 'context' is essentially a service registry as well as
run-time state?
- if 'renew-session' and 'return-renewed-token' both needed to
execute in a single transaction that was separate to
'some-thing-else', how would that be
Hi Colin- a simple example that uses a flow operator would be
(- context
do-something
do-some-io
do-a-last-thing )
with
(defn do-something [context]
(let [some-data (get-in context [:path :to :data :element])
result (pure-edge-function some-data)]
(assoc-in context [:path
Thanks Jonah - I will digest this over coffee...
On 5 March 2015 at 16:45, Jonah Benton jo...@jonah.com wrote:
Hi Colin- a simple example that uses a flow operator would be
(- context
do-something
do-some-io
do-a-last-thing )
with
(defn do-something [context]
(let [some-data
Hi Jonah,
This sounds very much like the model layer in DDD, which ironically is
exactly what I am building.
However, in the middle of a data flow a function needs to reach out to
a repository to make a decision - how does that fit in with the data
flow approach?
On 5 March 2015 at 13:39,
Yes, exactly.
That's fine, a node in the middle of the data flow can be responsible for
reaching out to the edge to synchronously get some data to feed into a
decision performed by the data flow. It would just do that through the edge
functions.
A request for data could also be asynchronously
Sounds interesting - are there are instances that I can look at?
On 5 March 2015 at 14:15, Jonah Benton jo...@jonah.com wrote:
Yes, exactly.
That's fine, a node in the middle of the data flow can be responsible for
reaching out to the edge to synchronously get some data to feed into a
Hi Colin,
Another option, other than HOFs or dynamic binding, is what might be called
a data flow approach.
At the edge of the application are the functions that explicitly take
parameterized resources to perform edge state IO. These might be bare
functions, or they might be protocol
Hi,
I am looking for the Clojure equivalent of:
class Whatever {
@Transactional
void doSomething(IDoSomething one, IDoSomethingElse two) {
one.doSomething()
two.doSomething()
}
}
where both one and two are dependency injected with a proxy which resolves
to a thread
And just to be clear - I get _why_ explicit parameter passing is a good
idea, or rather why dynamic binding is frowned upon, I am asking for
practical help with the consequences of that decision.
I also get the argument that a transaction changes at runtime state and so
shouldn't be part of
Having never used Spring (or anything else resembling the style of code you
presented) I don't really know if I'm understanding what you're asking.
However, it might be useful to wrap your database in a component. I do this
for Datomic all of the time, and the boilerplate looks something like
Ah I think I understand now! Is it possible to dereference the connection
and hold on to the thread local state? If so, then dynamically binding
the transactional connection and doing all of your work within that context
might be a good solution. You can also write a macro to do this,
In my previous project we were using high order functions to wrap
everything in a transaction.
So we would have stuff like this:
(require [clojure.java.jdbc :as db])
(defn create-foo-entity [entity]
[(fn [conn] (db/insert! ...))])
(defn create-bar-entity [entity]
[(fn [conn] (db/insert!
Hi Adrian, and thanks for replying.
I understand your point, but the subtlety is that a transactional
connection is per function invocation where as the database component
is per Component lifecycle - passing the db around isn't sufficient
here.
Spring plumbing binds a transactional connection
(if it's just a regular ThreadLocal, you should be able to get its value
through (.get tx))
To elucidate briefly, I mean something like this:
(def ^:dynamic *tx*)
;; elsewhere
(binding [*tx* (.get tx)]
...do stuff
...cleanup)
a with-tx macro would make this pattern reusable throughout
Yeah, that is the conclusion I came to, dynamic binding for the win, I
think :).
On 4 Mar 2015 18:47, adrian.med...@mail.yu.edu wrote:
(if it's just a regular ThreadLocal, you should be able to get its value
through (.get tx))
To elucidate briefly, I mean something like this:
(def ^:dynamic
16 matches
Mail list logo
