I've been concerning this problem for a few months.
The "transaction logs" is actually the history events of an entity.
With an initial state is offer, the current state of an entity can be
calculated with the help of history events.
So if you want to know a property of an entity currently, these
calculation is inevitable.
But we can reduce the calculation process by taking snapshots for a
given entity.
A snapshot is another state of an entity at a specific time. You can
calculate the current state of an entity by just applying all the
later history events to the snapshot.
For example, suppose we have a task T, and it's empty map at start.
(def T {})
We can do push/pop operation on it with a history event generated. S
doesn't change at all, just some events are recorded.
(assoc T :title"A task")
(assoc T :time "today")
(dissoc T :time)
(assoc T :status "done")
So what is the current state of T?
(calculate-current T)
=> {:title "A task" :status "done"}
This state is generated by applying all the operations on the initial
state of T.
However, if there are a large amount of history events, a long time
will take to get the current state of S.
To improve this, snapshot is needed.
(assoc T :title"A task")
(assoc T :time "today")
(def T1 (calculate-current T))
(dissoc T :time)
(assoc T :status "done")
So what's the current state of T?
As we know, the last snapshot is T1, we can just apply (dissoc T1
:time) and (assoc T1 :status "done") to get the current state of T.
With the help of the snapshot, we save 50% of the calculation.
Of course, we need to use some more space to store the snapshots.
More consideration is needed if you want to query the state of an
entity at a specific time in history.
But I think it's enough to solve your problem, because you always need
the current state of a task. Thus you can just store one snapshot.
On Tue, Jun 5, 2012 at 8: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
--
Sincerely,
江海龙
Hoiloong Kong
--
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
