date:20080121


 [ 
https://issues.apache.org/jira/browse/DERBY-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen updated DERBY-3260:
--

Fix Version/s: 10.4.0.0

Committed revision 613815.

Will wait a few days before I back-port the fix to 10.3.

 NullPointerException caused by race condition in GenericActivationHolder
 

 Key: DERBY-3260
 URL: https://issues.apache.org/jira/browse/DERBY-3260
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 
 10.2.2.0, 10.3.1.4
Reporter: Robert Yokota
Assignee: Knut Anders Hatlen
Priority: Blocker
 Fix For: 10.4.0.0

 Attachments: d3260.diff, GenericActivationHolder.java.diff


 I have a stress test using Derby 10.3.1.4 which is executing the same 
 PreparedStatement using multiple threads concurrently and I consistently get 
 the following NPE after several hours of running:
 2007-12-07 00:48:10.914 GMT Thread[pool-5-thread-25,5,main] (XID = 1219661), 
 (SESSIONID = 377), (DATABASE = /usr/ironhide/var/db/opera/derby), (DRDAID = 
 null), Failed Statement is: select rdbmsvaria0_.GUID_AND_INDEX as GUID1_3_0_, 
 rdbmsvaria0_.VALUE2 as VALUE2_3_0_, rdbmsvaria0_.HOLDER_GUID as HOLDER3_3_0_, 
 rdbmsvaria0_.VALUE_TYPE as VALUE4_3_0_, rdbmsvaria0_.VALUE_GUID as 
 VALUE5_3_0_, rdbmsvaria0_.DELETED as DELETED3_0_ from VARIABLE rdbmsvaria0_ 
 where rdbmsvaria0_.GUID_AND_INDEX=? with 1 parameters begin parameter #1: 
 9C202AB9E8356288A9320C9C383A4D2F-11 :end parameter
 java.lang.NullPointerException
 at 
 org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:271)
 at 
 org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:368)
 at 
 org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1203)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652)
 at 
 org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:275)
 at 
 org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186)
 at org.hibernate.loader.Loader.getResultSet(Loader.java:1787)
 at org.hibernate.loader.Loader.doQuery(Loader.java:674)
 at 
 org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
 at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
 at 
 org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
 at 
 org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
 at 
 org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3044)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:395)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:179)
 at 
 org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
 at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
 at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815)
 at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808)
 at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301)
 at $Proxy41.get(Unknown Source)
 at 
 com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getRdbmsVariable(RdbmsContextHolder.java:108)
 at 
 com.approuter.maestro.opera.rdbms.RdbmsContextHolder.getVariable(RdbmsContextHolder.java:94)
 at com.approuter.maestro.vm.Frame.getParameter(Frame.java:218)
 at com.approuter.maestro.vm.Task.getParameter(Task.java:1267)
 at 
 com.approuter.maestro.vm.CallContextImpl.setOutputParameter(CallContextImpl.java:195)
 at 
 com.approuter.maestro.vm.CallContextImpl.getOutputParameterWriter(CallContextImpl.java:264)
 at 
 com.approuter.maestro.sdk.mpi.DynamicExecutableActivity$3$1.getWriter(DynamicExecutableActivity.java:249)
 at

[jira] Commented: (DERBY-3192) Cache session data in the client driver

[
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560975#action_12560975
]

Dyre Tjeldvoll commented on DERBY-3192:
---

I've finally managed to finish the writeup I promised. It can be found at
http://wiki.apache.org/db-derby/Derby3192Writeup

Cache session data in the client driver
---

Key: DERBY-3192
URL: https://issues.apache.org/jira/browse/DERBY-3192
Project: Derby
Issue Type: Improvement
Components: JDBC, Network Client, Network Server, Performance, SQL
Affects Versions: 10.3.1.4
Reporter: Dyre Tjeldvoll
Assignee: Dyre Tjeldvoll
Attachments: derby-3192-test.fup1.diff, derby-3192-test.fup2.diff,
derby-3192-test.v1.diff, derby-3192-test.v1.stat, derby-3192.prelim1.diff

The reason for doing this is to avoid a rather
substantial performance hit observed when the client driver is used
together with an appserver that uses connection pooling. There are two
problems:
1) The connection pool will compare the isolation level it has
stored for the connection with the value returned from
Connection.getTransactionIsolation() each and every time someone
requests a new connection from the pool.
2) The users of the connection pool (ab)use it to avoid having to keep
track of their current connection. So each time a query needs to be
executed a call to the connection pool's getConnection() method is
made. Getting a connection from the connection pool like this also
means that a new PreparedStatement must be prepared each time.
The net result is that each query results in the following sequence:
getConnection()
getTransactionIsolation() -- roundtrip + lookup in server's statement cache
prepareStatment() -- roundtrip + lookup in server's statement cache
executeQuery()-- roundtrip
Arguably this is a user error but when suggesting this I'm kindly
informed that this works just fine with other datbases (such as
PostgreSQL and ORACLE).
The reason why it works is that these databases do statement caching
in the driver. I've tried to implement a very (too) simple statement
cache in Derby's client driver and to re-enable caching of the
isolation level (see
https://issues.apache.org/jira/browse/DERBY-1148). With these changes
I observe a marked performance improvement when running with appserver
load.
A proper statment cache cannot be implemented without knowing what the
current schema is. If the current schema has changed since the
statement was prepared, it is no longer valid and must be evicted from
the cache.
The problem with caching both the isolation level and the current schema in
the driver is that both can change on the server without the client
detecting it (through SQL and XA and possibly stored procedures).
I think this problem can be overcome if we piggy-back the information we
would
like to cache on messages going back to the client. This can be done by
utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume
3,
page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD
in the reply,
I think it would be possible to cache additional session information when
this becomes relevant. It
would also be possible to use EXCSQLSET to batch session state changes
going from the client to the server.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3235) Implement the replication stop functionality

2008-01-21 Thread V.Narayanan (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560979#action_12560979
 ] 

V.Narayanan commented on DERBY-3235:


Ran junit all on this issue and did not see any failures. I do not expect any 
failures
in the old tests since this patch does not affect any part of that code.

I request for this patch to be considered for a commit.

 Implement the replication stop functionality
 

 Key: DERBY-3235
 URL: https://issues.apache.org/jira/browse/DERBY-3235
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: StopImplementation_v1.diff, StopImplementation_v1.stat, 
 StopImplementation_v1_NotForCommit.diff, 
 StopImplementation_v1_NotForCommit.stat, StopImplementation_v2.diff, 
 StopImplementation_v2.stat, StopImplementation_v3.diff, 
 StopImplementation_v3.stat




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-3235) Implement the replication stop functionality

2008-01-21 Thread V.Narayanan (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560979#action_12560979
 ] 

narayanan edited comment on DERBY-3235 at 1/21/08 2:50 AM:
-

Ran junit all on this issue and did not see any failures (except the usual 
access control exceptions I get on a freshworkspace also). I do not expect any 
failures
in the old tests since this patch does not affect any part of that code.

I request for this patch to be considered for a commit.

  was (Author: narayanan):
Ran junit all on this issue and did not see any failures. I do not expect 
any failures
in the old tests since this patch does not affect any part of that code.

I request for this patch to be considered for a commit.
  
 Implement the replication stop functionality
 

 Key: DERBY-3235
 URL: https://issues.apache.org/jira/browse/DERBY-3235
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: StopImplementation_v1.diff, StopImplementation_v1.stat, 
 StopImplementation_v1_NotForCommit.diff, 
 StopImplementation_v1_NotForCommit.stat, StopImplementation_v2.diff, 
 StopImplementation_v2.stat, StopImplementation_v3.diff, 
 StopImplementation_v3.stat




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3254) Implement the replication failover functionality


[ 
https://issues.apache.org/jira/browse/DERBY-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560983#action_12560983
 ] 

Øystein Grøvlen commented on DERBY-3254:


I do not understand the change to MasterController#startFailover.  It seems 
like handleFailoverFailure will be called in all cases now.  Also, exceptions 
thrown by handleFailoverFailure called from the try block, will be caught and 
passed to handeFailoverFailure by the catch block.  That seems a bit 
unnecessary.  I think the whole handling of ack, as it was in v4 of the patch, 
should be moved outside the try block.


 Implement the replication failover functionality
 

 Key: DERBY-3254
 URL: https://issues.apache.org/jira/browse/DERBY-3254
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: failover_impl_notforcommit.diff, 
 failover_impl_notforcommit.stat, failover_impl_v1.diff, 
 failover_impl_v1.stat, failover_impl_v2.diff, failover_impl_v2.stat, 
 failover_impl_v3.diff, failover_impl_v3.stat, failover_impl_v4.diff, 
 failover_impl_v4.stat, failover_impl_v5.diff, failover_impl_v5.stat




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560989#action_12560989
]

Knut Anders Hatlen commented on DERBY-3327:
---

What about changing the names of the methods instead? I don't think it's a bad
idea to spell out the scope of the role, and I only read Rick's comment as
saying that it would be good if the names matched.

java.util.Stack is a synchronized collection, by the way, so you may want to
consider using ArrayList instead. You have already added (push,pop)Caller()
methods, so the stack abstraction will be preserved even with a different data
structure.

SQL roles: Implement authorization stack

Key: DERBY-3327
URL: https://issues.apache.org/jira/browse/DERBY-3327
Project: Derby
Issue Type: New Feature
Components: Security, SQL
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
Fix For: 10.4.0.0

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat

The current LanguageConnectionContext keeps the user authorization identifier
for an SQL session.
The lcc is shared context also for nested connections (opened from stored
procedures).
So far, for roles, the current role has been stored in the lcc also. However,
SQL requires that
authorization identifers be pushed on a authorization stack when calling a
stored procedure, cf.
SQL 2003, vol 2, section 4.34.1.1 and 4.27.3.
This allows a caller to keep its current role after a call even if changed by
the stored procedure.
This issue will implement the current role name part (cell) of the
authorization stack.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3235) Implement the replication stop functionality


[ 
https://issues.apache.org/jira/browse/DERBY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560995#action_12560995
 ] 

Øystein Grøvlen commented on DERBY-3235:


Patch, StopImplementation_v3.diff, committed as revision 613866.
I tested that it is now possible to quit ij after the master has been stopped.

However, if I shut down the database without stopping replication, I still get 
the hang.
I think we need to stop the LogShipperThread in that case, too.  
(Alternatively, we could prevent
shut down of replicated databases). 


 Implement the replication stop functionality
 

 Key: DERBY-3235
 URL: https://issues.apache.org/jira/browse/DERBY-3235
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: StopImplementation_v1.diff, StopImplementation_v1.stat, 
 StopImplementation_v1_NotForCommit.diff, 
 StopImplementation_v1_NotForCommit.stat, StopImplementation_v2.diff, 
 StopImplementation_v2.stat, StopImplementation_v3.diff, 
 StopImplementation_v3.stat




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-163) Timestamps do not display trailing zeros

2008-01-21 Thread Sandeep A (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep A reassigned DERBY-163:
---

Assignee: Sandeep A

 Timestamps do not display trailing zeros
 

 Key: DERBY-163
 URL: https://issues.apache.org/jira/browse/DERBY-163
 Project: Derby
  Issue Type: Bug
  Components: Newcomer, SQL
Affects Versions: 10.0.2.0
 Environment: Windows XP Professional SP1
Reporter: George Baklarz
Assignee: Sandeep A
Priority: Minor

 The timestamp format within Derby contains the following information:
 -mm-dd-hh.mm.ss.mm
 When issuing a CURRENT TIMESTAMP function, it returns
 -mm-dd-hh.mm.ss.mmm
 If you do a TIMESTAMP('1988-12-15-17.12.30.123400') it will return
 1988-12-15-17.12.30.1234
 Is there any particular reason why Derby does not display the zeros at the 
 end of the field? This may just be just to be consistent with the ISO 
 standards, but if you look at the example in the manual, it shows:
   VALUES TIMESTAMP(START_DATE, END_DATE)
   1988-12-25-17.12.30.00
 If I try this with a simple table:
 CREATE TABLE TS (A DATE, B TIME);
 INSERT INTO TS VALUES (CURRENT DATE, CURRENT TIME);
 SELECT TIMESTAMP(A,B) FROM TS;
 ij select timestamp(a,b) from ts;
 1
 --
 2005-03-04 15:13:19.0
 So the 0's are not displayed, except for the first microsecond. The format 
 needs to be clarified either in the manuals or corrected in the program. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3192) Cache session data in the client driver


[ 
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561002#action_12561002
 ] 

Knut Anders Hatlen commented on DERBY-3192:
---

In the writeup, I read this:
 Most of the overhead seems to come from the PKGNAMCSN instance variable which 
 by itself uses 76 bytes

It does however seem like DRDA allows this variable to be skipped.

DRDA, ver. 4, vol 1, p 10:

 PKGNAM, PKGNAMCSN, PKGNAMCT
 The length is no longer fixed and is based on the lengths of the RDBNAM,
 RDBCOLID, and PKGID contained therein. As of SQLAM Level 7, the
 PKGNAMCSN instance variable is optional. If not specified, the PKGSN is
 required to identify the package section number. The package name and
 consistency token defaults to the last set of values specified on the 
 connection.

DRDA, ver. 4, vol 1, p 463:

 CU15 The fully qualified package name and package consistency token are not 
 required to be
 specified on every SQL-related request. If the package name and consistency 
 token are
 not specified on a request, the last request that specified the package name 
 and
 consistency token is used to identify the package name and consistency token 
 for the
 request. The package section number is not optional and is required if the 
 package
 name and consistency token are not specified. If the package name and 
 consistency
 token were not specified on a previous request to establish the default, the 
 request is
 rejected by the application server with a conversational protocol error with 
 the error
 code set to X'20' (default package name not established).

 Cache session data in the client driver
 ---

 Key: DERBY-3192
 URL: https://issues.apache.org/jira/browse/DERBY-3192
 Project: Derby
  Issue Type: Improvement
  Components: JDBC, Network Client, Network Server, Performance, SQL
Affects Versions: 10.3.1.4
Reporter: Dyre Tjeldvoll
Assignee: Dyre Tjeldvoll
 Attachments: derby-3192-test.fup1.diff, derby-3192-test.fup2.diff, 
 derby-3192-test.v1.diff, derby-3192-test.v1.stat, derby-3192.prelim1.diff


 The reason for doing this is to avoid a rather
 substantial performance hit observed when the client driver is used
 together with an appserver that uses connection pooling. There are two
 problems:
 1) The connection pool will compare the isolation level it has
 stored for the connection with the value returned from
 Connection.getTransactionIsolation() each and every time someone
 requests a new connection from the pool.
 2) The users of the connection pool (ab)use it to avoid having to keep
 track of their current connection. So each time a query needs to be
 executed a call to the connection pool's getConnection() method is
 made. Getting a connection from the connection pool like this also
 means that a new PreparedStatement must be prepared each time.
 The net result is that each query results in the following sequence:
 getConnection()
 getTransactionIsolation() -- roundtrip + lookup in server's statement cache
 prepareStatment() -- roundtrip + lookup in server's statement cache
 executeQuery()-- roundtrip
 Arguably this is a user error but when suggesting this I'm kindly
 informed that this works just fine with other datbases (such as
 PostgreSQL and ORACLE). 
 The reason why it works is that these databases do statement caching
 in the driver. I've tried to implement a very (too) simple statement
 cache in Derby's client driver and to re-enable caching of the
 isolation level (see
 https://issues.apache.org/jira/browse/DERBY-1148). With these changes
 I observe a marked performance improvement when running with appserver
 load. 
 A proper statment cache cannot be implemented without knowing what the
 current schema is. If the current schema has changed since the
 statement was prepared, it is no longer valid and must be evicted from
 the cache.
 The problem with caching both the isolation level and the current schema in
 the driver is that both can change on the server without the client
 detecting it (through SQL and XA and possibly stored procedures).
 I think this problem can be overcome if we piggy-back the information we 
 would 
 like to cache on messages going back to the client. This can be done by
 utilizing the EXCSQLSET DRDA command. According to the DRDA spec (v4, volume 
 3, 
 page 359-360) it is possible to add one or more SQLSTT objects after SQLCARD 
 in the reply,
 I think it would be possible to cache additional session information when 
 this becomes relevant.  It
 would also be possible to use EXCSQLSET to batch session state changes
 going from the client to the server.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3235) Implement the replication stop functionality


