Anonymous avatar Anonymous committed 365c50f

update all bla bla files

Comments (0)

Files changed (6)

-=================
-ddbmock 0.4.1.dev
-=================
+==========================
+ddbmock 0.4.1 aka 1.0.0 RC
+==========================
 
 This section documents all user visible changes included between ddbmock
 versions 0.4.0 and versions 0.4.1
 
+This iteration was mostly focused on polishing and brings last missing bits.
+
 Additions
 ---------
 
 **DynamoDB** is really awesome but is terribly slooooow with managment tasks.
 This makes it completly unusable in test environements.
 
-**ddbmock** brings a nice, tiny, in-memory (optionaly sqlite) implementation of
+**ddbmock** brings a nice, tiny, in-memory or sqlite implementation of
 DynamoDB along with much better and detailed error messages. Among its niceties,
 it features a double entry point:
 
 you've been warned! I currently recommend the "boto extension" mode for unit-tests
 and the "server" mode for functional tests.
 
-Yes, ddbmock *can persist your data* using the optional "sqlite" backend. Bt still,
-do *not* use it in production.
-
 Installation
 ============
 
     $ nosetests # --no-skip to run boto integration tests too
 
 
+What is ddbmock *not* useful for ?
+==================================
+
+Do *not* use it in production or as a cheap DynamoDB replacement. I'll never
+stress it enough.
+
+All the focus was on simplicity/hackability and simulation quality. Nothing else.
+
 What is ddbmock useful for ?
 ============================
 
-- running unit test FAST. DONE
-- running functional test FAST. DONE
-- experiment with DynamoDB API. DONE
-- plan throughput usage. DONE
-- plan disk space requirements. DONE (describe table returns accurate size !)
-- perform simulations with accurate limitations.
+- FAST and RELIABLE unit testing
+- FAST and RELIABLE functional testing
+- experiment with DynamoDB API.
+- RELIABLE throughput planification
+- RELIABLE disk space planification
+- almost any DynamoDB simulation !
+
+ddbmock can also persist your data in SQLITE. This open another vast range of
+possibilities :)
 
 Current status
 ==============
 - support full item life-cycle
 - support for all item limitations
 - accurate size, throughput reporting
-- ``Scan``, ``BatchGetItem`` and ``BatchWriteItem`` still lacks ``ExclusiveStartKey``
 - no limits on concurent table operations
-- no limits for request/response size nor item count in those
+- no limits for request/response size nor item count in these
 
 See http://ddbmock.readthedocs.org/en/latest/pages/status.html for detailed
 up-to-date status.
 History
 =======
 
- - v0.4.1 (?): more analytics, schema persistence in sqlite, ...
+ - v1.0.0 (*): full documentation and bugfixes
+ - v0.4.1: schema persistence + thread safety, bugfixes
  - v0.4.0: sqlite backend + throughput statistics + refactoring, more documentation, more tests
  - v0.3.2: batchWriteItem support + pass boto integration tests
  - v0.3.1: accuracy in item/table sizes + full test coverage

docs/_include/intro.rst

 `DynamoDB <http://aws.amazon.com/dynamodb/>`_ is a minimalistic NoSQL engine
 provided by Amazon as a part of their AWS product.
 
-**DynamoDB** is great in production environement but sucks when testing your
-application. Tables needs roughtly 1 min to be created, deleted or updated.
-Items operation rates depends on how much you pay and tests will conflict if
-2 developers run them at the same time.
+**DynamoDB** allows you to store documents composed of unicode, number or binary
+data as well are sets. Each tables must define a ``hash_key`` and may define a
+``range_key``. All other fields are optional.
 
-**ddbmock** brings a tiny in-memory(tm) implementation of DynamoDB API. It can
-either be run as a stand alone server or as a regular library helping you to
-build lightning fast unit and functional tests :)
+**DynamoDB** is really awesome but is terribly slooooow with managment tasks.
+This makes it completly unusable in test environements.
+
+**ddbmock** brings a nice, tiny, in-memory or sqlite implementation of
+DynamoDB along with much better and detailed error messages. Among its niceties,
+it features a double entry point:
+
+ - regular network based entry-point with 1:1 correspondance with stock DynamoDB
+ - **embeded entry-point** with seamless boto intergration 1, ideal to avoid spinning yet another server.
 
 **ddbmock** is **not** intended for production use. It **will lose** your data.
 you've been warned! I currently recommend the "boto extension" mode for unit-tests
 
 .. include:: _include/intro.rst
 
+What is ddbmock *not* useful for ?
+----------------------------------
+
+Do *not* use it in production or as a cheap DynamoDB replacement. I'll never
+stress it enough.
+
+All the focus was on simplicity/hackability and simulation quality. Nothing else.
+
+What is ddbmock useful for ?
+----------------------------
+
+- FAST and RELIABLE unit testing
+- FAST and RELIABLE functional testing
+- experiment with DynamoDB API.
+- RELIABLE throughput planification
+- RELIABLE disk space planification
+- almost any DynamoDB simulation !
+
+ddbmock can also persist your data in SQLITE. This open another vast range of
+possibilities :)
+
+History
+-------
+
+ - v1.0.0 (*): full documentation and bugfixes
+ - v0.4.1: schema persistence + thread safety, bugfixes
+ - v0.4.0: sqlite backend + throughput statistics + refactoring, more documentation, more tests
+ - v0.3.2: batchWriteItem support + pass boto integration tests
+ - v0.3.1: accuracy in item/table sizes + full test coverage
+ - v0.3.0: first public release. Full table lifecycle + most items operations
+
+(?) indicates a future release. These are only ideas or "nice to have".
+
 Documentation
 =============
 

docs/pages/extending.rst

  - There is a "catch all" in the router that maps to DynamoDB internal server error
 
 
-Adding a method
-===============
+Adding a custom action
+======================
 
 As long as the method follows DynamoDB request structure, it is mostly a matter of
 adding a file to ``ddbmock/routes`` with the following conventions:

docs/pages/status.rst

 - ``NOT_CONTAINS`` DONE
 - ``IN`` DONE
 
-``IN`` operator is the only that can not be imported directly as it overlaps
-builtin ``in`` keyword. If you need it, either import it with ``getattr`` on the
-module or as ``in_test`` which, anyway, is its internal name.
+.. note::
+
+    ``IN`` operator is the only that can not be imported directly as it overlaps
+    with builtin ``in`` keyword. If you need it, either import it with ``getattr``
+    on the module or as ``in_test`` which, anyway, is its internal name.
 
 Return value specifications
 ---------------------------
 - ``UPDATED_OLD`` DONE
 - ``UPDATED_NEW`` DONE
 
-Please note that only ``UpdateItem`` supports the 5. Other compatible nethods
-understands only the 2 first.
+.. note::
+
+    Only ``UpdateItem`` recognize them all. Others does only the 2 first
+
 
 Rates and size limitations
 ==========================
 
-basically, none are supported yet
-
 Request rate
 ------------
 
 
 Dates are represented as float timestamps using scientific notation by DynamoDB
 but we only send them as plain number, not caring about the representation. Most
-parsers won't do any difference anyway.
+parsers won't spot any difference anyway.
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.