Jonas,
Definitely inspired by the ideas in Datomic.
My question was partially: "how can I implement the core immutability
semantics of Datomic in plain Clojure?".
(Say, hypothetically, that I need a Clojure datastore with flexible
schema and immutability semantics but cannot actually use Datomic for
business reasons.)
I gave it a shot this morning---writing code to serialize
{:a 1 :b 2}
into
[#Assertion{:id 1, :attribute :a, :value 1, :time 0},
#Assertion{:id 1, :attribute :b, :value 2, :time 0}]
and back again (which gets a bit more complex with references/
collections, but not much).
Nicolas,
Data can be kept anywhere that tuples can be kept = )
Caching intermediate values "diffs are collapsed" should definitely
bring a speedup.
The immutability semantics mean you really can go all out crazy with
the caching too.
On Jun 5, 1:44 am, "nicolas.o...@gmail.com" <nicolas.o...@gmail.com>
wrote:
> It is not totally clear in your post how you want to keep the data?
> Is it in memory (with a transactional log somewhere)?
> If it is the case, you can do better than reducing the whole data set
> when executing a query:
> you can keep a cache of query results, or indexed data and maintain
> it, while still being
> purely functional. (For example by attaching those results as meta
> data to the data structure, and
> defining your own assoc-like functions that maintain a consistency of
> the meta-dataed query results)
>
>
>
>
>
>
>
>
>
> On Tue, Jun 5, 2012 at 1:59 AM, Kevin Lynagh <ke...@keminglabs.com> wrote:
> > Has anyone seen or implemented a CRUD application in Clojure using a
> > database of immutable facts?
>
> > For instance, a traditional database table supporting a todo-list
> > application has columns
>
> > user_id, task_id, task_description, is_done
>
> > A new row is created when a user adds a task.
> > Then that row is updated so is_done = TRUE when the user checks the
> > task off.
>
> > With immutable facts this would instead be a collection of statements:
>
> > User U added task T with description D at time T1
> > User U completed task T at time T2
>
> > To get a list of unfinished tasks for a user, you'd need to grab all
> > the tasks from this "transaction log", put them into a data structure,
> > and then remove ones when you learn that they've been completed.
> > Whatever is left over is the todo list.
>
> > Nathan Marz talked about this in terms of big data:
>
> > http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
>
> > and Datomic's big bet is that your life as a developer gets much
> > easier when you just deal with (entity, attribute, value) + time.
>
> > I buy it in theory, but I have no idea what to expect in terms of
> > performance (e.g., how long would it take to find the current todo
> > list of someone who has added and completed/removed a few thousand
> > items?).
>
> > Has anyone implemented this idea on Clojure datastructures using,
> > say, (timestamp, keyseq, value) and reducing a ton of calls to assoc-
> > in?
> > Aside from speed, what are some other tradeoffs of an immutable
> > approach?
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
>
> --
> Sent from an IBM Model M, 15 August 1989.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