[ 
https://issues.apache.org/jira/browse/DERBY-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561003#action_12561003
 ] 

Jørgen Løland commented on DERBY-3235:
--

 Alternatively, we could prevent shut down of replicated databases

I don't think that's an option since that would break the shutdown server 
functionality. From the top of my head, I think server shutdown is implemented 
by first shutting down all booted databases and then shut down the server. If 
you throw an exception, e.g., shutdown server would result in a shutdown of the 
databases that by chance were iterated over before the replicated database was 
attempted shut down, but not the rest. Unless, of course, you want to change 
the shutdown server functionality as well...

 Implement the replication stop functionality
 

 Key: DERBY-3235
 URL: https://issues.apache.org/jira/browse/DERBY-3235
 Project: Derby
  Issue Type: Sub-task
  Components: Replication
Affects Versions: 10.4.0.0
Reporter: V.Narayanan
Assignee: V.Narayanan
 Attachments: StopImplementation_v1.diff, StopImplementation_v1.stat, 
 StopImplementation_v1_NotForCommit.diff, 
 StopImplementation_v1_NotForCommit.stat, StopImplementation_v2.diff, 
 StopImplementation_v2.stat, StopImplementation_v3.diff, 
 StopImplementation_v3.stat




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Request to add my JIRA id to the developers list

2008-01-21 Thread Abhishek

Hi,

Please add my id   dbz_a to the Derby developers list.

Regards,
Abhishek

[jira] Updated: (DERBY-3205) Replication: Add connection url command options for starting, stopping slave and for failover


 [ 
https://issues.apache.org/jira/browse/DERBY-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jørgen Løland updated DERBY-3205:
-

Attachment: stopSlave_v1a.stat
stopSlave_v1a.diff

The attached patch, stopSlave v1a, adds the functionality for stopSlave=true.

connect 'jdbc...;stopSlave=true' gives the following results:

* Unbooted DB or DB booted without startSlave: ERROR XRE40: Could not stop 
replication because the database is not in replication slave mode.
* Connection with master is up: ERROR XRE41: Replication operation 'failover' 
or 'stopSlave' failed because the connection with the master is working. Issue 
the 'failover' or 'stopMaster' operation on the master database instead.
* No connection with master: ERROR 08006: Database 'test' shutdown.

All tests passed. The patch is ready for review.

 Replication: Add connection url command options for starting, stopping slave 
 and for failover
 -

 Key: DERBY-3205
 URL: https://issues.apache.org/jira/browse/DERBY-3205
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: V.Narayanan
 Attachments: derby-3205_startslave_dontcommit.diff, 
 derby-3205_startslave_dontcommit.stat, 
 failover_impl_3205_NotForCommit_v1.diff, 
 failover_impl_3205_NotForCommit_v1.stat, failover_impl_3205_v1.diff, 
 failover_impl_3205_v1.stat, startSlave_1a.diff, startSlave_1a.stat, 
 startSlave_1b.diff, startSlave_1b.stat, startSlave_1c.diff, 
 startSlave_1d.diff, StopSlave_impl_3205_NotForCommit_v1.diff, 
 StopSlave_impl_3205_NotForCommit_v1.stat, stopSlave_v1a.diff, 
 stopSlave_v1a.stat


 Add commands to start and stop the replication slave using properties or 
 connection url. Example:
 'jdbc:derby:hostdbname;startSlave=true';
 'jdbc:derby:hostdbname;stopSlave=true';
 'jdbc:derby:hostdbname;failover=true;
 Connection url options that must be recognized:
 startSlave=true
 stopSlave=true
 failover=true
 slaveHost=host (optional, defaults to localhost) (only for startSlave)
 slavePort=port (optional, defaults to 8001) (only for startSlave)
 See functional specification on Derby-2872 for further details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Java ME and ToursDB

2008-01-21 Thread Vemund Ostgaard


Daniel John Debrunner wrote:
I just added a test org.apache.derbyTesting.junit.EnvTest that shows 
the environment that the Junit setup sees. It does this by changing 
the name of the fixture, e.g.


public void testJSR169() {
setName(JDBC.vmSupportsJSR169() + _vmSupportsJSR169());
}

When I run this in the swing ui test runner I see the updated names in 
the test hierarchy window.


I wonder if it would show different settings for weme6.1 and phoneME, 
leading to a different number of tests being run?

No swing in CDC/FP, but my modified textbased testrunner showed:

Test ended: 
true_hasTools(org.apache.derbyTesting.junit.EnvTest)duration: 0.014 (+0.014)
Test ended: 
true_hasEmbedded(org.apache.derbyTesting.junit.EnvTest)duration: 0.018 
(+0.001)
Test ended: 
false_hasClient(org.apache.derbyTesting.junit.EnvTest)duration: 0.018 (+0)
Test ended: 
true_hasServer(org.apache.derbyTesting.junit.EnvTest)duration: 0.021 
(+0.002)
Test ended: 
false_vmSupportsJDBC4()(org.apache.derbyTesting.junit.EnvTest)duration: 
0.022 (+0)
Test ended: 
false_vmSupportsJDBC3()(org.apache.derbyTesting.junit.EnvTest)duration: 
0.022 (+0)
Test ended: 
true_vmSupportsJSR169()(org.apache.derbyTesting.junit.EnvTest)duration: 
0.023 (+0)


Vemund

Re: Getting the LangaugeConnectionContext

2008-01-21 Thread Rick Hillegas


Jazarine Jamal wrote:

Really thanks for the reply...



Is it possible to get the LCC at some later point of execution : in 
the JDBCDisplayUtil?


I have got the Connection object in the function that i need. I want 
to if its possible to get the activation object related to the current 
connection.


By the way, why is that getCurrentLCC() throws an error when used in 
JDBCDisplayUtil but not when it is used in classes such as 
ConsistencyChecker, etc..?

Hi Jazarine,

The LanguageConnectionContext is the root of the SQL interpreter's state 
variable for a session. That is, the LCC is used to cache all sorts of 
information needed to parse, optimize, and execute queries. The LCC is a 
structure which only exists in the Derby engine layer, that is, it is 
only visible to code that is running on the server side of a JDBC 
connection.


JDBCDisplayUtil is tools code which runs outside the engine on the 
client side of a JDBC connection. JDBCDisplayUtil can run across the 
network in a remote client. In that remote layer, the LCC does not 
exist.  In contrast, ConsistencyChecker runs inside the engine.


Hope this helps,
-Rick




On Jan 20, 2008 6:07 PM, Thomas Nielsen  [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Hi Jazarine,

I'm assuming you need to get the LCC once you are in the execute
phase,
and in a class implementing ResultSet. All the different ResultSet
implementations in org.apache.derby.impl.sql.execute get an
activation
supplied to their constructor either directly, or through its
source/child ResultSet. It should hence be available either:
- as a member of the given ResultSet class
- though the ResultSets source/child ResultSet
- through getLanguageConnectionContext()
- or through getActivation().getLanguageConnectionContext()
depending on the ResultSet class implementation you are in.

It could be beneficial to have a look around
ProjectRestrictNodeResultSet, the top-most ResultSet for a SELECT qry,
and see how it's fetched/used?

Activations are created/built with an ActivationClassBuilder and is
populated during the bytecode generation phase. You can see one
example
of how the ActivationClassBuilder is used in
ProjectRestrictNode.generateMinion() in
org.apache.derby.impl.sql.compile. ProjectRestrictNode is the node
generating the ProjectRestrictNodeResultSet (and a few others for the
sake of correctness).
Generally we push objects to the stack, then call to
ActivationClassBuilder to push generation of the correct type of
ResultSet on the stack. This is where the actual Activation object is
created, and as previously stated it's often pushed as a parameter to
the ResultSet constructor. Once code generation is completed, we start
executing the generated bytecode. Someone with a little more
knowledge
of the details may want to explain this further, or correct me, if
necessary? :)

Hope this helps you figure it out :)

Thomas

Jazarine Jamal wrote:
 I need to get the langaugeconnectioncontext.
 I presume it can be done through this:


LangaugeConnectionContext=activation.getLangaugeConnectionContext()




 But How do I create an Activation object? Are there any implemented
 classes for Activation interface..??
 I am doing this since it forms a part of the code to get the type of
 an object.


 Please get me some help as soon as possible..

[jira] Commented: (DERBY-3192) Cache session data in the client driver

[
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561017#action_12561017
]

Dyre Tjeldvoll commented on DERBY-3192:
---

Thnak you, Knut. That is very good news!
I may need some time to digest the details, though.

Btw. You don't know if it is also legal to truncate/drop SQLCARD in the reply,
do you?

Cache session data in the client driver
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3205) Replication: Add connection url command options for starting, stopping slave and for failover


 [ 
https://issues.apache.org/jira/browse/DERBY-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jørgen Løland updated DERBY-3205:
-

Derby Info: [Patch Available]

 Replication: Add connection url command options for starting, stopping slave 
 and for failover
 -

 Key: DERBY-3205
 URL: https://issues.apache.org/jira/browse/DERBY-3205
 Project: Derby
  Issue Type: Sub-task
  Components: JDBC
Affects Versions: 10.4.0.0
Reporter: Jørgen Løland
Assignee: V.Narayanan
 Attachments: derby-3205_startslave_dontcommit.diff, 
 derby-3205_startslave_dontcommit.stat, 
 failover_impl_3205_NotForCommit_v1.diff, 
 failover_impl_3205_NotForCommit_v1.stat, failover_impl_3205_v1.diff, 
 failover_impl_3205_v1.stat, startSlave_1a.diff, startSlave_1a.stat, 
 startSlave_1b.diff, startSlave_1b.stat, startSlave_1c.diff, 
 startSlave_1d.diff, StopSlave_impl_3205_NotForCommit_v1.diff, 
 StopSlave_impl_3205_NotForCommit_v1.stat, stopSlave_v1a.diff, 
 stopSlave_v1a.stat


 Add commands to start and stop the replication slave using properties or 
 connection url. Example:
 'jdbc:derby:hostdbname;startSlave=true';
 'jdbc:derby:hostdbname;stopSlave=true';
 'jdbc:derby:hostdbname;failover=true;
 Connection url options that must be recognized:
 startSlave=true
 stopSlave=true
 failover=true
 slaveHost=host (optional, defaults to localhost) (only for startSlave)
 slavePort=port (optional, defaults to 8001) (only for startSlave)
 See functional specification on Derby-2872 for further details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Java ME and ToursDB

2008-01-21 Thread Knut Anders Hatlen

Vemund Ostgaard [EMAIL PROTECTED] writes:

 No swing in CDC/FP, but my modified textbased testrunner showed:

[...]

 true_hasServer(org.apache.derbyTesting.junit.EnvTest)duration: 0.021
 (+0.002)

Shouldn't Derby.hasServer() return false? Or do we support running the
server on Java ME?

-- 
Knut Anders

[jira] Commented: (DERBY-3323) ComparisonFailure in derbyStress

2008-01-21 Thread Ole Solberg (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561021#action_12561021
 ] 

Ole Solberg commented on DERBY-3323:


This failure is still seen on the 10.3 branch: e.g. 
http://dbtg.thresher.com/derby/test/statistics/3323_today.html (today = 
2008-01-21):
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/FailReports/613633_bySig.html
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/613633_bySig.html


 ComparisonFailure in derbyStress
 

 Key: DERBY-3323
 URL: https://issues.apache.org/jira/browse/DERBY-3323
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: jvm1.4 lin
 jvm1.5 lin, linN+1
 vm1.6 sles,sol, solN+1
 jvm1.5 w2003
Reporter: Ole Solberg
Assignee: Kathey Marsden
Priority: Minor

 See 
 jvm1.4 lin : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html
 jvm1.5 lin, jvm1.5 linN+1 : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html
 jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html
 jvm1.5 w2003: 
 http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html
 1) 
 derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure:
  Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- 
 unexpected exception ]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
   at 
 org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-2785) ij describe built in command cannot describe a table named run

2008-01-21 Thread Sandeep A (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandeep A reassigned DERBY-2785:


Assignee: Sandeep A

 ij describe built in command cannot describe a table named run
 --

 Key: DERBY-2785
 URL: https://issues.apache.org/jira/browse/DERBY-2785
 Project: Derby
  Issue Type: Bug
  Components: Tools
Affects Versions: 10.2.2.0
 Environment: OS-X, Java 1.5
Reporter: Tim Halloran
Assignee: Sandeep A
Priority: Minor

 steps to duplicate:
 (attach ij to any database)
 ij create table run (i int);
 0 rows inserted/updated/deleted
 ij desc run;
 ERROR 42X01: Syntax error: Encountered desc at line 1, column 1.
 ij 
 I think this is a parser problem within ij where the run is taken as a 
 token and that token is not included in the definition of a tablename 
 expression in the grammer (should be an easy fix).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3224) Get Suites.All to run on the phoneME advanced platform


 [ 
https://issues.apache.org/jira/browse/DERBY-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vemund Østgaard updated DERBY-3224:
---

Attachment: 3224-diffv3.stat
3224-diffv3

Updated patch adding an assertEquals() method for Time objects to 
BasedJDBCTestCase.

 Get Suites.All to run on the phoneME advanced platform
 --

 Key: DERBY-3224
 URL: https://issues.apache.org/jira/browse/DERBY-3224
 Project: Derby
  Issue Type: Test
  Components: Test
 Environment: Product: phoneME Advanced (phoneme_advanced_mr2-b34) 
 Profile: Foundation Profile Specification 1.1 
 JVM: CVM phoneme_advanced_mr2-b34 (interpreter loop) 
Reporter: Vemund Østgaard
Assignee: Vemund Østgaard
 Attachments: 3224-diff, 3224-diff.stat, 3224-diffv2, 
 3224-diffv2.stat, 3224-diffv3, 3224-diffv3.stat


 I'm trying to get suites.All to run on the phoneME advanced platform.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561030#action_12561030
]

Dag H. Wanvik commented on DERBY-3327:
--

Thanks for looking at this, Knut!

a) naming: Sounds like a good idea. You OK with that, Rick?

