Motivation and expectation changes :)

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.