[ 
https://issues.apache.org/jira/browse/DERBY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534970
 ] 

nmset edited comment on DERBY-3095 at 10/15/07 2:13 PM:
-------------------------------------------------------------

You're right on this point.

1. Perhaps we should abandon CURRENT USER as a SQL92Identifier, i.e, EVE and 
eve whether quoted or not should never refer to the same CURRENT USER.

appendId(String id, String list) in IdUtil.java doesn't parse the identifier to 
be appended.
deleteId(String id, String list) does this parsing with the on disk identifier 
which was not parsed and hence uppercased when it was appended.

appenId saves eve.
deleteId compares whatever input with EVE, and not eve.

We may consider deleteId with this diff :
                   if (!id.equals(enteredList_a[ix]))

Is it a fundamental requirement that any of Derby object be case insensitive 
unless specified by enclosed quotes ?


2. One more consideration :
In parseId(StringReader r, boolean normalize, boolean normalizeToUpper)

                 return parseQId(r,normalize);

should perhaps be written as 

                return parseQId(r,false);

so that a quoted identifier doesn't lose its quotes. This way, what is really 
on disk can be compared to whatever is supplied from outside, with or without 
quotes.



/\ BTW, EVE and eve can only coexist as "EVE" and "eve", or "EVE" and eve, or 
EVE and "eve". So modifying as per 2 above may be required together with 
modifying deleteId.

      was (Author: nmset):
    You're right on this point.

1. Perhaps we should abandon CURRENT USER as a SQL92Identifier, i.e, EVE and 
eve whether quoted or not should never refer to the same CURRENT USER.

appendId(String id, String list) in IdUtil.java doesn't parse the identifier to 
be appended.
deleteId(String id, String list) does this parsing with the on disk identifier 
which was not parsed and hence uppercased when it was appended.

appenId saves eve.
deleteId compares whatever input with EVE, and not eve.

We may consider deleteId with this diff :
                   if (!id.equals(enteredList_a[ix]))

Is it a fundamental requirement that any of Derby object be case insensitive 
unless specified by enclosed quotes ?


2. One more consideration :
In parseId(StringReader r, boolean normalize, boolean normalizeToUpper)

                 return parseQId(r,normalize);

should perhaps be written as 

                return parseQId(r,false);

so that a quoted identifier doesn't lose its quotes. This way, what is really 
on disk can be compared to whatever is supplied from outside, with or without 
quotes.



/\ BTW, EVE and eve can only coexist as "EVE" and "eve", or "EVE" and eve, or 
EVE and "eve". So modifying as per 2 above may resolve the problem better than 
modifying deleteId.
  
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS
> ----------------------------------------------------
>
>                 Key: DERBY-3095
>                 URL: https://issues.apache.org/jira/browse/DERBY-3095
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions: 10.3.1.4
>         Environment: Linux 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 
> x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
>            Reporter: EDAH-TALLY
>         Attachments: 3095_00.diff, 3095_01.diff, d3095.sql, 
> REGTEST3095_00.zip, Reproduce3095.zip
>
>
> Sorry to bother you again.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, 'NOACCESS') FAILS and here's the 
> stack trace : 
> ******************************************************************************************
> java.sql.SQLException: Droit d'accès 'NOACCESS' inconnu.
>         at 
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
>         at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
> Source)
>         at org.apache.derby.client.am.PreparedStatement.execute(Unknown 
> Source)
>         at com.somecom.createUser(someAPP.java:190)
>         at com.somecom.grantKeys(someAPP.java:288)
>         at com.somecom.showGrantKeys(someAPP.java:269)
>         at com.somecom.MDIMenuClicked(someAPP.java:620)
>         at com.somecom.access$000(someAPP.java:15)
>         at com.somecom$5.actionPerformed(someAPP.java:564)
>         at 
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
>         at 
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
>         at 
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
>         at 
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
>         at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
>         at 
> javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
>         at 
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
>         at java.awt.Component.processMouseEvent(Component.java:6038)
>         at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
>         at java.awt.Component.processEvent(Component.java:5803)
>         at java.awt.Container.processEvent(Container.java:2058)
>         at java.awt.Component.dispatchEventImpl(Component.java:4410)
>         at java.awt.Container.dispatchEventImpl(Container.java:2116)
>         at java.awt.Component.dispatchEvent(Component.java:4240)
>         at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
>         at 
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
>         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
>         at java.awt.Container.dispatchEventImpl(Container.java:2102)
>         at java.awt.Window.dispatchEventImpl(Window.java:2429)
>         at java.awt.Component.dispatchEvent(Component.java:4240)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
>         at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
>         at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
>         at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
>         at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
>         at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
> Caused by: org.apache.derby.client.am.SqlException: Droit d'accès 'NOACCESS' 
> inconnu.
>         at org.apache.derby.client.am.Statement.completeExecute(Unknown 
> Source)
>         at 
> org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown 
> Source)
>         at 
> org.apache.derby.client.net.NetStatementReply.readExecuteCall(Unknown Source)
>         at org.apache.derby.client.net.StatementReply.readExecuteCall(Unknown 
> Source)
>         at org.apache.derby.client.net.NetStatement.readExecuteCall_(Unknown 
> Source)
>         at org.apache.derby.client.am.Statement.readExecuteCall(Unknown 
> Source)
>         at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown 
> Source)
>         at org.apache.derby.client.am.PreparedStatement.executeX(Unknown 
> Source)
>         ... 34 more
> *********************************************************************************************
> FULLACCESS : OK
> READONLYACCESS : OK
> NOACCESS : FAILURE
> By the way, the CONNECTION_PERMISSION parameter in the documentation is not 
> up to date.
> Thank you for considering.

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

Reply via email to