b) Yes, Stack is a bit heavy being based on Vector. I was looking at
Deque which is the recommended stack abstraction,
(cf. comment at top of
http://java.sun.com/javase/6/docs/api/java/util/Stack.html:

...A more complete and consistent set of LIFO stack operations is
provided by the Deque interface and its implementations, which
should be used in preference to this class.

but it is not available in 1.4, so ArrayList, although less
descriptive, is sufficient and probably the better choice here, I
agree.

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Getting the LangaugeConnectionContext


Jazarine Jamal wrote:

I have got the Connection object in the function that i need. I want to 
if its possible to get the activation object related to the current 
connection.


What are you trying to achieve here? Maybe there's some alternate 
solution that doesn't require the LCC, but it's hard to help unless it's 
known what problem you want to solve.


Dan.

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-21 Thread Bryan Pendleton (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561036#action_12561036
 ] 

Bryan Pendleton commented on DERBY-3301:


Perhaps there are some clues in this section of the manual:
http://db.apache.org/derby/docs/10.3/tuning/ctuntransform13699.html
In particular, this section:
http://db.apache.org/derby/docs/10.3/tuning/ctuntransform36368.html

I find it interesting that there are two levels of subquery flattening
going on here; that is, we have a subquery in the where clause of
a subquery which is itself in the where clause of the top-level query.
Perhaps the flattening logic is evaluating the correctness rules properly
for a single level of flattening but isn't handling 
flattening-within-flattening?


 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-21 Thread Bryan Pendleton (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561037#action_12561037
 ] 

Bryan Pendleton commented on DERBY-3301:


This slight variation of the query seems to return the correct 7 rows. The
change is that I removed the extra join of this_employees_e, and just
used unbound_e throughout:

ij select unbound_e.empid, unbound_p.projid
from departments this,
 employees unbound_e,
 projects unbound_p
where exists (
select 1 from project_employees this_employees_e_projects_p
where this_employees_e_projects_p.empid = unbound_e.empid
and unbound_e.department = this.id
and unbound_p.projid = this_employees_e_projects_p.projid
and unbound_e.empid = unbound_e.empid) ;

EMPID  |PROJID
---
11 |101
12 |101
12 |102
13 |101
13 |102
14 |103
15 |103

7 rows selected


 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY

[jira] Commented: (DERBY-3192) Cache session data in the client driver

[
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561042#action_12561042
]

Knut Anders Hatlen commented on DERBY-3192:
---

You don't know if it is also legal to truncate/drop SQLCARD in the reply, do
you?
No, I don't know.

I just noticed that the DRDA spec allows you to define product-unique
extensions as long as you're still able to talk to a server/client which
doesn't have the extension. I haven't studied the details, but you could take a
look at section 2.5.5.4 in DRDA ver 4, vol 3. Perhaps we could have a custom
OPNQRYRM/QRYDTA object which contained session state with minimal overhead?

Cache session data in the client driver
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3327) SQL roles: Implement authorization stack


 [ 
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik updated DERBY-3327:
-

Attachment: DERBY-3327-3.stat
DERBY-3327-3.diff

New version of the patch, DERBY-3327-3, which addresses both a) and b) above.
Running regression tests over again.

 SQL roles: Implement authorization stack
 

 Key: DERBY-3327
 URL: https://issues.apache.org/jira/browse/DERBY-3327
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
 Fix For: 10.4.0.0

 Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff, 
 DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat


 The current LanguageConnectionContext keeps the user authorization identifier 
 for an SQL session.
 The lcc is shared context also for nested connections (opened from stored 
 procedures).
 So far, for roles, the current role has been stored in the lcc also. However, 
 SQL requires that
 authorization identifers be pushed on a authorization stack when calling a 
 stored procedure, cf.
 SQL 2003, vol 2, section 4.34.1.1 and 4.27.3.
 This allows a caller to keep its current role after a call even if changed by 
 the stored procedure.
 This issue will implement the current role name part (cell) of the 
 authorization stack. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2109) System privileges

[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561045#action_12561045
]

Rick Hillegas commented on DERBY-2109:
--

Based on the recent discussions, I propose to change the functional spec as
follows--unless there are strong objections:

1) Change the shutdownEngine privilege to be just shutdown. This is a
better match for the behavior of this privilege, which controls the ability to
shutdown both the server and the engine. In the future, someone can add a
shutdownEngine privilege with the behavior that shutdown = shutdownEngine.

2) Change the name of the Principal class from DatabasePrincipal to
SystemPrincipal. This class will describe system-wide Principals. This
eliminates the need for the special @ syntax. Wildcarding can be accomplished
as John and Martin have described, so there is no need for the special * or
PUBLIC syntax. In the future, we can introduce a DatabasePrincipal if use cases
for this arise. We introduce no additional escaping cases on top of the
escaping syntax defined for the policy file.

3) Clarify that a SystemPrincipal represents a UserName. It is therefore
case-sensitive.

System privileges
-

Key: DERBY-2109
URL: https://issues.apache.org/jira/browse/DERBY-2109
Project: Derby
Issue Type: New Feature
Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat,
derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat,
DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff,
DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat,
DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat,
SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html,
systemPrivs.html, systemPrivs.html

Add mechanisms for controlling system-level privileges in Derby. See the
related email discussion at
http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
The 10.2 GRANT/REVOKE work was a big step forward in making Derby more
secure in a client/server configuration. I'd like to plug more client/server
security holes in 10.3. In particular, I'd like to focus on authorization
issues which the ANSI spec doesn't address.
Here are the important issues which came out of the email discussion.
Missing privileges that are above the level of a single database:
- Create Database
- Shutdown all databases
- Shutdown System
Missing privileges specific to a particular database:
- Shutdown that Database
- Encrypt that database
- Upgrade database
- Create (in that Database) Java Plugins (currently Functions/Procedures,
but someday Aggregates and VTIs)
Note that 10.2 gave us GRANT/REVOKE control over the following
database-specific issues, via granting execute privilege to system
procedures:
Jar Handling
Backup Routines
Admin Routines
Import/Export
Property Handling
Check Table
In addition, since 10.0, the privilege of connecting to a database has been
controlled by two properties (derby.database.fullAccessUsers and
derby.database.defaultConnectionMode) as described in the security section of
the Developer's Guide (see
http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561047#action_12561047
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

 3) Clarify that a SystemPrincipal represents a UserName. It is therefore 
 case-sensitive.

Do you mean authorization identifier instead of UserName since it's 
authorization identifiers that are case sensitive?

Or did you mean follows the rules for SQL identifiers instead of 
case-sensitive, since some user names are folded to upper case (and therefore 
appear case-insensitive) and some are stripped of their delimiting quotes (and 
hence appear case-sensitive). Ie. the rules are more compilcated than just case 
sensitivity.

 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3323) ComparisonFailure in derbyStress


[ 
https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561048#action_12561048
 ] 

Kathey Marsden commented on DERBY-3323:
---

I hestitated to port the fix to 10.3 because Dan had some concerns with the 
fix.  He especially did not like the gc, but it seems to me that as long as 
there are open result sets referring to the table it cannot be dropped.  Dan, 
do you have another recommendation for removing these references so we can drop 
the table?


 ComparisonFailure in derbyStress
 

 Key: DERBY-3323
 URL: https://issues.apache.org/jira/browse/DERBY-3323
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: jvm1.4 lin
 jvm1.5 lin, linN+1
 vm1.6 sles,sol, solN+1
 jvm1.5 w2003
Reporter: Ole Solberg
Assignee: Kathey Marsden
Priority: Minor

 See 
 jvm1.4 lin : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html
 jvm1.5 lin, jvm1.5 linN+1 : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html
 jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html
 jvm1.5 w2003: 
 http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html
 1) 
 derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure:
  Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- 
 unexpected exception ]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
   at 
 org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561050#action_12561050
]

Rick Hillegas commented on DERBY-3327:
--

Thanks for the new patch, Dag. Now that the method names and variable names
agree, it's easier for me to read the code.

What happens if you call popCallers() too many times? Will it fail gracefully
or could this method use a little defensive logic?

Thanks!

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-21 Thread Craig Russell (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561054#action_12561054
 ] 

Craig Russell commented on DERBY-3301:
--

Bryan This slight variation of the query seems to return the correct 7 rows. 

So the intermediate flattening of the query is probably causing the problem. 
Note that for more complex mappings from JDOQL to SQL, there will be even more 
intermediate EXISTS expressions.

I also found 
http://db.apache.org/derby/docs/10.3/tuning/ctuntransform25868.html that goes 
into some detail of the EXISTS join flattening.

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE |DISCRIMINATOR

[jira] Commented: (DERBY-2109) System privileges

[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561053#action_12561053
]

Rick Hillegas commented on DERBY-2109:
--

3) Clarify that a SystemPrincipal represents a UserName. It is therefore
case-sensitive.

Do you mean authorization identifier instead of UserName since it's
authorization identifiers that are case sensitive?

Or did you mean follows the rules for SQL identifiers instead of
case-sensitive, since some user names are folded to upper case (and
therefore appear case-insensitive) and some are stripped of their delimiting
quotes (and hence appear case-sensitive). Ie. the rules are more compilcated
than just case sensitivity.

Here I'm following up on my musings about the three concepts of identity which
I see in play here:

1) UserName -- this is part of the credentials passed to the authentication
service. This could be case-sensitive or case-insensitive depending on the
rules of the authentication service.

2) AuthorizationID -- this is the SQL concept of identity. This is
case-insensitive unless double-quoted.

3) SystemPrincipal -- I think that we would like to map this onto either (1) or
(2). I think that (1) is a better fit than (2). At the system level there is no
SQL context and the behavior/sobjects being controlled are not SQL
behaviors/objects.

System privileges
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


 [ 
https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik updated DERBY-2207:
-

Attachment: spec.html

Uploading rev. 6.0 of the specification.


 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Regression Test Report - Daily 613609 - Sun DBTG

2008-01-21 Thread Henri . Vandescheur

[Auto-generated mail]

*Daily* 613609/2008-01-20 18:00:59 MET

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
0273273 072.13% derbyall
01015710157 0   1333.25% suitesAll
 linN+1
2273271 0   162.65% derbyall
01015710157 0   116.95% suitesAll
 sles
2273271 074.61% derbyall
01015710157 0   936.60% suitesAll
 sol
0273273 076.14% derbyall
01015710157 0   1468.47% suitesAll
 solN+1
0273273 097.01% derbyall
01015710157 0   200.24% suitesAll
 sparc
0273273 065.80% derbyall
01015710157 0   355.11% suitesAll
 vista
0273273 093.61% derbyall
091359135 065.95% suitesAll
 w2003
0273273 095.62% derbyall
091359135 0   130.51% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-613609.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/613609_bySig.html 

*Jvm: 1.5*
 lin
0274274 071.27% derbyall
084398439 0   879.27% suitesAll
 linN+1
0274274 097.99% derbyall
084398439 0   116.55% suitesAll
 sles
0274274 070.81% derbyall
084398439 0   567.00% suitesAll
 sol
0274274 078.98% derbyall
084398439 0   835.34% suitesAll
 solN+1
0274274 087.80% derbyall
084398439 0   794.00% suitesAll
 sparc
0274274 066.37% derbyall
084398439 0   690.85% suitesAll
 vista
0274274 071.09% derbyall
074177417 0   398.62% suitesAll
 w2003
0274274 074.39% derbyall
074177417 0   255.94% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-613609.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/613609_bySig.html 

*Jvm: 1.4*
 lin
0271271 272.73% derbyall
083878387 0   793.27% suitesAll
 linN+1
0271271 299.12% derbyall
083878387 0   115.79% suitesAll
 sles
1271270 272.48% derbyall
083878387 0   526.01% suitesAll
 sol
1271270 285.19% derbyall
083878387 0   678.63% suitesAll
 solN+1
0271271 288.94% derbyall
083878387 0   752.21% suitesAll
 sparc
0271271 266.68% derbyall
083878387 0   689.65% suitesAll
 vista
0271271 271.19% derbyall
073657365 0   391.01% suitesAll
 w2003
0271271 275.04% derbyall
073667366 0   250.57% suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-613609.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/613609_bySig.html 

---

Changes in  http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/613609.txt 

( All results in http://dbtg.thresher.com/derby/test/ )

[jira] Subscription: Derby: JIRA issues with patch available

2008-01-21 Thread jira

Issue Subscription
Filter: Derby: JIRA issues with patch available (14 issues)
Subscriber: derby-dev


Key Summary
DERBY-3327  SQL roles: Implement authorization stack
https://issues.apache.org/jira/browse/DERBY-3327
DERBY-3205  Replication: Add connection url command options for starting, 
stopping slave and for failover
https://issues.apache.org/jira/browse/DERBY-3205
DERBY-3254  Implement the replication failover functionality
https://issues.apache.org/jira/browse/DERBY-3254
DERBY-3050  Convert groupBy.sql tests to JUnit and include them in 
GroupByTest.java
https://issues.apache.org/jira/browse/DERBY-3050
DERBY-3137  SQL roles: add catalog support
https://issues.apache.org/jira/browse/DERBY-3137
DERBY-3324  JDBC statement cache implementation
https://issues.apache.org/jira/browse/DERBY-3324
DERBY-3088  convert to junit, or otherwise eliminate version in tests which 
require an update of the master in the release management process
https://issues.apache.org/jira/browse/DERBY-3088
DERBY-3169  Add documentation for replication
https://issues.apache.org/jira/browse/DERBY-3169
DERBY-3184  Replication: Connection attempts to a database in slave mode must 
fail
https://issues.apache.org/jira/browse/DERBY-3184
DERBY-2871  XATransactionTest gets XaException: Error executing a 
XAResource.commit(), server returned XAER_PROTO.
https://issues.apache.org/jira/browse/DERBY-2871
DERBY-3117  Adjust master build script to require the Java 5 compiler to build 
Derby
https://issues.apache.org/jira/browse/DERBY-3117
DERBY-2953  Dump the information about rollbacks of the global transaction 
(introduced in DERBY-2220 and DERBY-2432) to derby.log
https://issues.apache.org/jira/browse/DERBY-2953
DERBY-3083  Network server demands a file called derbynet.jar in classpath
https://issues.apache.org/jira/browse/DERBY-3083
DERBY-3227  Remove final from all getConnection() methods in EmbeddedDataSource
https://issues.apache.org/jira/browse/DERBY-3227

[jira] Commented: (DERBY-3257) SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB


[ 
https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561065#action_12561065
 ] 

A B commented on DERBY-3257:


Thank you for investigating this further, and for posting a complete patch, 
Kathey.  I verified that the new test case passes with the changes and fails 
without them.

 We clearly are not setup to handle subquery flattenning within the having 
 clause

This is good to know.  Just curious: is there something in the code that makes 
this limitation explicit, or does this statement just follow from the fact that 
attempts to flatten such a subquery lead to other errors?

Very minor nits on the patch that you can ignore if you choose:

  - Might be good to add another bullet to the list in the comment preceding 
the following
line, so that the comments and the code match each other.

@@ -609,7 +615,7 @@
-underTopAndNode 
+   underTopAndNode  !havingSubquery 

Likewise for the other, similar change further down in that method.

  - Some whitespace inconsistencies between new code and existing code.

  - Maybe the new test case in GroupByTest would be better called 
testOrNodeInHavingClause()
instead of testDerby3257?  This doesn't affect the test at all, and the 
comments for the fixture
clearly indicate what is being tested, so this is definitely nit-picking. 
 But a meaningful method
name seems (to me, as reader of the test) slightly more convenient than the 
Derby Jira number.

But these nits aside, if you've run derbyall and suites.All with this change 
and there were no failures, I think the patch can be committed...

 SELECT with HAVING clause containing OR conditional incorrectly return 1 row 
 - should return 2 rows - works correctly with 10.2 DB
 --

 Key: DERBY-3257
 URL: https://issues.apache.org/jira/browse/DERBY-3257
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Reporter: Stan Bradbury
Assignee: Kathey Marsden
 Attachments: 42X24_error.sql, d3257_doNOTCommit.patch, 
 derby-3257_diff.txt, derby-3257_plan_10.2.txt, derby-3257_plan_10.4.txt, 
 derby-3257_stat.txt, TestHaving.java


 Attached program demonstrates the problem.  Only one count is returned 
 (matching CODE= GBR) - the count of CODE=CHA is not returned.  Works fine 
 with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 
 database (soft upgrade).
 Query:
 SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 
   GROUP BY t0.CODE 
 HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL
 Incorrect results (see last line):
 Database product: Apache Derby
 Database version: 10.3.1.5 - (579866)
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.3.1.5 - (579866)
 result: 2
 Correct results:
 Database product: Apache Derby
 Database version: 10.2.2.0 - (485682)
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.2.2.0 - (485682)
 result: 4
 result: 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


 [ 
https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik updated DERBY-2207:
-

Attachment: (was: spec.html)

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2207) Improve usability of Derby's client/server security by implementing ANSI Roles


 [ 
https://issues.apache.org/jira/browse/DERBY-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik updated DERBY-2207:
-

Attachment: spec.html

 Improve usability of Derby's client/server security by implementing ANSI Roles
 --

 Key: DERBY-2207
 URL: https://issues.apache.org/jira/browse/DERBY-2207
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Rick Hillegas
Assignee: Dag H. Wanvik
 Attachments: spec.html, spec.html, spec.html, spec.html, spec.html, 
 spec.html


 Implementing ANSI Roles will make it easier to manage security for multi-user 
 applications with high user turnover.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561069#action_12561069
]

Dag H. Wanvik commented on DERBY-3327:
--

It will give an IndexOutOfBoundsException, but it should never happen unless
there is a
coding error, so I chose not to add any logic. Better to make it fail early, I
think?

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-1749) Implement Bracketed SQL comments (/.../ comments)


 [ 
https://issues.apache.org/jira/browse/DERBY-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik closed DERBY-1749.



Did not hear back from reporter, so closing.


 Implement Bracketed SQL comments (/*...*/ comments)
 ---

 Key: DERBY-1749
 URL: https://issues.apache.org/jira/browse/DERBY-1749
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4
Reporter: Conny Kreyßel
Assignee: James F. Adams
 Fix For: 10.4.0.0

 Attachments: d1749-ref-single.html.diff, 
 d1749-ref-single.html.diff-2, d1749-rrefsqlj28468.dita.diff, 
 d1749-rrefsqlj28468.html.diff, d1749-rrefsqlj28468.html.diff-2, 
 Derby-1749-2.txt, Derby-1749-3.diff, Derby-1749-4.diff, DERBY-1749.diff, 
 releaseNote.html


 Hibernate use multiline sql statements to show the internal building of the 
 hql statements. You can disable this feature, but it would be nice if you can 
 implements bracketed SQL comments in Derby.
 Thanks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561073#action_12561073
 ] 

A B commented on DERBY-3301:


bryan Perhaps the flattening logic is evaluating the correctness rules properly
bryan for a single level of flattening but isn't handling 
flattening-within-flattening? 

Without having done any explicit tracing myself, this is what I would guess is 
the
problem.  Perhaps the inner-most EXISTS subquery can be considered an exists
base table (and thus only returns a single row) w.r.t. it's parent query, but 
if it is
then flattened _again_ to the outer-most query, maybe it should no longer be 
marked
as an exists base table?  I don't if that's actually true, I'm just 
speculating.

craig I also found 
http://db.apache.org/derby/docs/10.3/tuning/ctuntransform25868.html that
craig goes into some detail of the EXISTS join flattening

Something from that page which stands out to me is the following condition:

  None of the predicates in the subquery, including the additional one formed 
between the
  left side of the subquery operator and the column in the subquery's SELECT 
list (for IN or
  ANY subqueries), include any subqueries, method calls, or field accesses.

If an EXISTS clause is considered a predicate, then the query 

  select ...  from ...
  where exists (
select 1 from ...
where exists (
select 1 from ...
  ...

seems to violate the condition quoted above from the documentation.  That is, 
the subquery
for the first EXISTS has a predicate (in this case another EXISTS query) which 
includes
another subquery (select 1 from ...), and therefore the first subquery should 
not be flattened.
Or am I misreading?  If this is the correct reading then the bug would appear 
to be in the logic
that checks for the aforementioned condition--presumably because that check 
occurs after
the inner-most subquery has itself been flattened?  Just guessing...feel free 
to ignore.

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561074#action_12561074
 ] 

Rick Hillegas commented on DERBY-2109:
--

Just to clarify that username/password credentials are case-sensitive, I ran 
the following experiment: I created my own UserAuthenticator implementation, 
wired it into derby.properties, and then connected. The custom 
UserAuthenticator printed out the arguments which Derby passed to it. Those 
arguments are case sensitive, so it is up to the UserAuthenticator to determine 
the rules it wants to enforce.

Here is my custom UserAuthenticator:

import org.apache.derby.authentication.UserAuthenticator;

import java.util.Properties;
import java.sql.SQLException;

/**
  * Dummy authenticator. All users are legal
  *
  * @see org.apache.derby.authentication.UserAuthenticator 
  */

public class DummyAuthenticator implements UserAuthenticator
{
public DummyAuthenticator() {}

/**
 * Authenticate the passed-in user's credentials.
 * A more complex class could make calls
 * to any external users directory.
 *
 * @param userName   The user's name
 * @param userPassword   The user's password 
 * @param databaseName   The database 
 * @param infoAdditional jdbc connection info.
 * @exception SQLException on failure
 */
public boolean authenticateUser(String userName,
 String userPassword,
 String databaseName,
 Properties info)
   throws SQLException 
{
System.out.println( userName =  + userName + \nuserPassword =  + 
userPassword + \ndatabaseName =  + databaseName );
System.out.println( info =  + info );

return true;
}
}

Here is my derby.properties:

derby.connection.requireAuthentication=true
derby.authentication.provider=DummyAuthenticator

And here is an ij script showing how this behaves at run-time:

ij version 10.4
ij connect 'jdbc:derby:derby10.4;user=myHumbleSelf;password=myHumblePassword';
userName = myHumbleSelf
userPassword = myHumblePassword
databaseName = derby10.4
info = {user=myHumbleSelf, password=myHumblePassword}
ij select count(*) from sys.systables;
1  
---
24 

1 row selected
ij userName = null
userPassword = null
databaseName = null
info = {shutdown=true}


 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561075#action_12561075
]

Rick Hillegas commented on DERBY-3327:
--

Thanks, Dag. I agree that since this is an internal error (triggered by a bug
in Derby) that the IndexOutOfBoundsException is good enough. Cheers-Rick

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-3301) Incorrect result from query with nested EXIST


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561073#action_12561073
 ] 

