Mailing-List: contact commits-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: commits@drill.apache.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: bridgetb@apache.org
To: commits@drill.apache.org
Message-Id: <0d19e59dcb2b41549400c5c2702667fd@git.apache.org>
Subject: drill git commit: Updates for 1.6
Date: Wed, 16 Mar 2016 00:02:54 +0000 (UTC)

Repository: drill
Updated Branches:
  refs/heads/gh-pages ae8d958d6 -> 1dfec3806


Updates for 1.6


Project: http://git-wip-us.apache.org/repos/asf/drill/repo
Commit: http://git-wip-us.apache.org/repos/asf/drill/commit/1dfec380
Tree: http://git-wip-us.apache.org/repos/asf/drill/tree/1dfec380
Diff: http://git-wip-us.apache.org/repos/asf/drill/diff/1dfec380

Branch: refs/heads/gh-pages
Commit: 1dfec38060f2a87a8ba97c940dfcd77ef80e8ff2
Parents: ae8d958
Author: Bridget Bevens <bbevens@maprtech.com>
Authored: Tue Mar 15 17:00:25 2016 -0700
Committer: Bridget Bevens <bbevens@maprtech.com>
Committed: Tue Mar 15 17:00:25 2016 -0700

----------------------------------------------------------------------
 .../071-configure-inbound-impersonation.md      | 102 ++++++++++---------
 .../010-sql-window-functions-introduction.md    |  45 ++++----
 images/inboundImpersonation.PNG                 | Bin 0 -> 21216 bytes
 3 files changed, 79 insertions(+), 68 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/drill/blob/1dfec380/_docs/configure-drill/071-configure-inbound-impersonation.md
