Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T torque-postgresql
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 6
    • Issues 6
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Carlos
  • torque-postgresql
  • Wiki
  • Auxiliary Statements

Auxiliary Statements · Changes

Page history
Updated Auxiliary Statements (markdown) authored Aug 18, 2018 by Carlos's avatar Carlos
Hide whitespace changes
Inline Side-by-side
Auxiliary-Statements.md
View page @ bb929d92
......@@ -19,13 +19,33 @@ end
The statement is lazy load, so the block is called only when a query requires its usage. To configure your statement, these are the options available:
`cte.query` The query that will be performed inside the auxiliary statement (WITH). It most likely will be one that brings extra information related to the main class, in this case the `User` class.
- `cte.query` The query that will be performed inside the auxiliary statement (WITH). It most likely will be one that brings extra information related to the main class, in this case, the `User` class.
- `cte.attributes` The list of attributes that will be exposed to the main query and after it is able to access through the entries fetch. It's read as `The column form the query => The alias exposed`. It accepts join columns in the left side as `'table.column' => 'alias'`.
- `cte.join_type` The type of join between the main query and statement query. By default it's set to `:inner`, that will perform an `INNER JOIN`. The options are `:inner, :left, :right, :full`.
- `cte.join` The columns used on the join in the main query. It has similar behavior as the attributes, and it's read as `The column from the main query == The column from the statement query`. It accepts join columns in both sides as `'table.column' => 'table.column'`.
`cte.attributes` The list of attributes that will be exposed to the main query and after it is able to access through the entries fetch. It's read as `The column form the query => The alias exposed`. It accepts join columns in the left side as `'table.column' => 'alias'`.
#### Query option
`cte.join_type` The type of join between the main query and statement query. By default it's set to `:inner`, that will perform an `INNER JOIN`. The options are `:inner, :left, :right, :full`.
You have to think about the query as the command that will bring the information from all the records, so don't use where or similar conditions, because they will be calculated using `join`.
`cte.join` The columns used on the join in the main query. It has similar behavior as the attributes, and it's read as `The column from the main query == The column from the statement query`. It accepts join columns in both sides as `'table.column' => 'table.column'`.
For this option, you can use either a `String`, a `Proc`, or an `ActiveRecord::Relation`. For the first 2 options, you need to manually provide the table name as the first argument.
```ruby
cte.query :comments, 'SELECT * FROM comments'
cte.query :comments, -> { Comments.all }
cte.query Comments.all
```
#### Accessing attributes
The class provided in the `|cte|` has many ways to facilitate accessing columns and other query stuff.
```ruby
cte.query_table # Gives an Arel::Table of the defined statement
cte.query_table['col'] # Gives an Arel::Attributes::Attribute
cte.col('col') # Same as the above
cte.sql('MAX(col)') # A literal SQL string with Arel properties
```
### Querying
```ruby
......@@ -41,4 +61,13 @@ user.last_comment_content
You are able to use all the exposed columns set on the right side of the `attributes` configuration in other methods like `where`, `order`, `group`, etc.
```ruby
user = User.with(:last_comment).order(:last_comment_content)
```
\ No newline at end of file
```
The advantage of the String and Proc query option on an auxiliary statement is that they allow arguments. Which means that the can be further configured based on what you provide on the `:args` key. **CAUTION** if you use `with` with multiple values and the `:args` for arguments, the list of arguments will be used for all `String` and `Proc` queries.
```ruby
user = User.with(:comments, args: {id: 1}).order(:last_comment_content)
```
You can also change the name of the key used to pass arguments using
[`auxiliary_statement.send_arguments_key`](https://github.com/crashtech/torque-postgresql/wiki/Configuring#auxiliary_statement.send_arguments_key) config.
\ No newline at end of file
Clone repository
  • Wiki
  • Configuring

Data types

  • Enum
  • Interval

Querying

  • Distinct On
  • Auxiliary Statements