army edited comment on DERBY-3301 at 1/21/08 9:34 AM:
-

bryan Perhaps the flattening logic is evaluating the correctness rules properly
bryan for a single level of flattening but isn't handling 
flattening-within-flattening? 

Without having done any explicit tracing myself, this is what I would guess is 
the problem.  Perhaps the inner-most EXISTS subquery can be considered an 
exists base table (and thus only returns a single row) w.r.t. it's parent 
query, but if it is then flattened _again_ to the outer-most query, maybe it 
should no longer be marked as an exists base table?  I don't if that's 
actually true, I'm just speculating.

craig I also found 
http://db.apache.org/derby/docs/10.3/tuning/ctuntransform25868.html that
craig goes into some detail of the EXISTS join flattening

Something from that page which stands out to me is the following condition:

  None of the predicates in the subquery, including the additional one formed
  between the left side of the subquery operator and the column in the 
subquery's
  SELECT list (for IN or ANY subqueries), include any subqueries, method calls,
  or field accesses.

If an EXISTS clause is considered a predicate, then the query 

  select ...  from ...
  where exists (
select 1 from ...
where exists (
select 1 from ...
  ...

seems to violate the condition quoted above from the documentation.  That is, 
the
subquery for the first EXISTS has a predicate (in this case another EXISTS 
query) which includes another subquery (select 1 from ...), and therefore the 
first subquery should not be flattened.  If this is the correct reading then 
the bug would appear to be in the logic that checks for the aforementioned 
condition--presumably because that check occurs after the inner-most subquery 
has itself been flattened?  Again, I'm just guessing, I haven't done much 
examination of the actual codepath...

  was (Author: army):
bryan Perhaps the flattening logic is evaluating the correctness rules 
properly
bryan for a single level of flattening but isn't handling 
flattening-within-flattening? 

Without having done any explicit tracing myself, this is what I would guess is 
the
problem.  Perhaps the inner-most EXISTS subquery can be considered an exists
base table (and thus only returns a single row) w.r.t. it's parent query, but 
if it is
then flattened _again_ to the outer-most query, maybe it should no longer be 
marked
as an exists base table?  I don't if that's actually true, I'm just 
speculating.

craig I also found 
http://db.apache.org/derby/docs/10.3/tuning/ctuntransform25868.html that
craig goes into some detail of the EXISTS join flattening

Something from that page which stands out to me is the following condition:

  None of the predicates in the subquery, including the additional one formed 
between the
  left side of the subquery operator and the column in the subquery's SELECT 
list (for IN or
  ANY subqueries), include any subqueries, method calls, or field accesses.

If an EXISTS clause is considered a predicate, then the query 

  select ...  from ...
  where exists (
select 1 from ...
where exists (
select 1 from ...
  ...

seems to violate the condition quoted above from the documentation.  That is, 
the subquery
for the first EXISTS has a predicate (in this case another EXISTS query) which 
includes
another subquery (select 1 from ...), and therefore the first subquery should 
not be flattened.
Or am I misreading?  If this is the correct reading then the bug would appear 
to be in the logic
that checks for the aforementioned condition--presumably because that check 
occurs after
the inner-most subquery has itself been flattened?  Just guessing...feel free 
to ignore.
  
 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E

[jira] Commented: (DERBY-2109) System privileges

[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561076#action_12561076
]

Daniel John Debrunner commented on DERBY-2109:
--

Rick wrote:

2) AuthorizationID -- this is the SQL concept of identity. This is
case-insensitive unless double-quoted.

We seem to be using the same terms for slightly different concepts.

I believe I'm using authorization identifier in the way that the SQL standard
defines it. This would be a case-sensitive value that defines a unique identity
in the sql system (database). Thus an authorization identifier is never double
quoted, contradicting your statement 2).

A UserName is a representation of an authorization identifier using the SQL
rules for regular and delimited identifiers and thus has the case folding rules
etc.

In SQL this behaviour, mapping UserName to authorization identifier is defined
by the standard.

In Java code and Java property files Derby chose to use SQL identifier rules
(ie. UserName) as the representation of an authorization identifier. Looking
back this maybe was a poor choice, a direct representation of the authorization
identifier might have been better, (ie. jdbc:derby:cs;user=fred and
jdbc:derby:cs;user=FRED would connect as different authorization ids, today
they map to the same authorization id). So if we want to be consistent with
other Java uses, the policy file should probably use UserName, however using
authorization identifier might be clearer.

1) UserName -- this is part of the credentials passed to the authentication
service. This could be case-sensitive or case-insensitive depending on the
rules of the authentication service.

I think the last sentence is incorrect. The rules of UserName are set by Derby,
not an arbitrary implementation of the authentication service.
As above, the rules for how UserName map to a unique identity follows the rules
of SQL identifiers, and thus UserNames of FRED and fred always map to the same
unique identity FRED. However, I'm not sure you agree with this, since you are
promoting authorization identifier as a SQL only concept. That may be a valid
approach, but I think you need to clearly state the rules for that, and then we
can discuss if having two different models (one for database and one for
system) adds any benefit or adds complication. The rules would need to state
how UserName maps to a unique identity in a system context.

System privileges
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3194) LOCALIZEDDISPLAY of CURRENT_TIMESTAMP returns only the TIME


[ 
https://issues.apache.org/jira/browse/DERBY-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561077#action_12561077
 ] 

Dag H. Wanvik commented on DERBY-3194:
--

Merged to 10.3 branch as svn 613948, closing.


 LOCALIZEDDISPLAY of CURRENT_TIMESTAMP returns only the TIME
 ---

 Key: DERBY-3194
 URL: https://issues.apache.org/jira/browse/DERBY-3194
 Project: Derby
  Issue Type: Bug
  Components: Localization, Tools
Affects Versions: 10.3.1.4
Reporter: Stan Bradbury
Assignee: Dag H. Wanvik
Priority: Trivial
 Fix For: 10.4.0.0

 Attachments: DERBY-3194.diff


 In IJ - LOCALIZEDDISPLAY ON causes  VALUES CURRENT_TIMESTAMP to display on 
 the TIME
 ij values current_timestamp;
 1
 --
 2007-11-09 10:37:58.828
 1 row selected
 ij localizeddisplay on;
 ij values current_timestamp;
 1
 ---
 10:38:10 AM PST
 1 row selected

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3194) LOCALIZEDDISPLAY of CURRENT_TIMESTAMP returns only the TIME


[ 
https://issues.apache.org/jira/browse/DERBY-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561078#action_12561078
 ] 

Dag H. Wanvik commented on DERBY-3194:
--

Can we close this on now, Stan?


 LOCALIZEDDISPLAY of CURRENT_TIMESTAMP returns only the TIME
 ---

 Key: DERBY-3194
 URL: https://issues.apache.org/jira/browse/DERBY-3194
 Project: Derby
  Issue Type: Bug
  Components: Localization, Tools
Affects Versions: 10.3.1.4
Reporter: Stan Bradbury
Assignee: Dag H. Wanvik
Priority: Trivial
 Fix For: 10.4.0.0

 Attachments: DERBY-3194.diff


 In IJ - LOCALIZEDDISPLAY ON causes  VALUES CURRENT_TIMESTAMP to display on 
 the TIME
 ij values current_timestamp;
 1
 --
 2007-11-09 10:37:58.828
 1 row selected
 ij localizeddisplay on;
 ij values current_timestamp;
 1
 ---
 10:38:10 AM PST
 1 row selected

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-3301) Incorrect result from query with nested EXIST


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561073#action_12561073
 ] 

army edited comment on DERBY-3301 at 1/21/08 9:35 AM:
-

bryan Perhaps the flattening logic is evaluating the correctness rules properly
bryan for a single level of flattening but isn't handling 
flattening-within-flattening? 

Without having done any explicit tracing myself, this is what I would guess is 
the 
problem.  Perhaps the inner-most EXISTS subquery can be considered an exists 
base table (and thus only returns a single row) w.r.t. it's parent query, but 
if it is then 
flattened _again_ to the outer-most query, maybe it should no longer be marked 
as 
an exists base table?  I don't if that's actually true, I'm just speculating.

craig I also found 
http://db.apache.org/derby/docs/10.3/tuning/ctuntransform25868.html that
craig goes into some detail of the EXISTS join flattening

Something from that page which stands out to me is the following condition:

  None of the predicates in the subquery, including the additional one formed
  between the left side of the subquery operator and the column in the 
subquery's
  SELECT list (for IN or ANY subqueries), include any subqueries, method calls,
  or field accesses.