----------------------------------------------------------------------
diff --git a/_docs/configure-drill/071-configure-inbound-impersonation.md b/_docs/configure-drill/071-configure-inbound-impersonation.md
index 8a581ed..3c03d67 100644
--- a/_docs/configure-drill/071-configure-inbound-impersonation.md
+++ b/_docs/configure-drill/071-configure-inbound-impersonation.md
@@ -1,50 +1,52 @@
----
-title: "Configuring Inbound Impersonation"
-date:  
-parent: "Configure Drill"
----  
-
-Drill supports [user impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/)  where queries run as the user that created a connection. However, this user is not necessarily the end user who submits the queries. For example, in a classic three-tier architecture, the end user interacts with Tableau Desktop, which communicates with a Tableau Server, which in turn communicates with a Drill cluster. In this scenario, a proxy user creates a connection, and the queries are submitted to Drill by the proxy user on behalf of the end user, and not by the end user directly. In this particular case, the query runs as the end user.  
-
-![The picture shows how identity is propagated through various layers (with authentication enabled). The flow on the left is what Drill currently supports, and the flow on the right is the proposed change. t:euser is a property on the connection (u is username, p is password, t is impersonation_target).](http://i.imgur.com/R3b4fi0.png)  
-
-As of Drill 1.6, an administrator can define inbound impersonation policies to impersonate the end user. Impersonating the end user is a natural extension of Drill’s impersonation model and accounts for one more [user hop in the chain]({{site.baseurl}}/docs/configuring-user-impersonation/#chained-impersonation). This additional hop requires authorization, meaning that the proxy user needs to be authorized to submit queries on behalf of the specified end user. Otherwise, any user can impersonate another user. Then, the query runs as the end user, and data authorization is based on this user’s access permissions. Note that without [authentication]({{site.baseurl}}/docs/configuring-user-authentication/) enabled in both communication channels, a user can impersonate any other user.
-
-Drill trusts proxy users to provide the correct end user identity information. Drill does not authenticate the end user. The proxy user (application) is responsible for end user authentication, which is usually enabled.
-
-##Configuring Inbound Impersonation
-You must be an administrator to configure inbound impersonation. You can define administrative users through the `security.admin.user_groups` and `security.admin.users` options. See [Configuration Options]({{site.baseurl}}/docs/configuration-options-introduction/#system-options). 
-
-[User impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/) must be enabled before you can configure inbound impersonation.
-
-Complete the following steps to enable inbound impersonation:  
-
-1. In `drill-override.conf`, set user impersonation to true:
-  
-              {
-              drill.exec.impersonation.enabled: true,
-              ...
-              }
-
-2. Define inbound impersonation policies. For example, the following ALTER SYSTEM statement authorizes:
-       * `puser1` to impersonate any user (*)
-       * `puser2` to impersonate `euser1` and all users in `egroup2` 
-       * all users in `pgroup3` to impersonate all users in `egroup3`  
-      
-              ALTER SYSTEM SET `exec.impersonation.inbound_policies`=‘[
-              { proxy_principals : { users: [“puser1”] },
-                target_principals: { users: [“*”] } },
-              { proxy_principals : { users: [“puser2”] }, 
-                target_principals: { users: [“euser1”], groups :  [“egroup2”] } },
-              { proxy_principals : { groups: [“pgroup3”] },
-                target_principals: { groups: [“egroup3”] } } ]’;  
-Policy format:
-
-              { proxy_principals : { users : [“...”], groups : [“...”] },
-                target_principals: { users : [“...”], groups : [“...”] } }
-
-3. Ensure that the proxy user (application) passes the username of the impersonation target user to Drill when creating a connection through the `impersonation_target` connection property. For example, through sqlline:  
-
-        bin/sqlline –u “jdbc:drill:schema=dfs;zk=myclusterzk;impersonation_target=euser1” -n puser1 -p ppass1  
-
-In this example, `puser1` is the user submitting the queries. This user is authenticated. Since this user is authorized to impersonate any user, queries through the established connection are run as `euser1`.
+---
+title: "Configuring Inbound Impersonation"
+date: 2016-03-16 00:00:26 UTC
+parent: "Configure Drill"
+---  
+
+Drill supports [user impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/)  where queries run as the user that created a connection. However, this user is not necessarily the end user who submits the queries. For example, in a classic three-tier architecture, the end user interacts with Tableau Desktop, which communicates with a Tableau Server, which in turn communicates with a Drill cluster. In this scenario, a proxy user creates a connection, and the queries are submitted to Drill by the proxy user on behalf of the end user, and not by the end user directly. In this particular case, the query runs as the end user.  
+
+![]({{ site.baseurl }}/docs/img/inboundImpersonation.PNG)  
+
+This image shows how identity is propagated through various layers (with authentication enabled). The flow on the left is Drill with user impersonation enabled, and the flow on the right is Drill with inbound impersonation enabled. `t:euser` is a property on the connection (`u` is `username`, `p`is `password`, `t` is `impersonation_target`).  
+
+As of Drill 1.6, an administrator can define inbound impersonation policies to impersonate the end user. Impersonating the end user is a natural extension of Drill’s impersonation model and accounts for one more [user hop in the chain]({{site.baseurl}}/docs/configuring-user-impersonation/#chained-impersonation). This additional hop requires authorization, meaning that the proxy user needs to be authorized to submit queries on behalf of the specified end user. Otherwise, any user can impersonate another user. Then, the query runs as the end user, and data authorization is based on this user’s access permissions. Note that without [authentication]({{site.baseurl}}/docs/configuring-user-authentication/) enabled in both communication channels, a user can impersonate any other user.
+
+Drill trusts proxy users to provide the correct end user identity information. Drill does not authenticate the end user. The proxy user (application) is responsible for end user authentication, which is usually enabled.
+
+##Configuring Inbound Impersonation
+You must be an administrator to configure inbound impersonation. You can define administrative users through the `security.admin.user_groups` and `security.admin.users` options. See [Configuration Options]({{site.baseurl}}/docs/configuration-options-introduction/#system-options). 
+
+[User impersonation]({{site.baseurl}}/docs/configuring-user-impersonation/) must be enabled before you can configure inbound impersonation.
+
+Complete the following steps to enable inbound impersonation:  
+
+1. In `drill-override.conf`, set user impersonation to true:
+  
+              {
+              drill.exec.impersonation.enabled: true,
+              ...
+              }
+
+2. Define inbound impersonation policies. For example, the following ALTER SYSTEM statement authorizes:
+       * `puser1` to impersonate any user (*)
+       * `puser2` to impersonate `euser1` and all users in `egroup2` 
+       * all users in `pgroup3` to impersonate all users in `egroup3`  
+      
+              ALTER SYSTEM SET `exec.impersonation.inbound_policies`=‘[
+              { proxy_principals : { users: [“puser1”] },
+                target_principals: { users: [“*”] } },
+              { proxy_principals : { users: [“puser2”] }, 
+                target_principals: { users: [“euser1”], groups :  [“egroup2”] } },
+              { proxy_principals : { groups: [“pgroup3”] },
+                target_principals: { groups: [“egroup3”] } } ]’;  
+Policy format:
+
+              { proxy_principals : { users : [“...”], groups : [“...”] },
+                target_principals: { users : [“...”], groups : [“...”] } }
+
+3. Ensure that the proxy user (application) passes the username of the impersonation target user to Drill when creating a connection through the `impersonation_target` connection property. For example, through sqlline:  
+
+        bin/sqlline –u “jdbc:drill:schema=dfs;zk=myclusterzk;impersonation_target=euser1” -n puser1 -p ppass1  
+
+In this example, `puser1` is the user submitting the queries. This user is authenticated. Since this user is authorized to impersonate any user, queries through the established connection are run as `euser1`.

http://git-wip-us.apache.org/repos/asf/drill/blob/1dfec380/_docs/sql-reference/sql-window-functions/010-sql-window-functions-introduction.md
----------------------------------------------------------------------
diff --git a/_docs/sql-reference/sql-window-functions/010-sql-window-functions-introduction.md b/_docs/sql-reference/sql-window-functions/010-sql-window-functions-introduction.md
index d6567bd..8ca7f82 100644
--- a/_docs/sql-reference/sql-window-functions/010-sql-window-functions-introduction.md
+++ b/_docs/sql-reference/sql-window-functions/010-sql-window-functions-introduction.md
@@ -1,6 +1,6 @@
 ---
 title: "SQL Window Functions Introduction"
-date:  
+date: 2016-03-16 00:00:27 UTC
 parent: "SQL Window Functions"
 ---
 
@@ -134,10 +134,20 @@ and *order_list* is:
 
 and the optional *frame_clause* is one of the following frames:
 
-       RANGE UNBOUNDED PRECEDING
-       RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
-       RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
-       ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING  
+       { RANGE | ROWS } frame_start
+       { RANGE | ROWS } BETWEEN frame_start AND frame_end  
+
+where *frame_start* is one of the following choices: 
+ 
+       UNBOUNDED PRECEDING  
+       CURRENT ROW  
+
+and *frame_end* is one of the following choices:  
+
+       CURRENT ROW  
+       UNBOUNDED FOLLOWING  
+
+{% include startnote.html %}The *frame_end* choice cannot appear earlier than the *frame_start* choice and defaults to CURRENT ROW if not explicitly included.{% include endnote.html %}
 
 
 ## Arguments  
@@ -183,24 +193,23 @@ ASC | DESC
 Specifies sort order, either ascending or descending.  
 
 *frame_clause*  
-The frame\_clause specifies the group of rows that create the window frame. Currently, Drill only supports the default frame RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which sets the frame as all rows from the start of the partition through the current row's last peer in the ordering, as specified by the ORDER BY clause. The frame also includes ties when ordering is not unique. You cannot explicitly state the frame specification for ranking window functions.  
-
-When the OVER clause contains an ORDER BY clause, the following frames are equivalent to the default frame: 
- 
-       RANGE UNBOUNDED PRECEDING
-       RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW  
+For window functions that operate on the frame instead of the whole partition, the frame\_clause specifies the group of rows that create the window frame. The frame\_clause supports the following frames:  
 
-When the OVER clause does not contain an ORDER BY clause, the following frames are equivalent to the default frame:  
+* RANGE UNBOUNDED PRECEDING
+* RANGE BETWEEN CURRENT ROW AND CURRENT ROW
+* [RANGE | ROWS] BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
+* [RANGE | ROWS] BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING  
 
-       RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
-       ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING  
+The default frame is RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which is the same as RANGE UNBOUNDED PRECEDING. This frame sets the frame as all rows from the start of the partition through the current row's last peer in the ordering, as specified by the ORDER BY clause.  The frame also includes ties when ordering is not unique.  
 
 The following delimiters define the frame:  
 
-* UNBOUNDED PRECEDING means that the frame starts with the first row of the partition.
-* UNBOUNDED FOLLOWING means that the frame ends with the last row of the partition.
-* CURRENT ROW means that the frame starts or ends with the current row’s first or last peer in the ORDER BY list.  
-
+* UNBOUNDED PRECEDING  
+The frame starts with the first row of the partition.  
+* UNBOUNDED FOLLOWING  
+The frame ends with the last row of the partition, for both ROW and RANGE modes.  
+* CURRENT ROW  
+In ROWS mode, CURRENT ROW means that the frame starts or ends with the current row. In RANGE mode, CURRENT ROW means that the frame starts or ends with the current row’s first or last peer in the ORDER BY ordering.
 
 ## Usage Notes  
 

http://git-wip-us.apache.org/repos/asf/drill/blob/1dfec380/images/inboundImpersonation.PNG
----------------------------------------------------------------------
diff --git a/images/inboundImpersonation.PNG b/images/inboundImpersonation.PNG
new file mode 100644
index 0000000..e87cb48
Binary files /dev/null and b/images/inboundImpersonation.PNG differ