documentation:tutorials:json_query
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
documentation:tutorials:json_query [2016/11/06 13:48] – [Other Lessons] Deciding that an unordered list is better csharp | documentation:tutorials:json_query [2022/02/10 13:34] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 115: | Line 115: | ||
- | * The entire JSON query is an object. In this simple case the object includes only one entry, for the FROM clause. Typically you'll also have entries for the SELECT clause and the WHERE clause, and possibly for HAVING, ORDER BY, LIMIT, or OFFSET clauses. There is no separate entry for a GROUP BY clause, which you can specify by other means. | + | |
- | * Although all the other entries are optional, you must include an entry for the FROM clause. You cannot, for example, do a SELECT USER the way you can in psql. | + | |
- | * Every column is qualified by an alias for the table. This alias is usually the class name for the table, as defined in the IDL, but you can use an alias of your own choosing for a table in a JOIN clause (not shown here). | + | |
- | * Every column is aliased with the column name. There is a way to choose a different column alias (not shown here). | + | |
===== The SELECT clause ===== | ===== The SELECT clause ===== | ||
Line 186: | Line 186: | ||
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
This example assigns a different column alias: | This example assigns a different column alias: | ||
Line 2086: | Line 2086: | ||
JOIN actor.org_unit AS s ON (t.source = s.id) | JOIN actor.org_unit AS s ON (t.source = s.id) | ||
JOIN actor.org_unit AS d ON (t.dest = d.id) | JOIN actor.org_unit AS d ON (t.dest = d.id) | ||
- | WHERE s.parent_ou< | + | WHERE s.parent_ou <> d.parent_ou ) AS " |
</ | </ | ||
Line 2094: | Line 2094: | ||
+ | ==== Choosing the Order of JOINs ==== | ||
+ | |||
+ | As of Evergreen 3.0.2, we support user-defined join order in cstore and friends. Previously, because the join structure of '' | ||
+ | |||
+ | For example, given the following JSON object passing through a modern Perl 5 interpreter as a nested hash: | ||
+ | |||
+ | <code json> | ||
+ | { | ||
+ | select : { | ||
+ | acp: [' | ||
+ | acn: [' | ||
+ | acpl: [' | ||
+ | }, | ||
+ | from : { | ||
+ | acp: { | ||
+ | acn: {filter: {record: 12345} }, | ||
+ | acpl: null | ||
+ | } | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | the FROM clause of the query may end up as: | ||
+ | |||
+ | <code sql> | ||
+ | FROM acp | ||
+ | JOIN acn ON (acp.call_number = acn.id AND acn.record = 12345) | ||
+ | JOIN acpl ON (acp.location = acpl.id) | ||
+ | </ | ||
+ | |||
+ | Or as: | ||
+ | |||
+ | <code sql> | ||
+ | FROM acp | ||
+ | JOIN acpl ON (acp.location = acpl.id) | ||
+ | JOIN acn ON (acp.call_number = acn.id AND acn.record = 12345) | ||
+ | </ | ||
+ | |||
+ | In some situations, the join order will matter either to the semantics of the query plan, or to its performance. The following example of the newly supported syntax illustrates how to specify join order: | ||
+ | |||
+ | <code json> | ||
+ | { | ||
+ | select : { | ||
+ | acp: [' | ||
+ | acn: [' | ||
+ | acpl: [' | ||
+ | }, | ||
+ | from : { | ||
+ | acp: [ | ||
+ | {acn: {filter: {record: 12345} } }, | ||
+ | ' | ||
+ | ] | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | And the only FROM clause the can be generated is: | ||
+ | |||
+ | <code sql> | ||
+ | FROM acp | ||
+ | JOIN acn ON (acp.call_number = acn.id AND acn.record = 12345) | ||
+ | JOIN acpl ON (acp.location = acpl.id) | ||
+ | </ | ||
==== Things You Can't Do ==== | ==== Things You Can't Do ==== | ||
documentation/tutorials/json_query.1478458099.txt.gz · Last modified: 2022/02/10 13:33 (external edit)