The querying logic behind all the Load methods in your ORM classes is powered by Qcodo Query, or QQ for short. Put simply, QQ is a completely object oriented API to perform any SELECT-based query on your database to return any result or hierarchy of your ORM objects.

While the ORM classes utilize basic, straightforward SELECT statements in its Load methods, QQ is capable of infinitely more complex queries. In fact, any SELECT a developer would need to do against a database should be possible with QQ*.


At its core, any QQ query will return a collection of objects of the same type (e.g. a collection of Person objects). But the power of QQ is that we can branch beyond this core collection by bringing in any related objects, performing any SQL-based clause (including WHERE, ORDER BY, JOIN, aggregations, etc.) on both the core set of Person rows and any of these related objects rows.

Every code generated class in your ORM will have the three following static Qcodo Query methods:

• QuerySingle: to perform a Qcodo Query to return just a single object (typically for queries where you expect only one row)
• QueryArray: to perform a Qcodo Query to return just an array of objects
• QueryCount: to perform a Qcodo Query to return an integer of the count of rows (e.g. "COUNT (*)")

All three Qcodo Query methods expect two parameters, a QQ Condition and an optional set of QQ Clauses. QQ Conditions are typically conditions that you would expect to find in a SQL WHERE clause, including Equal, GreaterThan, IsNotNull, etc. QQ Clauses are additional clauses that you could add to alter your SQL statement, including methods to perform SQL equivalents of JOIN, DISTINCT, GROUP BY, ORDER BY and LIMIT.

And finally, both QQ Condition and QQ Clause objects will expect QQ Node parameters. QQ Nodes can either be tables, individual columns within the tables, or even association tables. QQ Node classes for your entire ORM is code generated for you.

The next few examples will examine all three major constructs (QQ Node, QQ Condition and QQ Clause) in greater detail.

And as a final note, notice that Qcodo Query doesn't have any construct to describe what would normally be your SELECT clause. This is because we take advantage of the code generation process to allow Qcodo Query to automagically "know" which fields that should be SELECT-ed based on the query, conditions and clauses you are performing. This will allow a lot greater flexbility in your data model. Because the framework is now taking care of column names, etc., instead of the developer needing to manually hard code it, you can make changes to columns in your tables without needing to rewrite your Qcodo Query calls.