If an EXISTS clause is considered a predicate, then the query 

  select ...  from ...
  where exists (
select 1 from ...
where exists (
select 1 from ...
  ...

seems to violate the condition quoted above from the documentation.  That is, 
the
subquery for the first EXISTS has a predicate (in this case another EXISTS 
query) 
which includes another subquery (select 1 from ...), and therefore the first 
subquery should not be flattened.  If this is the correct reading then the bug 
would 
appear to be in the logic that checks for the aforementioned 
condition--presumably 
because that check occurs after the inner-most subquery has itself been 
flattened?  
Again, I'm just guessing, I haven't done much examination of the actual 
codepath...

  was (Author: army):
bryan Perhaps the flattening logic is evaluating the correctness rules 
properly
bryan for a single level of flattening but isn't handling 
flattening-within-flattening? 

Without having done any explicit tracing myself, this is what I would guess is 
the problem.  Perhaps the inner-most EXISTS subquery can be considered an 
exists base table (and thus only returns a single row) w.r.t. it's parent 
query, but if it is then flattened _again_ to the outer-most query, maybe it 
should no longer be marked as an exists base table?  I don't if that's 
actually true, I'm just speculating.

craig I also found 
http://db.apache.org/derby/docs/10.3/tuning/ctuntransform25868.html that
craig goes into some detail of the EXISTS join flattening

Something from that page which stands out to me is the following condition:

  None of the predicates in the subquery, including the additional one formed
  between the left side of the subquery operator and the column in the 
subquery's
  SELECT list (for IN or ANY subqueries), include any subqueries, method calls,
  or field accesses.

If an EXISTS clause is considered a predicate, then the query 

  select ...  from ...
  where exists (
select 1 from ...
where exists (
select 1 from ...
  ...

seems to violate the condition quoted above from the documentation.  That is, 
the
subquery for the first EXISTS has a predicate (in this case another EXISTS 
query) which includes another subquery (select 1 from ...), and therefore the 
first subquery should not be flattened.  If this is the correct reading then 
the bug would appear to be in the logic that checks for the aforementioned 
condition--presumably because that check occurs after the inner-most subquery 
has itself been flattened?  Again, I'm just guessing, I haven't done much 
examination of the actual codepath...
  
 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM

[jira] Updated: (DERBY-3194) LOCALIZEDDISPLAY of CURRENT_TIMESTAMP returns only the TIME


 [ 
https://issues.apache.org/jira/browse/DERBY-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik updated DERBY-3194:
-

Fix Version/s: 10.3.2.2

 LOCALIZEDDISPLAY of CURRENT_TIMESTAMP returns only the TIME
 ---

 Key: DERBY-3194
 URL: https://issues.apache.org/jira/browse/DERBY-3194
 Project: Derby
  Issue Type: Bug
  Components: Localization, Tools
Affects Versions: 10.3.1.4
Reporter: Stan Bradbury
Assignee: Dag H. Wanvik
Priority: Trivial
 Fix For: 10.3.2.2, 10.4.0.0

 Attachments: DERBY-3194.diff


 In IJ - LOCALIZEDDISPLAY ON causes  VALUES CURRENT_TIMESTAMP to display on 
 the TIME
 ij values current_timestamp;
 1
 --
 2007-11-09 10:37:58.828
 1 row selected
 ij localizeddisplay on;
 ij values current_timestamp;
 1
 ---
 10:38:10 AM PST
 1 row selected

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561080#action_12561080
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

Rick Hillegas (JIRA) wrote:

 Those arguments are case sensitive, so it is up to the UserAuthenticator to 
 determine the rules it wants to enforce.

But is such a class honouring the UserAuthenticator api when it does that? The 
description for authenticateUser states that an unquoted user name is treated 
as a case-insensitive authorization identifier by Derby's authorization 
system. While this is technically incorrect, (see DERBY-3334), the intention 
behind the text is to follow SQL identifier rules for converting the parameter 
userName to a unique authorization identifier within Derby. This can be seen by 
the fact this mapping will be followed:

   userName (in authenticateUser) -- VALUES CURRENT_USER

   myHumbleSelf -- MYHUMBLESELF
   MYHUMBLESELF-- MYHUMBLESELF
   myHumbleSelf  -- myHumbleSelf

 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Db-derby Wiki] Update of UserIdentifiers by DanDebrunner

2008-01-21 Thread Dag H. Wanvik

Apache Wiki [EMAIL PROTECTED] writes:

 Earlier versions of this document used ''normal user name'' to
 represent ''authorization identifier''.

The term authorization identifier is used in the standard to cover
both user identifier and role name, cf. section 5.4:

 authorization identifier ::=
   role name
 | user identifier 

Would is perhaps be better to reserve the more generic term
authorization identifer to those cases when either a user or a role
meant, and rather user user identifier when talking about users
only?

Dag

[jira] Commented: (DERBY-2109) System privileges

[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561086#action_12561086
]

Rick Hillegas commented on DERBY-2109:
--

Thanks for the continued discussion, Dan. I agree that we seem to be talking
past one another.

2) AuthorizationID -- this is the SQL concept of identity. This is
case-insensitive unless double-quoted.

We seem to be using the same terms for slightly different concepts.

I believe I'm using authorization identifier in the way that the SQL standard
defines it. This would be a case-sensitive value that defines a unique
identity in the sql system (database). Thus an authorization identifier is
never double quoted, contradicting your statement 2).

I think the relevant section of the SQL spec is part 2 section 5.4 (names and
identifiers). In that section authorization identifier can resolve to be a
user identifier which in turn can resolve to an identifier which in turn
can resolve to a regular identifier or a delimited identifier. The regular
identifier is uppercased to a normalized value regardless of its original
casing and the delimited identifer is quoted and is not uppercased. This is
what I mean by This is case-insensitive unless double-quoted.

I think the disconnect here is that the authorization identifier can be
referenced in two ways. When it is used in a SQL statement and resolves to a
regular identifier, it is normalized to uppercase and so, as I would put it,
it is case-insensitive. When it is referenced in the form stored in the system
catalogs, it is case-sensitive.

A UserName is a representation of an authorization identifier using the SQL
rules for regular and delimited identifiers and thus has the case folding
rules etc.

The term UserName is a word I invented for this discussion. But it pretty much
corresponds to userName as used in the javadoc for UserAuthenticator.

In SQL this behaviour, mapping UserName to authorization identifier is defined
by the standard.

This is where I am not tracking you. The term UserName does not occur in the
SQL standard as far as I know. It is a term which I thought I invented in order
to bring some precision to this discussion. But I don't seem to have succeeded.
Can you refer me to the section of the SQL standard which defines this term (or
a related term)? That will help me propose some new language which we can agree
on.

In Java code and Java property files Derby chose to use SQL identifier rules
(ie. UserName) as the representation of an authorization identifier. Looking
back this maybe was a poor choice, a direct representation of the
authorization identifier might have been better, (ie. jdbc:derby:cs;user=fred
and jdbc:derby:cs;user=FRED would connect as different authorization ids,
today they map to the same authorization id). So if we want to be consistent
with other Java uses, the policy file should probably use UserName, however
using authorization identifier might be clearer.

1) UserName -- this is part of the credentials passed to the authentication
service. This could be case-sensitive or case-insensitive depending on the
rules of the authentication service.

I think the last sentence is incorrect. The rules of UserName are set by
Derby, not an arbitrary implementation of the authentication service.
As above, the rules for how UserName map to a unique identity follows the
rules of SQL identifiers, and thus UserNames of FRED and fred always map to
the same unique identity FRED. However, I'm not sure you agree with this,
since you are promoting authorization identifier as a SQL only concept. That
may be a valid approach, but I think you need to clearly state the rules for
that, and then we can discuss if having two different models (one for database
and one for system) adds any benefit or adds complication. The rules would
need to state how UserName maps to a unique identity in a system context.

Ha! Once we can agree on some terms, I can take another crack at stating the
rules.

Thanks.

System privileges
-

Add mechanisms for controlling system-level privileges in Derby. See the
related email

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561087#action_12561087
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

On the current patch itself I have some questions:

1) Since J2ME/CDC/Foundation does not support some of the security classes 
used, how is this being handled? Seems like it isn't at the moment. I think a 
new abstract method is needed in InternalDriver called shutdownCheck() is 
needed that would do nothing in J2ME but call the checks (through SecurityUtil 
in J2SE.

2) Any thought on backwards compatibility for the network shutdown command in 
terms of the DRDA protocol? Seems like the on-wire format for the shutdown 
command has changed by adding in the user and password fields. What happens if 
an old version of Derby tries to shutdown a 10.4 server?

3) I'd like to see more comments around the use of doAsPrivileged (e.g. why is 
this needed rather than doAs, why pass in a null ACC
and the nesting of doAsPrivileged in a doPrivileged call (why is this needed). 
I'm not sure that the code is using these correctly and given this is security 
code we need to understand why one is used instead of the other, rather than a 
comment like doAs is not strong enough (in the test).
My gut feeling is that doAsPrivileged is correct for the network server 
shutdown only, seems like doAs is needed in the embedded calls if this piece of 
the functional spec is to be true:
  Because we use Java Security to model system privileges, the shutdownEngine 
and create privileges can be granted to code as well as to users.

 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2109) System privileges

[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561090#action_12561090
]

Rick Hillegas commented on DERBY-2109:
--

Those arguments are case sensitive, so it is up to the UserAuthenticator to
determine the rules it wants to enforce.

But is such a class honouring the UserAuthenticator api when it does that? The
description for authenticateUser states that an unquoted user name is treated
as a case-insensitive authorization identifier by Derby's authorization
system. While this is technically incorrect, (see DERBY-3334), the intention
behind the text is to follow SQL identifier rules for converting the parameter
userName to a unique authorization identifier within Derby. This can be seen
by the fact this mapping will be followed:

The javadoc for UserAuthenticator states the rules for mapping the userName
onto the value of SYSSCHEMAS.AUTHORIZATIONID. Indirectly, it warns the customer
that Edward and EdWard will be thrown into the same schema even though the
company-wide authentication service recognizes these two names as different
individuals with different credentials. However, the javadoc should probably
punch up the significance of this behavior.

In the Developer's Guide section titled Example of setting a user-defined
class, the sampe code shows a user-supplied authenticator which treats
userName as a case-sensitive string. In that example, Edward and EdWard have
separate credentials.

At least as far as I can see, the surrounding sections of the Developer's Guide
do not explain that Edward and EdWard will be thrown into the same schema.
Probably, we should state this explicitly.

System privileges
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2109) System privileges

[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561092#action_12561092
]

Daniel John Debrunner commented on DERBY-2109:
--

Right I was seeing authorization identifier as a value that resulted from
applying the rules of section 5.2/5.4 to the identifiers, but strictly speaking
that's not true. Then as Dag points out we are really talking about user
identifier for authentication, though possibly authorization identifier for
authorization.

So I think we can agree that a user has a unique identity, can we call this
UID? This corresponds to what is stored in the system tables.

So a user identifier is a mechanism of representing a UID in a SQL statement
using SQL regular or delimited identifiers. Section 5.2/5.4 provides the rules
for this mapping.

Derby's Java code and property files use the same syntax rules as SQL's user
identifier to represent a UID.

So the concept of UserName and user identifier are actually the same, so we
should drop UserName and use user identifier.
[so that's what I meant by the SQL standard defined the rules from user name to
authorization identifier - which is really user identifier to UID]

authorization identifier is defined by the SQL spec and can represent a user
identifier or a role name.

So if SystemPrincipal represents a user then its input format should be that of
a user identifier. I think if we ever wanted to add role support to the policy
file then a RolePrincipal would be clearer than having roles and users mixed in
the same Principal class.

Rick I think you seem to be saying that a system authentication implementation
could treat regular user identifiers of fred and FRED as different. This then
contradicts the very definition of user identifier, so it would need a new set
of terms to describe this. This seems to go against the existing definitions.

System privileges
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Db-derby Wiki] Update of UserIdentifiers by DanDebrunner


Dag H. Wanvik wrote:

Apache Wiki [EMAIL PROTECTED] writes:


Earlier versions of this document used ''normal user name'' to
represent ''authorization identifier''.


The term authorization identifier is used in the standard to cover
both user identifier and role name, cf. section 5.4:

 authorization identifier ::=
   role name
 | user identifier 


Would is perhaps be better to reserve the more generic term
authorization identifer to those cases when either a user or a role
meant, and rather user user identifier when talking about users
only?


Probably, though Derby's documentation uses 'authorization identifier' 
in a somewhat different way.


http://db.apache.org/derby/docs/dev/devguide/cdevcsecure37241.html

In the wiki page I was using authorization identifier more in line with 
the Derby docs.


Dan.

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561099#action_12561099
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

 The javadoc for UserAuthenticator states the rules for mapping the userName 
 onto the value of SYSSCHEMAS.AUTHORIZATIONID.

Which version (svn revision) are you looking at? I don't see the words  
SYSSCHEMAS or AUTHORIZATIONID in the javadoc at all.

I do see this text in the section on stating how the userName is handled

  ... within the Derby user authorization system

revision 613345

That's doesn't state it's only for database authorization.

 However, the javadoc should probably punch up the significance of this 
 behavior. 
I entered DERBY-3334 to make this clearer.

Note the introduction to MyAuthenticationSchemeImpl says very simple example 
:-)
It agrees with the discussion a few pages later
http://db.apache.org/derby/docs/dev/devguide/cdevcsecure24458.html
that says if the external scheme is case-sensitive (as in 
MyAuthenticationSchemeImpl) then you must always log in with a user name that 
maps to the value defined in the external scheme.
It remains silent on what to do if the external schema has different identities 
that map to the same SQL identity, as you say that could be improved.

Later on in that page it says when talking about delimited identifiers:
  (Derby knows to remove the double quotes when passing the name to the 
external authentication system.)
I don't believe that's true, at least it contradicts UserAuthenticator's 
documentation.


 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3257) SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB


 [ 
https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden updated DERBY-3257:
--

Attachment: derby-3257_diff2.txt

Thanks Army for looking at the patch.
Attached is a revised patch derby-3257_diff2.txt with the changes you 
recommended.  I will commit this afternoon if I don't hear anything back.

You asked
Is there something in the code that makes this limitation explicit, or does 
this statement just follow from the fact that attempts to flatten such a 
subquery lead to other errors?

Flattenning produces a column in the having clause that is not generated to 
replace an aggregate causing this condition to throw the exception:
if (!cr.getGeneratedToReplaceAggregate()  
cr.getSourceLevel() == level) {
throw StandardException.newException(

SQLState.LANG_INVALID_COL_HAVING_CLAUSE, 
cr.getSQLColumnName()); 

}

I tried to understand why this condition was necessary by commenting it out and 
I ended up with a null pointer exception in the generated code when I had a 
select in the having clause.  I didn't pursue it much further than that and 
figured Manish put that condition and error there for good reason.  Perhaps 
there is a way to allow the flattenning of the subquery  but I was not able to 
figure out how to do it so went with this solution.

I'm hoping at some point.  Manish or someone else can take a look at this and 
come up with a more elegant solution allowing the subqueries to be flattenned 
in the having clause.  

 SELECT with HAVING clause containing OR conditional incorrectly return 1 row 
 - should return 2 rows - works correctly with 10.2 DB
 --

 Key: DERBY-3257
 URL: https://issues.apache.org/jira/browse/DERBY-3257
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Reporter: Stan Bradbury
Assignee: Kathey Marsden
 Attachments: 42X24_error.sql, d3257_doNOTCommit.patch, 
 derby-3257_diff.txt, derby-3257_diff2.txt, derby-3257_plan_10.2.txt, 
 derby-3257_plan_10.4.txt, derby-3257_stat.txt, TestHaving.java


 Attached program demonstrates the problem.  Only one count is returned 
 (matching CODE= GBR) - the count of CODE=CHA is not returned.  Works fine 
 with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 
 database (soft upgrade).
 Query:
 SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 
   GROUP BY t0.CODE 
 HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL
 Incorrect results (see last line):
 Database product: Apache Derby
 Database version: 10.3.1.5 - (579866)
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.3.1.5 - (579866)
 result: 2
 Correct results:
 Database product: Apache Derby
 Database version: 10.2.2.0 - (485682)
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.2.2.0 - (485682)
 result: 4
 result: 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3335) Allow UserAuthenticator.authenticateUser to work with authorization identifiers and not user name.

