The OPM Query Translator supports two types of projections which may be used together.
COnsider the following query example:
SELECT name = @pname, @p (age, degree_date, degree, field)
FROM @p in PERSON, @pname in @p.name, @pfield in @p.field
WHERE @pfield = "Genetics";
(Note: the @variable convention is useful to adopt for easy identification of variables as well as for avoiding potential name conflicts with schema identifiers.)
In this example, the output variables @pname and @p (class instance Oid for PERSON) provide two columns in the denormalized tuple output. The attributes age, degree_date, degree, and field specify the Oid based projection output attributes for a class instance of PERSON specified by variable @p.
Condition evaluation generates the first level denormalized output. This level of evaluation takes into account restrictions on qualifying set-valued attributes instances and join correlations specified in the condition. The denormalized tuple projection is efficiently implemented in one main SQL query, with possibly one or more subqueries within the main query, and is useful for retrieving raw values for higher level software. For example, a query processor may use ``get tuple'' to retrieve values for condition evaluation.
For each abstract or class output variable in the denormalized output, the user may additionally specify output attributes. Unlike the denormalized tuple output, these output attribute instances are not constrained by the condition in the manner described above. They are constrained only by the class instance Oid of a variable instance. Oid based projection results in all attribute instances for a given class instance and may be assembled into an ``object'' data output consisting of variously structured single and set-valued attributes, as well as simple and tuple attributes. In addition, implied retrievals, such as REP's are also handled at this level.
While Oid based projection provides a structurally richer output, retrieval is an order of magnitude slower than the denormalized output. For each class instance in the denormalized output variable ( @p in this example), a relational query, or queries, are resubmitted to retrieve all specified attributes for one Oid. The retrieval of these attributes by Oid may be accomplished using raw SQL or stored procedures.
Both these types of projections have their appropriate place in application strategy. The first provides efficient retrieval of raw values in a tuple, and as mentioned earlier, may be used to retrieve raw values for a higher level query processor. The second provides a ``full object'' retrieval for a single class instance. The second is inefficient for large volume query retrievals, but may be useful for queries like ``get me the first N object instances'' based on a condition specification, where N is a small number. Oid based projection may also be used for connection oriented applications, where the user submits the query, but views one class instance result at a time, and retrieves the next class instance from the query result by hitting some ``next'' button. For such an application interaction, the user has the option to quit any time without retrieving all instances. Oid based projections may also be used in connection-less applications, such as Web based CGI retrievals. The CGI application may use the ``get tuple'' projection to efficiently retrieve all the Oid and REP's qualified in a condition. The user can then select one class instance from this result list and use the ``get object'' projection to look at one full class instance at a time.