gistfile1.txt

# Indexes
- Index should be non-empty array
- Index cannot have duplicate attributes
- Index must have at least one 'hash' attribute
- All indexed attributes must exist in a schema
- Static indexes cannot be created on a table with no range indexes
# Revision policy
- Only keys 'type', 'grace_ttl' and 'count' are allowed
- Type can be 'all' and 'latest'
- Grace_ttl must be a number and can't be less then minGcGrace
- Count must be a number and must be between minKeep and maxKeep
# Schema
- Schema must have at least one attribute
- Attribute types must be valid
- Compression option must have valid algorithm and block size
- Durablity option must have valid value
# Get projection
- A projection must be a String or Array
- All projection attributes must exist in a table/index schema
# Conditions
 - Every attribute in the predicate must be 'hash' or 'range' indexed (optional for WHERE bit no for IF)
 - Each individual condition operator must be valid
 - Non-eq operators allowed only on 'range' indexed columns
 - There can't be more than one non-eq predicates.
# Order
- Order must be either 'asc' or 'desc'
- Order attributes must be in a 'range' index of a table
# Get request
- Table schema must exist
- If the query uses a secondary index, it must exist
- Projection, condition and order parts are also verified
# Put request
- A table schema must exist
- All primary key attributes must be provided
- IF condition verified

There can't be more than one non-eq predicates

I think there can be more than one, but they must comply with the index definition, AFAIK.

There can definitely be multiple non-eq predicates. Example from https://github.com/wikimedia/restbase/blob/master/doc/TableStorageAPI.md:

        property: {
            gt: 'a',
            le: 'c'
        }

• Compression option must have valid algorithm and block size

These should be treated as hints, and might be backend-specific. Lets not reject schemas in the general spec validator based on it.

• Durablity option must have valid value

This isn't really used yet. We might want to ignore this for now.

• A projection must be a String or Array

Maybe we should remove the String option?

• All projection attributes must exist in a table/index schema

We could check this in the spec, but it is probably cheaper to check in the backend. Maybe leave this for later?

Generally, lets make sure that we don't add a lot of overhead in the high-volume read / write paths. That doesn't necessarily mean that we skimp on validation, but we might want to think about tricks like caching a ready-to-execute closure holding the generated CQL right behind the interface, possibly keyed on a hash of the request structure (ignoring the concrete values).

All projection attributes must exist in a table/index schema

We could check this in the spec, but it is probably cheaper to check in the backend. Maybe leave this for later?

But that was one of the points where cassandra/sqlite are different, so it was one of the main reasons to build the validator.. But if you are strictly concerned about performance we could leave this out

@Pchelolo, my comment was more about where the check happens, not so much about whether it happens.