[
https://issues.apache.org/jira/browse/DERBY-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561103#action_12561103
]

Daniel John Debrunner commented on DERBY-3335:
--

An alternate way of addressing this would be to not add a new method or change
the meaning of the existing parameters.

Instead Derby could add a property to info Properties set passed into
authenticateUser.
This property would be the unique user identity (which is currently described
as authorization identifier) but the discussion in DERBY-2109 might come up
with a better name since authorization identifier has a specific meaning in SQL
and a different meaning in the derby docs).

E.g. the property could be sql.user and thus

userName=Fred = sql.user=FRED
userName=Fred = sql.user=FRED
userName=Fred = sql.user=Fred

Minor backwards compat risk that a user authentication scheme was using
sql.user to pass some information to its specific scheme.

Allow UserAuthenticator.authenticateUser to work with authorization
identifiers and not user name.
--

Key: DERBY-3335
URL: https://issues.apache.org/jira/browse/DERBY-3335
Project: Derby
Issue Type: Improvement
Components: Security
Reporter: Daniel John Debrunner
Priority: Minor

Add a new method to UserAuthenticator that allows the authentication scheme
to request that the user name passed into authenticateUser is an
authentication identifier. This would absolve authentication schemes from
each implementing the mapping from user name to authorization identifier.
Implementing the logic in each scheme is pointless and subject to errors if a
different set of rules is implemented by the scheme (say by a coding bug).
Signature could be
/**
Return true if the identifier argument to authenticateUser is to represent
an authorization identifier,
false if it is to represent the user name.
Note the identifier argument passed into authenticateUser is provided by
the database engine.
@since 10.x If this method does exist then a return of false is assumed.
*/
public boolean authenticateUsingAuthorizationId();
The first argument to authenticateUser would change for userName to
identifier with appropriate comment changes.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2109) System privileges


[ 
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561104#action_12561104
 ] 

Daniel John Debrunner commented on DERBY-2109:
--

Just to add to the confusion, the derby documentation uses authorization 
identifier in most cases to mean UID. I think that is what was driving my line 
of thinking to use authorization identifier when I really meant the UID.

http://db.apache.org/derby/docs/dev/devguide/cdevcsecure37241.html



 System privileges
 -

 Key: DERBY-2109
 URL: https://issues.apache.org/jira/browse/DERBY-2109
 Project: Derby
  Issue Type: New Feature
  Components: Security
Affects Versions: 10.3.1.4
Reporter: Rick Hillegas
Assignee: Martin Zaun
 Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, 
 derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat, 
 DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff, 
 DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, 
 DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat, 
 SystemPrivilegesBehaviour.html, systemPrivs.html, systemPrivs.html, 
 systemPrivs.html, systemPrivs.html


 Add mechanisms for controlling system-level privileges in Derby. See the 
 related email discussion at 
 http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
 The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  
 secure in a client/server configuration. I'd like to plug more client/server 
 security holes in 10.3. In particular, I'd like to focus on  authorization 
 issues which the ANSI spec doesn't address.
 Here are the important issues which came out of the email discussion.
 Missing privileges that are above the level of a single database:
 - Create Database
 - Shutdown all databases
 - Shutdown System
 Missing privileges specific to a particular database:
 - Shutdown that Database
 - Encrypt that database
 - Upgrade database
 - Create (in that Database) Java Plugins (currently  Functions/Procedures, 
 but someday Aggregates and VTIs)
 Note that 10.2 gave us GRANT/REVOKE control over the following  
 database-specific issues, via granting execute privilege to system  
 procedures:
 Jar Handling
 Backup Routines
 Admin Routines
 Import/Export
 Property Handling
 Check Table
 In addition, since 10.0, the privilege of connecting to a database has been 
 controlled by two properties (derby.database.fullAccessUsers and 
 derby.database.defaultConnectionMode) as described in the security section of 
 the Developer's Guide (see 
 http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3257) SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB


[ 
https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561113#action_12561113
 ] 

Dyre Tjeldvoll commented on DERBY-3257:
---

Fwiw: I applied the first version of your patch and verified that the repro 
worked correctly. I also ran all the test with the patch. I saw no failures. +1 
to commit. And thanks for addressing this - one less regression to worry about 
:)


 SELECT with HAVING clause containing OR conditional incorrectly return 1 row 
 - should return 2 rows - works correctly with 10.2 DB
 --

 Key: DERBY-3257
 URL: https://issues.apache.org/jira/browse/DERBY-3257
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Reporter: Stan Bradbury
Assignee: Kathey Marsden
 Attachments: 42X24_error.sql, d3257_doNOTCommit.patch, 
 derby-3257_diff.txt, derby-3257_diff2.txt, derby-3257_plan_10.2.txt, 
 derby-3257_plan_10.4.txt, derby-3257_stat.txt, TestHaving.java


 Attached program demonstrates the problem.  Only one count is returned 
 (matching CODE= GBR) - the count of CODE=CHA is not returned.  Works fine 
 with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 
 database (soft upgrade).
 Query:
 SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 
   GROUP BY t0.CODE 
 HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL
 Incorrect results (see last line):
 Database product: Apache Derby
 Database version: 10.3.1.5 - (579866)
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.3.1.5 - (579866)
 result: 2
 Correct results:
 Database product: Apache Derby
 Database version: 10.2.2.0 - (485682)
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.2.2.0 - (485682)
 result: 4
 result: 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-3257) SELECT with HAVING clause containing OR conditional incorrectly return 1 row - should return 2 rows - works correctly with 10.2 DB


[ 
https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561113#action_12561113
 ] 

dyret edited comment on DERBY-3257 at 1/21/08 12:14 PM:
-

Fwiw: I applied the first version of your patch and verified that the repro 
worked correctly. I also ran all the tests with the patch. I saw no failures. 
+1 to commit. And thanks for addressing this - one less regression to worry 
about :)


  was (Author: dyret):
Fwiw: I applied the first version of your patch and verified that the repro 
worked correctly. I also ran all the test with the patch. I saw no failures. +1 
to commit. And thanks for addressing this - one less regression to worry about 
:)

  
 SELECT with HAVING clause containing OR conditional incorrectly return 1 row 
 - should return 2 rows - works correctly with 10.2 DB
 --

 Key: DERBY-3257
 URL: https://issues.apache.org/jira/browse/DERBY-3257
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
Reporter: Stan Bradbury
Assignee: Kathey Marsden
 Attachments: 42X24_error.sql, d3257_doNOTCommit.patch, 
 derby-3257_diff.txt, derby-3257_diff2.txt, derby-3257_plan_10.2.txt, 
 derby-3257_plan_10.4.txt, derby-3257_stat.txt, TestHaving.java


 Attached program demonstrates the problem.  Only one count is returned 
 (matching CODE= GBR) - the count of CODE=CHA is not returned.  Works fine 
 with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 
 database (soft upgrade).
 Query:
 SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 
   GROUP BY t0.CODE 
 HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL
 Incorrect results (see last line):
 Database product: Apache Derby
 Database version: 10.3.1.5 - (579866)
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.3.1.5 - (579866)
 result: 2
 Correct results:
 Database product: Apache Derby
 Database version: 10.2.2.0 - (485682)
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.2.2.0 - (485682)
 result: 4
 result: 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2109) System privileges

[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561118#action_12561118
]

Rick Hillegas commented on DERBY-2109:
--

So I think we can agree that a user has a unique identity, can we call this
UID? This corresponds to what is stored in the system tables.

I'm afraid that when I read these words, they sound like this to me: A person
has a unigue identity, a UID, which is stored in the system tables. I don't
agree with this. Two persons (Edward and EdWard in my example) end up with the
same identity. The identity is not unique. That's a problem.

As a practical matter, I don't think that we can please everyone:

1) A customer whose authentication service enforces the case sensitivity of
usernames is probably going to want to grant privileges to case-sensitive
names. This customer is not going to be happy if the payroll clerk EdWard gets
the shutdown privilege intended for the system administrator Edward.

2) On the other hand, a customer whose authentication service treats Edward and
EdWard as the same username is not going to want to have to grant shutdown
privilege to every casing combination.

Maybe we could add a userNamesAreCaseSensitive() method to UserAuthenticator or
create a CaseSensitiveUserAuthenticator interface to extend UserAuthenticator?
Given a case-sensitive UserAuthenticator, we would not have to throw Edward and
EdWard into the same schema. The default behavior would be the current
behavior. And the default behavior for SystemPrincipal would be, as Dan
suggests, that usernames are case-insensitive.

This distinction could be added later on. I don't see that we have to support
case-sensitive usernames in 10.4.

System privileges
-

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (DERBY-2109) System privileges

Rick Hillegas (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561118#action_12561118 ]

Rick Hillegas commented on DERBY-2109:
--

So I think we can agree that a user has a unique identity, can we call this UID? This corresponds to what is stored in the system tables.

I'm afraid that when I read these words, they sound like this to me: A person has a
unigue identity, a UID, which is stored in the system tables. I don't agree with
this.
Two persons (Edward and EdWard in my example) end up with the same
identity. The identity is not unique. That's a problem.

Does it help if I say a *database* user has a unique database identity,
call it DBUID), because that's a fact of how Derby works and how the
SQL Standard require it works. We can only be concerned about the
identity and its uniqueness meaning in Derby's realm, database or
system. How a real person maps onto a Derby database or system users is
not relevant here. E.g. Edward and EdWard defining two unique people is
obviously unique only in some specified domain, e.g. a unix system
logins in a corporate setup. Such a setup has to understand how
identities need to be mapped across systems with different rules, e.g.
mapping those unix login names to e-mail addresses would also fail with
a simple use of [EMAIL PROTECTED], since e-mail addresses are
case-insensitive while logins are not.

Currently system users do follow the same rules as database users, thus
there is an equivalent system user unique identifier, call it SYSUID.

In *Java code* I can provide the identifier values you list as follows:

String u1 = Edward;
String u2 = EdWard;

String u3 = \Edward\;
String u4 = \EdWard\;

Derby's documented rules state that u1 and u2 are equivalent, thus they
are the same identifier and the CNF of it is EDWARD (SYSUID=EDWARD).

u3 and u4 are two different identifiers (and also different to u1,u2),
thus they allow your two edwards to be distinguished, at the cost of
having to delimit the name with quotes.

If an authentication implementation is ignoring the rules defined for
how Derby handles user names then I'm not sure what can be done. An
application can interface correctly into any authentication scheme by
providing its UserAuthenticator and following the rules Derby indicates.

As I said, I think looking back it was the wrong choice to have pushed
the SQL identifier model into the Java space, but that's how it works
today in Derby's Java code, property files, property key-value pairs.

We could say that within a Java policy file then we follow a simple Java
model, meaning that the user name provided corresponds to the SYSUID.
That might make life clearer in some cases, but now consistency across
apis goes away which may confuse the situation.

I don't see that we have to support case-sensitive usernames in 10.4.

Could you state what you are proposing for 10.4 for system users that
are represented by SystemPrincipals in the policy file? I'm still
somewhat lost as you seem to be saying the system authentication has a
different model to database authentication.

Thanks,
Dan.

Re: [jira] Commented: (DERBY-2109) System privileges


Rick Hillegas (JIRA) wrote:


2) On the other hand, a customer whose authentication service treats Edward and 
EdWard as the same username is not going to want to have to grant shutdown 
privilege to every casing combination.


No scheme would require that. Remember authentication and authorization 
are different. Authorization is entirely within Derby's realm, 
unaffected by the authentication that proceeded it. For this case the 
text within the policy file will be either:


   // Format of Principal's name corresponds to SYSUID
   SystemPrincipal EDWARD;


or any *one* of the following

  // Format of Principal's name corresponds to user identifier
  // and thus matches Derby's existing way to specify a user
  // in other Java constructs.
  SystemPrincipal edward
  SystemPrincipal EdWard
  SystemPrincipal EDWArD  // etc. etc.


This is of course assuming that system user handling continues with its 
current rules that follow database user handling.


Dan.

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-21 Thread Thomas Nielsen (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561138#action_12561138
 ] 

Thomas Nielsen commented on DERBY-3301:
---

Thanks a lot for all the pointers folks. I think both Army and Bryan nailed it 
on where/why this query fails on the trunk.

To check the hypothesis, I tried marking any subquery in the wherePredicates as 
such and skip flattening if this is a subquery in a whereClause. 
The happens to be exactly what Kathy did in DERBY-3257 for havingSubqueries. 
With the mark-and-skip fix the correct 7 rows are returned as the flattening is 
skipped.

My approach is possibly too brute, and might be relaxed, but I'll post a proper 
patch tomorrow morning.

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE |DISCRIMINATOR

[jira] Issue Comment Edited: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-21 Thread Thomas Nielsen (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561138#action_12561138
 ] 

thomanie edited comment on DERBY-3301 at 1/21/08 1:55 PM:


Thanks a lot for all the pointers folks. I think both Army and Bryan nailed it 
on where/why this query fails on the trunk.

To check the hypothesis, I tried marking any subquery in the wherePredicates as 
such and skip flattening if this is a subquery in a whereClause. 
The happens to be exactly what Kathey did in DERBY-3257 for havingSubqueries. 
With the mark-and-skip fix the correct 7 rows are returned as the flattening is 
skipped.

My approach is possibly too brute, and might be relaxed, but I'll post a proper 
patch tomorrow morning.

  was (Author: thomanie):
Thanks a lot for all the pointers folks. I think both Army and Bryan nailed 
it on where/why this query fails on the trunk.

To check the hypothesis, I tried marking any subquery in the wherePredicates as 
such and skip flattening if this is a subquery in a whereClause. 
The happens to be exactly what Kathy did in DERBY-3257 for havingSubqueries. 
With the mark-and-skip fix the correct 7 rows are returned as the flattening is 
skipped.

My approach is possibly too brute, and might be relaxed, but I'll post a proper 
patch tomorrow morning.
  
 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema

[jira] Commented: (DERBY-3301) Incorrect result from query with nested EXIST

2008-01-21 Thread Craig Russell (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561141#action_12561141
 ] 

Craig Russell commented on DERBY-3301:
--

