...

1. Should the appropriate processing and post-filtering for a complex find be done client or server side?
   1. We should probably do this on the server so that these queries are performant. I'm really concerned about all the network overhead of the client sending multiple separate queries over the wire.
   2. If this is done on the client, then complex queries are somewhat analogous to a compound operation
      1. This means that our results can become invalid if a spurious write changes the data in between network calls
         1. Example: Assume my criteria is find all records where "name = 'John' AND age = 23". If the client has to do separate calls and post filter the results then its possible a record that matches the first query can be changed to no longer match the first query after the result is returned and the client moves onto the second query.
   3. If this is done on the server, the complex query is analogous to a repeatable atomic operation
2. Should we deprecate the #find methods that take simple parameters?
   1. No: Builders are inherently not user friendly so we should not force the user to use one of a simple query
   2. Yes: Overloaded methods that take different kinds of parameters is bad API design
3. Why a programatic builder as opposed to a grammar parser?
   1. Don't trust raw string input from users. We can regulate things a lot more if this is done programmatically with a builder.
4. This project may form the basis of a larger database language (e.g. Concourse Action Language (CAL))
   1. This means that we need to write this feature in a way that can easily be leveraged and extended in the future
5. Will this builder be usable in CaSH?

Building Process

1. User creates Criteria from builder.
2. The client goes through each symbol in the Criteria and converts them to the appropriate TSymbol, building a TCriteria along the way
   1. All sub criteria is expanded and prepended/appended with the appropriate parenthesis symbols
3. The server receives the TCriteria, goes through the list of TSymbols and converts them back to Symbols
4. The server does the shunting yard alg on the list of Symbols.

...

The state that expects the next symbol/token to be a key an operator specification.

class KeyState extends State {
	OperatorState operator(Operator operator);
}

...

...

ConjunctionSymbol

An enum that represents the possible conjunction symbols.

enum ConjunctionConjunctionSymbol implements Symbol {
	AND, OR;
}

...

KeySymbol

A symbol that represents a "key" in a Criteria.

class KeyKeySymbol implements Symbol {
	public String getKey();
}

OperatorSymbol

A symbol that represents an "operator" in a Criteria.

class OperatorSymbol implements Symbol {
	public Operator getOperator();
}

...

ValueSymbol

A symbol that represents a "value" in a Criteria.

class ValueValueSymbol implements Symbol {	
	// When the State creates this symbol it must convert the object to a TObject so that it can be passed over the wire via Thrift
	public TObject getValue();
}

...

ParenthesisSymbol (only defined on the server)

A symbol that represents a parenthesis in a Criteria. Note that the builder doesn't actually need to use these since Criteria objects are embedded to signify groups.

enum ParenthesisParenthesisSymbol implements Symbol {
	LEFT, RIGHT;
}

...

Task	Description	Notes
Define Criteria grammar	Implement the rules of the grammar, define all the appropriate symbols, and define all the appropriate operations
Port Shunting-yard to Java	Given a collection of symbols, implement the algorithm that returns those symbols in reverse polish notation.
Implement Criteria builder	Implement a builder that allows the programatic creation of a Criteria
Edit Public API	Add the appropriate methods to the public api
Integrate with CaSH