added toJSON method to Storable prototype to allow stringifying storable instances.

note that JSON representations of storables currently contain only "_id" and primitive properties, mapped objects and collections are ignored.
added JSON.stringify test
fixed bug in cache initialization
output PEG.SyntaxError

this will output:

    Error: Could not parse query.
    "slect foo fram bar"
          ^
    Expected "." or [A-Za-z0-9_\-] but " " found. At column: 6
    	at ringo-sqlstore/lib/sqlstore/query/query.js:23 (anonymous)
    	at ringo-sqlstore/lib/sqlstore/query/query.js:72 (anonymous)
    	at ringo-sqlstore/lib/sqlstore/store.js:679 (anonymous)
    	at /home/simon/ositestats/query stuff:50
allow multiple "having" conditions
bugfix: don't use AS keyword between entity and alias (oracle doesn't like that)
Extended query parsing, simplified sql statement generation

- Summands/factors are now recognised by the parser (including nested ones)
- Dropped auto-creation of result aliases in generated sql statements. This turned out to be much too complex (eg. auto-generation of an alias for summand/factor trees). Instead aliases are only used as property names for query result objects (if querying for more than one value) and as long they are necessary for sql statement construction.
- Result/table aliases no longer require "AS" keyword
- Store.executeQuery() now passed the resultset metadata along with the resultset to the collector
- Fixed join parsing rules to allow "left join" (before direction was optional, but "outer" required)

Collector changes:

- Collectors access resultset columns by index instead of by column name
- CollectorGenerator is no longer a visitor (it's easier this way)
- Added AggressiveEntityCollector used whenever a SelectEntity node is found in the select clause
- Added ValueCollector used for all non-property values in a select clause (this one uses getColumnType of jdbc resultset metadata). If no result alias is specified in the query this collector uses a newly introduced Normalizer to generate a result object property name for the value

AST changes:

- Added SelectExpression constructor: every selected value (ident, entity, aggregation, summand, factor ...) is wrapped in such an expression that also contains any specified result alias
- Added Summand and Factor constructors
- Removed SelectAggregation and SelectIdent constructors, switched to using Aggregation and Ident now
- SelectEntity is now only used for aggressive loading of entities
bugfix in mapping: don't put mapped collections into a mapping's column map

collections don't have a column property, so adding these to the column map leads to a wrong mapped column count which in turn messes up aggressive entity collector (which relies on the column count for correct offset calculation within a query result set)
increased speed of parsing nested parenthesis expressions

split summand/factor rules in left/right rules - this avoids re-parsing a left node if parsing the right hand side fails
Merge branch '0.2' of https://github.com/grob/ringo-sqlstore into 0.2
removed syncing of method calls, replaced HashMap instances with synchronized ones

rhino's sync() only syncs on the method, not the instance this method belongs to (thanks to hannesw for this hint).
Make sure entity cache is touched only after successful database commits

Until now the entity cache introduced a number of problems (esp. in conjunction with explicitly opened transactions):
- Store.updateEntity() copied a storable's properties into its _entity which most likely was already cached. Problem 1: before the Store.update() method would remove the entity object from the cache, other threads would use this modified (and uncommitted) entity as base for new storable instances. Problem 2: even after the modified entity has been removed from the cache, other threads could retrieve the entity data before the changes have been committed to database, thus getting values soon to be replaced, and effectively put an entity with old data into the object cache.
- Store.remove() removed the entity from the object cache, but also before the change has been committed to db. Thus other threads could re-get the entity data from db before the commit and put it into cache.

A transaction rollback would not solve the above problems. Therefor the new strategy is:
- updateEntity() stores the data about to be saved in db in a new entity object
- cache puts/evictions are handled by the transaction after a successful commit
- a manual/automatic rollback reverts the state of the affected storables to their previous one, but all modifications are kept (so eg. if a modified storable can't be saved, it will stay in modified state containing all changes made. if a transient storable can't be saved, it will stay in transient state containing all data).
add Collection.all
fixed aggressive loading of collections
changed PartitionedCollection to extend Collection

it now has the same interface as Collection, plus removes duplicated code
modified transaction to avoid multiple cache operations per storable

instead of keeping track of inserted/updated/removed storables in arrays, use objects as maps. this ensures that only one operation per storable is done on transaction commit/rollback. additional benefit: cache key generation is done only once when registering a storable in the transaction.
added tests for transaction isolation

note that for this to work with h2 i had to switch on Multi-Version Concurrency Control in the unit test db config (see http://www.h2database.com/html/advanced.html#mvcc for details on that)
throw an error when trying to overwrite a key's ID instead of silently ignoring it.

removed Key.isPersistent() to avoid confusion: this didn't mean that a storable had been persisted, it just meant that the key had an ID set.
Fixed transaction isolation and collection modification/invalidation

Transaction isolation:

- All changes (including collection invalidations/reloads) within an open transaction are completely invisible to other threads. All cache.put() calls are only done if there is either a) no open transaction or b) the transaction doesn't contain the key of the entity about to be put into cache.
- Transaction now has a map for invalidated collections. After a successful commit the collections are either marked as invalidated or, if they have been reloaded during the transaction, their ID list is put directly into cache.

Collection changes:

- Added explicit state to Collection instances, instead of an isInitialized boolean
- Removed Collection methods add() and remove(): these were merely an alias for invalidate(), but suggested that the collection itself would be immediately modified.
modified cache key generation/access

- added _cacheKey getter to storable to provide the same as collections do
- added a cacheKey getter to Key prototype: this way the cache key of a Key is only created once