Great! I'm looking forward to trying the patch.

 Incorrect result from query with nested EXIST
 -

 Key: DERBY-3301
 URL: https://issues.apache.org/jira/browse/DERBY-3301
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.2.1
Reporter: Craig Russell
 Attachments: d3301-queryplan.log, derby-3301.sql


 Derby returns unexpected results from a query with embedded EXIST clauses. 
 The query SQL is generated by the JPOX jdo implementation and is supposed to 
 return all of the PERSONS and PROJECTS where there is an entry in the join 
 table. This query works as expected when using MySQL.
 Here's the query:
 SELECT UNBOUND_E.PERSONID, UNBOUND_P.PROJID 
 FROM applicationidentity0.DEPARTMENTS THIS, 
  applicationidentity0.PERSONS UNBOUND_E, 
  applicationidentity0.PROJECTS UNBOUND_P 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PERSONS THIS_EMPLOYEES_E 
 WHERE EXISTS ( 
 SELECT 1 FROM applicationidentity0.PROJECT_MEMBER 
 THIS_EMPLOYEES_E_PROJECTS_P 
 WHERE THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = 
 THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E_PROJECTS_P.MEMBER = THIS_EMPLOYEES_E.PERSONID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND THIS_EMPLOYEES_E.DEPARTMENT = THIS.ID 
 AND UNBOUND_P.PROJID = THIS_EMPLOYEES_E_PROJECTS_P.PROJID 
 AND UNBOUND_E.PERSONID = THIS_EMPLOYEES_E.PERSONID) 
 );
 PERSONID   |PROJID 
 ---
 3  |1  
 5  |3  
 4  |3  
 2  |1  
 1  |1  
 5 rows selected
 I'm expecting 7 rows to be returned here, one row for each row in the join 
 table. 
 Here's the schema:
 CREATE TABLE departments (
 ID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 EMP_OF_THE_MONTH INTEGER,
 COMPANYID INTEGER,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT DEPTS_COMP_FK FOREIGN KEY (COMPANYID) REFERENCES companies,
 CONSTRAINT DEPTS_PK PRIMARY KEY (ID)
 );
 CREATE TABLE persons (
 PERSONID INTEGER NOT NULL,
 FIRSTNAME VARCHAR(32) NOT NULL,
 LASTNAME VARCHAR(32) NOT NULL,
 MIDDLENAME VARCHAR(32),
 BIRTHDATE TIMESTAMP NOT NULL,
 ADDRID INTEGER,
 STREET VARCHAR(64),
 CITY VARCHAR(64),
 STATE CHAR(2),
 ZIPCODE CHAR(5),
 COUNTRY VARCHAR(64),
 HIREDATE TIMESTAMP,
 WEEKLYHOURS REAL,
 DEPARTMENT INTEGER,
 FUNDINGDEPT INTEGER,
 MANAGER INTEGER,
 MENTOR INTEGER,
 HRADVISOR INTEGER,
 SALARY REAL,
 WAGE REAL,
 DISCRIMINATOR varchar(255) NOT NULL,
 CONSTRAINT PERS_DEPT_FK FOREIGN KEY (DEPARTMENT) REFERENCES departments,
 CONSTRAINT PERS_FUNDDEPT_FK FOREIGN KEY (FUNDINGDEPT) REFERENCES 
 departments,
 CONSTRAINT PERS_MANAGER_FK FOREIGN KEY (MANAGER) REFERENCES persons,
 CONSTRAINT PERS_MENTOR_FK FOREIGN KEY (MENTOR) REFERENCES persons,
 CONSTRAINT PERS_HRADVISOR_FK FOREIGN KEY (HRADVISOR) REFERENCES persons,
 CONSTRAINT EMPS_PK PRIMARY KEY (PERSONID)
 );
 CREATE TABLE projects (
 PROJID INTEGER NOT NULL,
 NAME VARCHAR(32) NOT NULL,
 BUDGET DECIMAL(11,2) NOT NULL,
 DISCRIMINATOR VARCHAR(255),
 CONSTRAINT PROJS_PK PRIMARY KEY (PROJID)
 );
 CREATE TABLE project_member (
 PROJID INTEGER REFERENCES projects NOT NULL,
 MEMBER INTEGER REFERENCES persons NOT NULL
 );
 ij connect 
 'jdbc:derby:/Users/clr/apache/jdo/trunk/tck2/target/database/derby/jdotckdb';
 ij set schema applicationidentity0;
 0 rows inserted/updated/deleted
 ij select * from persons;
 PERSONID   |FIRSTNAME   |LASTNAME
 |MIDDLENAME  |BIRTHDATE |ADDRID 
 |STREET  |CITY
 |STA|ZIPC|COUNTRY   
   |HIREDATE  
 |WEEKLYHOURS  |DEPARTMENT |FUNDINGDEPT|MANAGER|MENTOR |HRADVISOR  
 |SALARY   |WAGE |DISCRIMINATOR

[jira] Commented: (DERBY-3192) Cache session data in the client driver

[
https://issues.apache.org/jira/browse/DERBY-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561144#action_12561144
]

Dyre Tjeldvoll commented on DERBY-3192:
---

Thank you! This is indeed interesting.

This really opens up the possibilities. But an asynchronous approach as you
suggest (no polling, which is great) would require some handshake logic to
figure out if both the client and the server supports this. I'm guessing that
perhaps EXCSAT could be used for this somehow, but I don't quite understand how
it works yet...

Cache session data in the client driver
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3323) ComparisonFailure in derbyStress

2008-01-21 Thread Mike Matrigali (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Matrigali updated DERBY-3323:
--


depending on isolation level and the state of the open results set it would 
totally be expected that this would stop 
a drop from happening.  It gets confusing with the various row caches around, 
but from the bottom up what is expected for read committed:

while a result set is open store will hold a IS table intent lock until the 
result set is closed.  This lock will conflict
with drop table and thus will cause the drop table to block until the result 
set is closed.  It will usually hold one
read committed row lock with is the current row in the scan.  From store 
point of view the result set can get closed 
in one of 2 ways, either by explicitly closing it or by nexting past the last 
row in the result set.  Correlating the second condition is hard from the 
client side as multiple level of caching (drda and internal group fetch) make 
it to tell
the relationship between the current row in the application and the actual 
last row that has been fetched from store.

 ComparisonFailure in derbyStress
 

 Key: DERBY-3323
 URL: https://issues.apache.org/jira/browse/DERBY-3323
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: jvm1.4 lin
 jvm1.5 lin, linN+1
 vm1.6 sles,sol, solN+1
 jvm1.5 w2003
Reporter: Ole Solberg
Assignee: Kathey Marsden
Priority: Minor

 See 
 jvm1.4 lin : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html
 jvm1.5 lin, jvm1.5 linN+1 : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html
 jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html
 jvm1.5 w2003: 
 http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html
 1) 
 derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure:
  Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- 
 unexpected exception ]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
   at 
 org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DERBY-3338) CancelQueryTask.forgetContext() could be simplified.

CancelQueryTask.forgetContext() could be simplified.


 Key: DERBY-3338
 URL: https://issues.apache.org/jira/browse/DERBY-3338
 Project: Derby
  Issue Type: Improvement
  Components: Newcomer, Services, SQL
Reporter: Daniel John Debrunner
Priority: Minor


Minor issue but CancelQueryTask.forgetContext() has this code (in 
GenericStatementContext.java)

public void forgetContext() {
boolean mayStillRun = !cancel();
if (mayStillRun) {
synchronized (this) {
statementContext = null;
}
}
}

The mayStillRun = !cancel() is somewhat confusing. I can't see from the javadoc 
of TimerTask.cancel() how its return value could indicate the task may still 
run.
Less confusing code could be:

public void forgetContext() {
   synchronized (this) {
statementContext = null;
}
cancel();
}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3323) ComparisonFailure in derbyStress


[ 
https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561154#action_12561154
 ] 

Daniel John Debrunner commented on DERBY-3323:
--

Is the System.gc() required? If so we probably need to document this as part of 
DROP TABLE.

However I think that would be a really bad idea, I thought that Derby itself 
went through and tried to perform gc() if there were open result sets during 
such an operation.

 ComparisonFailure in derbyStress
 

 Key: DERBY-3323
 URL: https://issues.apache.org/jira/browse/DERBY-3323
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: jvm1.4 lin
 jvm1.5 lin, linN+1
 vm1.6 sles,sol, solN+1
 jvm1.5 w2003
Reporter: Ole Solberg
Assignee: Kathey Marsden
Priority: Minor

 See 
 jvm1.4 lin : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html
 jvm1.5 lin, jvm1.5 linN+1 : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html
 jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html
 jvm1.5 w2003: 
 http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html
 1) 
 derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure:
  Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- 
 unexpected exception ]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
   at 
 org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3323) ComparisonFailure in derbyStress

2008-01-21 Thread Mike Matrigali (JIRA)


 [ 
https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Matrigali updated DERBY-3323:
--


looking more carefully at the error message I don't think the locking is was is 
causing the drop error (what I described would likely be the case if the drop 
and the result sets were in different connections), but instead 
probably the dependency manager.  My assumption would be that disallowing this 
ddl is necessary otherwise 
one would get strange behavior in the resultset which depends on a stable ddl 
for the tables in the result set while
the result set is open.

 ComparisonFailure in derbyStress
 

 Key: DERBY-3323
 URL: https://issues.apache.org/jira/browse/DERBY-3323
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: jvm1.4 lin
 jvm1.5 lin, linN+1
 vm1.6 sles,sol, solN+1
 jvm1.5 w2003
Reporter: Ole Solberg
Assignee: Kathey Marsden
Priority: Minor

 See 
 jvm1.4 lin : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html
 jvm1.5 lin, jvm1.5 linN+1 : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html
 jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html
 jvm1.5 w2003: 
 http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html
 1) 
 derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure:
  Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- 
 unexpected exception ]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
   at 
 org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3023) Different result rows depending on the sequence of INNER JOIN and OUTER JOIN


 [ 
https://issues.apache.org/jira/browse/DERBY-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

A B updated DERBY-3023:
---

Fix Version/s: 10.3.2.2

Tinderbox runs on trunk ran for several days with no apparent fallout from the 
changes for this issue, so I ported back to 10.3 with a simple merge command:

  svn merge -r 612503:612504 
https://svn.apache.org/repos/asf/db/derby/code/trunk

I ran derbyall and suites.All with ibm142 and there were no new failures.  So I 
committed with svn # 614046:

  URL: http://svn.apache.org/viewvc?rev=614046view=rev

Updating fix-in to reflect the fact that this is now in 10.3.

 Different result rows depending on the sequence of INNER JOIN and OUTER JOIN
 

 Key: DERBY-3023
 URL: https://issues.apache.org/jira/browse/DERBY-3023
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4
 Environment: Windows XP, Java 1.4.2
Reporter: Stefan Cordes
Assignee: A B
 Fix For: 10.3.2.2, 10.4.0.0

 Attachments: d3023_notTested_v1.patch, d3023_repro.sql, 
 d3023_v2.patch, derby-02-search-joins.zip, derby-02-search-joins2.zip, 
 DerbySearchJoins.java, RUNTIMESTATISTICS-10.3.zip, Statement10.3.1.4 - 
 (561794)-j1.4.2_10.zip


 We have a complex SQL joining 11 Tables via INNER JOIN and OUTER JOIN.
 These SQLs were tested against an z/OS DB2 Version 8.
 After moving to our local platform with Derby we found out the resultsets 
 returned by the SQLs were too less.
 I tested our old style SQL which results in 889 rows.
 Our new style SQL expected to give similar rows but gives *0*.
 After some work we found a workaround: first place all the INNER JOINs in 
 the SQL and then the OUTER JOINs.
 {code:title=Result of testprogram}
 Derby=10.3-b561794
 Test 10.3-b561794-old-style-sql
 889 Rows in 1703ms
 Test 10.3-b561794-new-style-sql
 0 Rows in 563ms  _(expected 924 rows instead)_
 Test 10.3-b561794-new-style-sql-only-inner
 2 Rows in 766ms _(only inner joins, no outer joins but larger result)_
 Test 10.3-b561794-new-style-sql_first-inner-joins
 924 Rows in 578ms
 Test 10.3-b561794-new-style-sql_without-condition
 924 Rows in 438ms
 {code}
 Here our initial used SQL:
 {code:title=SQL giving wrong result (0 rows)}
 SELECT O4Work.ESVN01.NU_BUY_CPY AS PO_BuyCompanyNo, O4Work.ESVN01.NU_ODR AS 
 PO_Number, O4Work.ESVN01.FL_ODR_CAE AS PO_Type, O4Work.ESVN01.NU_MCS_SPY AS 
 PO_SupplierNo, O4Work.ESVN01.NU_ST3 AS PO_StatusNo, 
 O4Work.ESVN01.DA_SPY_COY_PRT AS PO_SCPrintDate, O4Work.ESVN01.FL_SAS AS 
 PO_SeasFlag, CASE WHEN (SELECT COUNT(O4Work.ESVNA5.ID_PTE) FROM O4Work.ESVNA5 
 WHERE O4Work.ESVN02.NU_BUY_CPY = O4Work.ESVNA5.NU_BUY_CPY AND 
 O4Work.ESVN02.NU_ODR = O4Work.ESVNA5.NU_ODR AND O4Work.ESVN02.NU_PST = 
 O4Work.ESVNA5.NU_PST) = 0 THEN 'N' ELSE 'Y' END AS POPA_PictureID, CASE WHEN 
 (SELECT COUNT(O4Work.ESVNG3.NU_ODR) FROM O4Work.ESVNG3 WHERE 
 O4Work.ESVN01.NU_BUY_CPY = O4Work.ESVNG3.NU_BUY_CPY AND O4Work.ESVN01.NU_ODR 
 = O4Work.ESVNG3.NU_ODR) = 0 THEN 'N' ELSE 'Y' END AS ON_ID, 
 O4Work.ESVN02.NU_PST AS POP_Position_Id, O4Work.ESVN02.NU_CTT AS 
 POP_ContractNo, O4Work.ESVN02.NU_ARO_CTT AS POP_ArosContractNo, 
 O4Work.ESVN02.NU_ST3 AS POP_StatusNo, O4Work.ESVN02.DA_CAE AS 
 POP_CreationDate, O4Work.ESVN02.DA_LAT_AMD AS POP_LastAmendDate, 
 O4Work.ESVNA0.NU_SSN_IDE AS POPD_SeasonInd,  O4Work.ESVNA0.NU_STL_ID1 AS 
 POPD_StyleId, O4Work.ESVNA0.NU_SRY_ID1 AS POPD_StoryID, O4Work.ESVNA0.NU_LC1 
 AS POPD_LicenseID, O4Work.ESVP00.NU_CSY AS SER_ClassNo, O4Work.ESVP00.NU_COE 
 AS SER_CodeNo, O4Work.ESVP00.NU_SRL AS SER_SerialNo, O4Work.ESVP00.NU_PIK_MOD 
 AS SER_PickingM, O4Work.ESVN03.NU_MT1_CPY AS POPC_MasterCpyNo, 
 O4Work.ESVN03.QU_ODR AS POPC_OrderedQty, O4Work.ESVN03.DA_EDD AS POPC_Edd, 
 O4Work.ESVN03.DA_LDD AS POPC_Ldd, O4Work.ESVN03.DA_PAD AS POPC_Pad, 
 O4Work.ESVN03.DA_SAD AS POPC_Sad, O4Work.ESVN03.PR_SCP AS POPC_SupCstPrice, 
 O4Work.ESVN03.NU_SCP_CR1 AS POPC_SupCstPrCurr, O4Work.ESVN03.NU_ST3 AS 
 POPC_StatusNo, O4Work.ESVN03.NU_COY_FRM_ODR AS POPC_Src_PO_Number, 
 O4Work.ESVN03.NU_COY_UTL_ODR AS POPC_Tgt_PO_Number, O4Work.ESVN03.DA_FLR_RDY 
 AS POPC_FRM_DATE, O4Work.ESVN03.FL_CSG AS POPC_CS_FLAG, 
 O4Work.ESVN03.NU_PAK_MOD_SPY AS POPC_PackSupplNo, 
 O4Work.ESVN03.NU_PAK_MOD_DCR AS POPC_PackingDCNo, O4Work.ESVN03.NU_PS2_MOD AS 
 POPC_PresMethodNo, O4Work.ESVN04.NU_RTL_CPY AS POPRC_RetailCode, 
 O4Work.ESVN04.PR_PLN_SEL AS POPRC_SellPrice, O4Work.ESVN04.NU_PLN_SEL_PRC_CR1 
 AS POPRC_SellPrCurr, O4Work.ESVN08.NU_AVE AS POPRCA_AdvertNo, 
 O4Work.ESVQ00.ID_SHP AS SHP_ShippingID, O4Work.ESVQ00.NU_SHP AS 
 SHP_ShippingNo, O4Work.ESVNB0.NU_NTL_PDE_ID1 AS POPDC_NationalID, 
 O4Work.ESVNB0.NU_EQP AS POPDC_EquipNumber, O4Work.ESVNE1.PE_OMU AS POPCC_OMU, 
 CASE WHEN (SELECT COUNT(O4Work.ESVN07.NU_ODR) FROM

[jira] Created: (DERBY-3339) APP schema is always owned by APP regardless of the database owner

APP schema is always owned by APP regardless of the database owner
--

 Key: DERBY-3339
 URL: https://issues.apache.org/jira/browse/DERBY-3339
 Project: Derby
  Issue Type: Bug
  Components: SQL
Reporter: Daniel John Debrunner
Priority: Minor


Every schema in a newly created database should be owned by the database owner 
since APP may not be a valid user.

ij connect 'jdbc:derby:cs;create=true;user=[EMAIL PROTECTED]';

ij select CAST(schemaname AS VARCHAR(15)) AS SCHEMANAME,
CAST (authorizationid AS VARCHAR(15)) AS AUTHORIZATIONID from sys.sysschemas;
SCHEMANAME |AUTHORIZATIONID
---
SYSIBM |[EMAIL PROTECTED]
SYS|[EMAIL PROTECTED]
SYSCAT |[EMAIL PROTECTED]
SYSFUN |[EMAIL PROTECTED]
SYSPROC|[EMAIL PROTECTED]
SYSSTAT|[EMAIL PROTECTED]
NULLID |[EMAIL PROTECTED]
SQLJ   |[EMAIL PROTECTED]
SYSCS_DIAG |[EMAIL PROTECTED]
SYSCS_UTIL |[EMAIL PROTECTED]
APP|APP


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3215) Potential NullPointerException in CachedPage class


[ 
https://issues.apache.org/jira/browse/DERBY-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561177#action_12561177
 ] 

Dag H. Wanvik commented on DERBY-3215:
--

Merged both patches to 10.3 branch as svn 614068 after running 
regression tests without errors.

 Potential NullPointerException in CachedPage class
 --

 Key: DERBY-3215
 URL: https://issues.apache.org/jira/browse/DERBY-3215
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.1.4
 Environment: Windows XP
Reporter: Jason Valentine
Assignee: Dag H. Wanvik
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: DERBY-3215.diff, DERBY-3215b.diff


 There's a potential for a NullPointerException to be thrown in the in the 
 org.apache.derby.impl.store.raw.data.CachedPage class.  In the writePage() 
 method, there's a test of the myContainer reference to ensure it's not null 
 (line 771), however in the else block, myContainer is dereferenced (line 
 836), where a NullPointerException is guaranteed to be thrown.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3215) Potential NullPointerException in CachedPage class


 [ 
https://issues.apache.org/jira/browse/DERBY-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik closed DERBY-3215.



Issue fixed on both trunk and 10.3 branch, so closing. Jason, please feel free 
to reopen
if you don't agree the issue should be closed.

 Potential NullPointerException in CachedPage class
 --

 Key: DERBY-3215
 URL: https://issues.apache.org/jira/browse/DERBY-3215
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.3.1.4
 Environment: Windows XP
Reporter: Jason Valentine
Assignee: Dag H. Wanvik
Priority: Minor
 Fix For: 10.4.0.0

 Attachments: DERBY-3215.diff, DERBY-3215b.diff


 There's a potential for a NullPointerException to be thrown in the in the 
 org.apache.derby.impl.store.raw.data.CachedPage class.  In the writePage() 
 method, there's a test of the myContainer reference to ensure it's not null 
 (line 771), however in the else block, myContainer is dereferenced (line 
 836), where a NullPointerException is guaranteed to be thrown.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3311) Client ResultSet.getHoldabilty will return incorrect value when the ResultSet is obtained from a procedure call

