From derby-dev-return-88955-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Mon Jul 4 12:00:48 2011 Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3CC546550 for ; Mon, 4 Jul 2011 12:00:48 +0000 (UTC) Received: (qmail 83754 invoked by uid 500); 4 Jul 2011 12:00:48 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 83521 invoked by uid 500); 4 Jul 2011 12:00:47 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 83500 invoked by uid 99); 4 Jul 2011 12:00:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jul 2011 12:00:46 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jul 2011 12:00:45 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id BD82636E3A for ; Mon, 4 Jul 2011 12:00:24 +0000 (UTC) Date: Mon, 4 Jul 2011 12:00:22 +0000 (UTC) From: "Dag H. Wanvik (JIRA)" To: derby-dev@db.apache.org Message-ID: <151095241.1709.1309780822535.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <790802027.29851.1308762407377.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (DERBY-5292) SQLAuthorisation and views MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059402#comment-13059402 ] Dag H. Wanvik commented on DERBY-5292: -------------------------------------- Committed version "d" as svn 1142635. This is a back-port candidate, so I am not closing it yet. > SQLAuthorisation and views > -------------------------- > > Key: DERBY-5292 > URL: https://issues.apache.org/jira/browse/DERBY-5292 > Project: Derby > Issue Type: Bug > Components: SQL > Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2 > Environment: windows xp > Reporter: Thomas Hill > Fix For: 10.9.0.0 > > Attachments: derby5292a.diff, derby5292b.diff, derby5292b.stat, derby5292c.diff, derby5292c.stat, derby5292d.diff, derby5292d.stat, output.txt, script.txt > > > Hi, > in some cases there seem to be issues with SQLAuthorisation in conjunction with database VIEWS. > Please see attached files as repro (script.txt has only the SQL I executed, output is the output resulting when running the script). > I would think identical results should be returned in all cases and independent on how the view has been defined, but this to my surprise not being the case: > 1) Trying to select from view appl."VW_MyTasks" - which is a simple view defined on just one table - leads to expected results, i.e. "my" tasks are being returned. > 2) Trying to select from view appl."VW_MyPriorityTasks - which is a view defined on two joined tables without using an inner join clause - leads to expected results, i.e. "my" priority tasks are being returned. > 3) Trying to select from view appl."VW2_MyPriorityTasks - which is the same view but now the two tables joined using an inner join clause - leads to an error and no tasks returned (when the same results as in 2) above were expected). > 4) Trying to select from view appl."VW3_MyPriorityTasks" - which is a view defined using a subselect - also unexpectedly leads to an error. > Note: While I could rewrite each inner join clause with changing the syntax like in 2) above, this provides a simple work-around for such cases. May be there is a work-around for subselects also (not sure if every subselect could be rewritten to a join?). However when depending on using EXISTS constructs in the query there unfortunately is no way (I would know of) to get around this problem. Unfortuanetly a view that makes use of EXISTS is also one I would need to define in my data base... > Thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira