From dc572c5e418e53fcadd3b9694bb6570135809c11 Mon Sep 17 00:00:00 2001 From: Sergey Didenko Date: Wed, 13 Mar 2013 18:03:05 +0200 Subject: [PATCH] Motivation and expectation changes :) --- README | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README b/README index 69c7aac..b8eb3b8 100644 --- a/README +++ b/README @@ -6,13 +6,13 @@ Also it is possible to use it just as the journaling layer to record the (writin Transactions are logged as a valid Clojure code, so they are easy to read and run separately. (Just wrap them into dosync) -I consider it a good fit for the prototyping stage of a project development. When you don't want to pay the price of impedance mismatch between the language data structures and your database because your database schema is not stable yet. +Probably under certain conditions it can be a good fit for the prototyping stage of a project development. However this pattern is used in production by some teams, see Prevayler mail list for details. Of course this implementation can contain bugs and must be tested well before doing that. Though it is very simple and I made some tests. The disadvantage of the pattern is that your data structures must fit in memory (unless you implement ad-hoc paging solution). However the journaling nature lets you easily switch to other databases. For that you just re-implement your transaction functions (subjects of apply-transaction* ) to write/read from another DB and replay transactions one time (init-db). -Snapshotting is not yet implemented. It can solve another pattern problem - growing startup time. +Snapshotting is not implemented. It can solve another pattern problem - growing startup time. In comparison with Prevayler, this library does not block the reads, because it relies on Clojure STM. However it blocks the writes as Prevayler. To avoid this, atoms can be used to generate a transaction id without locking, but that will make reading and backup logic much more complex.