2008-01-21 Thread Myrna van Lunteren (JIRA)


[ 
https://issues.apache.org/jira/browse/DERBY-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561180#action_12561180
 ] 

Myrna van Lunteren commented on DERBY-3311:
---

Can this now be closed? 

 Client ResultSet.getHoldabilty will return incorrect value when the ResultSet 
 is obtained from a procedure call
 ---

 Key: DERBY-3311
 URL: https://issues.apache.org/jira/browse/DERBY-3311
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Daniel John Debrunner
Assignee: Daniel John Debrunner
Priority: Minor
 Attachments: derby_3311_diff.txt


 Fixing DERBY-3305 (aka DERBY-) exposes that the holdability for a result 
 set sent over DRDA is being obtained from the Statement that created the JDBC 
 ResultSet, not its actual holdability. The two can be different when the 
 result set is dynamic result set from a procedure.
 jdbc4.ResultSetTest.getHoldability fails in client mode.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561181#action_12561181
]

Daniel John Debrunner commented on DERBY-3327:
--

One high level comment and some specific comments on the patch:

high-level
--

It seems somewhat strange that this is implemented as a stack of activations
and because of that we end up needing to store role information in two
different places, in the LCC if it's the top-level and the activation
otherwise. Since the activation represents an individual statement is its job
to hold SQL context information?

Looking closer at the SQL standard (4.34.1.1 and 4.27.3) I'm not sure the patch
is implementing exactly what is described there.
One portion is the SQL-session context, that comes into being with the routine
invocation. Then within the SQL-session context is an authorization stack.
The patch seems to be morphing the two into one, executing a routine creates
just a role stack.

DERBY-1331 is an outstanding issue to handle SET SCHEMA within routines
correctly, which I think falls into the SQL-session context logic, creating a
morphed stack here might make it harder to fix that.

Would it make more sense to have objects that followed the model described by
the SQL specification, even if currently they are not fully utilized?

Something like:
SQLSessionContext - pushed for a routine call, stack maintained in the lcc
has a field for schema (future for DERBY-1331)
has a field for authorization stack (stack of AuthorizationCell)

AuthorizationCell (see 4.34.1.1)
field for user identifier
field for role name

Maybe the existing StatementContext class is already fulfilling the purpose of
SQLSessionContext?

specific patch comments
--

For the field 'callers' in GenericLanguageConnectionContext.java I think it's
holding a stack of Activations. Could you state this in its javadoc.
(oh for Java 5 :-)

In the javadoc comment for 'callers' it says:

For the top level, the current role is kept here, cf. 'currentRole'.

Since this is the javadoc for callers, the here applies to callers, but I think
you really mean the current class. Would this be correct?

For the top level, the current role is kept in this.currentRole.

In BaseActivation can the comments for the field callActivation be javadoc
comments, so that IDE's will pick them up.
Can comments be added for nestedCurrentRole.

Even with the comments for BaseActivation.callActivation I became a little
confused. Looking elsewhere I can see that callActivation is the activation of
the enclosing CALL statement, that would have been useful in the javadoc. I'm
somewhat confused by the need for BaseActivation.callActivation and the stack
in the LCC. It seems that the stack of activations is being kept twice, once in
LCC and once through the activations.

I wonder about the cost of this stack maintenance, for SQL routines that are
defined as NO SQL it might be a significant overhead. E.g. SIN() function.
Avoiding the context manipulation for those routines could be a follow on, but
I'd be interested in the overhead with this change.

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DERBY-3327) SQL roles: Implement authorization stack


 [ 
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik resolved DERBY-3327.
--

Resolution: Fixed
Derby Info:   (was: [Patch Available])

Re-ran regression tests then committed DERBY-3327-3 as svn 614071, resolving.

 SQL roles: Implement authorization stack
 

 Key: DERBY-3327
 URL: https://issues.apache.org/jira/browse/DERBY-3327
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
 Fix For: 10.4.0.0

 Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff, 
 DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat


 The current LanguageConnectionContext keeps the user authorization identifier 
 for an SQL session.
 The lcc is shared context also for nested connections (opened from stored 
 procedures).
 So far, for roles, the current role has been stored in the lcc also. However, 
 SQL requires that
 authorization identifers be pushed on a authorization stack when calling a 
 stored procedure, cf.
 SQL 2003, vol 2, section 4.34.1.1 and 4.27.3.
 This allows a caller to keep its current role after a call even if changed by 
 the stored procedure.
 This issue will implement the current role name part (cell) of the 
 authorization stack. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (DERBY-3327) SQL roles: Implement authorization stack


 [ 
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dag H. Wanvik reopened DERBY-3327:
--


Sorry, Dan, I belatedly (I committed the patch) noticed you had further 
comments on this issue, thanks for looking at it!
I will reopen this issue and consider them.


 SQL roles: Implement authorization stack
 

 Key: DERBY-3327
 URL: https://issues.apache.org/jira/browse/DERBY-3327
 Project: Derby
  Issue Type: New Feature
  Components: Security, SQL
Reporter: Dag H. Wanvik
Assignee: Dag H. Wanvik
 Fix For: 10.4.0.0

 Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff, 
 DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat


 The current LanguageConnectionContext keeps the user authorization identifier 
 for an SQL session.
 The lcc is shared context also for nested connections (opened from stored 
 procedures).
 So far, for roles, the current role has been stored in the lcc also. However, 
 SQL requires that
 authorization identifers be pushed on a authorization stack when calling a 
 stored procedure, cf.
 SQL 2003, vol 2, section 4.34.1.1 and 4.27.3.
 This allows a caller to keep its current role after a call even if changed by 
 the stored procedure.
 This issue will implement the current role name part (cell) of the 
 authorization stack. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3323) ComparisonFailure in derbyStress


[ 
https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561185#action_12561185
 ] 

Kathey Marsden commented on DERBY-3323:
---

We do document:
The existence of an open cursor that references table being dropped cause the 
DROP TABLE statement to generate an error, and the table is not dropped.

Which as a user I would read as not closed, either explicitly or by garbage 
collection.   I don't think that it is a bug that DROP TABLE does not attempt 
garbage collection, but do think it would be a nice improvement.   We do so for 
SET TRANSACTION ISOLATION.  Should I file a issue to have Derby attempt garbage 
collection if it detects open result sets when attempting DROP TABLE?



 ComparisonFailure in derbyStress
 

 Key: DERBY-3323
 URL: https://issues.apache.org/jira/browse/DERBY-3323
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: jvm1.4 lin
 jvm1.5 lin, linN+1
 vm1.6 sles,sol, solN+1
 jvm1.5 w2003
Reporter: Ole Solberg
Assignee: Kathey Marsden
Priority: Minor

 See 
 jvm1.4 lin : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html
 jvm1.5 lin, jvm1.5 linN+1 : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html
 jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html
 jvm1.5 w2003: 
 http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html
 1) 
 derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure:
  Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- 
 unexpected exception ]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
   at 
 org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3327) SQL roles: Implement authorization stack

[
https://issues.apache.org/jira/browse/DERBY-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561186#action_12561186
]

Daniel John Debrunner commented on DERBY-3327:
--

np - one other item is that according to section 10.4 routine invocation the
order is:

GR2) Evaluate arguments
GR5) Push new SQL-session context (RSC)
GR7/8) Execute the routine

The order in the patch is:
A) Push new authorization context
B) Evaluate arguments
C) Execute the routine

To match the order of the spec the new context would need to be part of the
generated code.
Not sure if it makes any difference or not, but something to consider.

Ok - one other item ...
I don't think the patch addresses functions, since the lcc.pushCaller() is
only set from CallStatementResultSet.

Performing the context setup in generated code would solve both of these issues.

SQL roles: Implement authorization stack

Attachments: DERBY-3327-1.diff, DERBY-3327-1.stat, DERBY-3327-2.diff,
DERBY-3327-2.stat, DERBY-3327-3.diff, DERBY-3327-3.stat

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3323) ComparisonFailure in derbyStress


[ 
https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561187#action_12561187
 ] 

Daniel John Debrunner commented on DERBY-3323:
--

I thought DROP TABLE did perform gc since 
GenericLanguageConnectionContext.verifyNoOpenResultSets does and I thought 
that's what DROP TABLE would end up calling.

I'm curious, do you know why  where gc() is called for SET TRANSACTION 
ISOLATION, I can't see the connection ...

 ComparisonFailure in derbyStress
 

 Key: DERBY-3323
 URL: https://issues.apache.org/jira/browse/DERBY-3323
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: jvm1.4 lin
 jvm1.5 lin, linN+1
 vm1.6 sles,sol, solN+1
 jvm1.5 w2003
Reporter: Ole Solberg
Assignee: Kathey Marsden
Priority: Minor

 See 
 jvm1.4 lin : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html
 jvm1.5 lin, jvm1.5 linN+1 : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html
 jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html
 jvm1.5 w2003: 
 http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html
 1) 
 derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure:
  Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- 
 unexpected exception ]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
   at 
 org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3323) ComparisonFailure in derbyStress


[ 
https://issues.apache.org/jira/browse/DERBY-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561188#action_12561188
 ] 

Kathey Marsden commented on DERBY-3323:
---

The gc()  happens in 
GenericLanguageConnectionContext.verifiyAllHeldResultSetsAreClosed() which is  
called from GenericLanguageConnectionContext.setIsolationLevel().  I missed the 
gc()  in verifyNoOpenResultSets().  

 ComparisonFailure in derbyStress
 

 Key: DERBY-3323
 URL: https://issues.apache.org/jira/browse/DERBY-3323
 Project: Derby
  Issue Type: Bug
  Components: Regression Test Failure
Affects Versions: 10.4.0.0
 Environment: jvm1.4 lin
 jvm1.5 lin, linN+1
 vm1.6 sles,sol, solN+1
 jvm1.5 w2003
Reporter: Ole Solberg
Assignee: Kathey Marsden
Priority: Minor

 See 
 jvm1.4 lin : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/612516_bySig.html
 jvm1.5 lin, jvm1.5 linN+1 : 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/612516_bySig.html
 jvm1.6 sles, jvm1.6 sol, jvm1.6 solN+1: 
 http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/612516_bySig.html
 jvm1.5 w2003: 
 http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/FailReports/612526_bySig.html
 1) 
 derbyStress(org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest)junit.framework.ComparisonFailure:
  Output at line 6 expected:[Test derbyStress finished.] but was:[FAIL -- 
 unexpected exception ]
   at 
 org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100)
   at 
 org.apache.derbyTesting.functionTests.util.HarnessJavaTest.runTest(HarnessJavaTest.java:91)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:96)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3305) Embedded ResultSet.getStatement() returns incorrect reference for dynamic result sets


 [ 
https://issues.apache.org/jira/browse/DERBY-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel John Debrunner closed DERBY-3305.


   Resolution: Fixed
Fix Version/s: 10.4.0.0

Fixed in trunk with tests. Any backport to 10.3 will also require DERBY-3311 as 
this exposes a bug fixed by DERBY-3311.

 Embedded ResultSet.getStatement() returns incorrect reference for dynamic 
 result sets
 -

 Key: DERBY-3305
 URL: https://issues.apache.org/jira/browse/DERBY-3305
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.4.0.0
Reporter: Daniel John Debrunner
Assignee: Daniel John Debrunner
Priority: Minor
 Fix For: 10.4.0.0


 ResultSets returned as dynamic results sets, ie. those created in a java 
 procedure and returned via the java.sql.Statement that executed the call of 
 the procedure, do not return the correct statement reference for 
 getStatement. Need to return reference to statement that executed the CALL 
 and returned the ResultSet instead of the statement that performed the 
 executeQuery.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3311) Client ResultSet.getHoldabilty will return incorrect value when the ResultSet is obtained from a procedure call