Query
Related Doc:
package rogue
Adds another and-connected clause to the query.
Adds an iscan clause to a query.
Places a limit on the size of the returned result.
Places a limit on the size of the returned result.
Like "or", this uses the Rogue phantom-type/implicit parameter mechanics. To call this method, the query must not yet have a limit clause attached. This is captured by the implicit parameter being constrained to be "Unlimited". After this is called, the type signature of the returned query is updated so that the "MaybeLimited" type parameter is now Limited.
Chains an "or" subquery to the current query.
Chains an "or" subquery to the current query.
The use of the implicit parameter here is key to how the Rogue type checking mechanics work. In order to attach an "or" clause to a query, the query as it exists must not yet have an or-clause. So the implicit parameter, which carries the phantom type information, must be "HasNoOrClause" before this is called. After it's called, you can see that the "MaybeHasOrClause" type parameter is changed, and is now specifically bound to "HasOrClause", rather than to a type variable.
Like "or", this uses the Rogue phantom-type/implicit parameter mechanics.
Like "or", this uses the Rogue phantom-type/implicit parameter mechanics. To call this method, the query must not yet have an ordering clause attached. This is captured by the implicit parameter being constrained to be "Unordered". After this is called, the type signature of the returned query is updated so that the "MaybeOrdered" type parameter is now Ordered.
Natural ordering.
Natural ordering. TODO: doesn't make sense in conjunction with ordering on any other fields. enforce w/ phantom types?
Search score ordering
Adds a scan clause to a query.
Adds text search to the query.
Adds a select clause to the query.
Adds a select clause to the query. The use of this method constrains the type signature of the query to force the "Sel" field to be type "Selected".
The use of the implicit parameter here is key to how the Rogue type checking mechanics work. In order to attach a "select" clause to a query, the query as it exists must not have a select clause yet. So the implicit parameter, which carries the phantom type information, must be "Unselected" before this is called. After it's called, you can see that the "MaybeSelected" type parameter is changed, and is now specifically bound to "Selected", rather than to a type variable.
Set a flag to indicate whether this query should hit primaries or secondaries.
Set a flag to indicate whether this query should hit primaries or secondaries. This only really makes sense if you're using replica sets. If this field is unspecified, rogue will leave the option untouched, so you'll use secondaries or not depending on how you configure the mongo java driver. Also, this only works if you're doing a query -- findAndModify, updates, and deletes always go to the primaries.
For more info, see http://www.mongodb.org/display/DOCS/slaveOk
Adds a skip to the query.
Adds a skip to the query.
Like or, this uses the Rogue phantom-type/implicit parameter mechanics. To call this
method, the query must not yet have a skip clause attached. This is captured
by the implicit parameter being constrained to be Unskipped. After this is called, the
type signature of the returned query is updated so that the MaybeSkipped type parameter is
now Skipped.
Adds a where clause to a query.
Adds an eqs clause specifying the shard key.
The definition of methods needed to build a query.
To construct a query, an instance of a query-builder needs to be created. That's done by using an implicit conversion from an instance of a meta-record. In code, the user writes a query by calling one of the query construction methods on an instance of the query-record meta-record instance. The implicit conversion will construct an appropriate query builder from the meta-record.
Query builders are parameterized using a collection of phantom types. For our purposes here, phantom types are types which are inferred by the type system, rather than being explicitly provided by users. The phantom types are inferred by the type system on the basis of what clauses are contained in the query. For example, if there's a ordering clause, that constrains the types so that the type system must infer a type parameter of type "Ordered". This use of phantom types allows the type system to prevent a range of query errors - for example, if two query clauses have incompatible ordering constraints, the type system will reject it.
The specific mechanics of the type inference process are based on implicit parameters. A type can only get inferred into an expression based on a parameter. But we don't want people to have to specify parameters explicitly - that would wreck the syntax. Instead, we use implicit parameters. The inference system will find an implicit parameter that is type compatible with what's used in the rest of the expression.
the record type being queried.
a phantom type which defines the state of the builder.