Developer Acess for my account
Good Day.. I am Jazarine Jamal, a student of Computer Science and is participating in Sun's Code for freedom contest. I've registered for a JIRA account at http://issues.apache.org/jira I request you to grant developer access to my account so that I can work on bugs in apache derby. Reference: Mayuresh Nirhali, Sun Mentor. strive to be a memory of time!!! ==Jaz===
Finding object type
Is there a function in the derby source code to find the type of an object.. i.e. if the XXX is a table , it should return 'TABLE' .. if YYY is a view, it should return 'VIEW'.. or anything like that?? please tell where to look for it.. please help asap...
Getting the LangaugeConnectionContext
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..
Re: Getting the LangaugeConnectionContext
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..? On Jan 20, 2008 6:07 PM, Thomas Nielsen < [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.. > >
Re: Getting the LangaugeConnectionContext
Hi Dan.. What I actually am trying to do is to get an object's type..i.e. is it a table, view or synonym.. Thanks.. On 1/21/08, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > > 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. >
Derby Testing
I've just fixed a source bug on derby but don't quite know how to test it.. The wiki has been telling me that I need to write my own tests to test derby.. And do I have to run all the tests: Functional,performance etc..? Please give me an insight into Derby Testing...
Re: Derby Testing
Also can anyone help with performing derby tests using netbeans...? On Jan 31, 2008 7:17 PM, Jazarine Jamal <[EMAIL PROTECTED]> wrote: > I've just fixed a source bug on derby but don't quite know how to test > it.. > The wiki has been telling me that I need to write my own tests to test > derby.. > > And do I have to run all the tests: Functional,performance etc..? > > Please give me an insight into Derby Testing... >
Newbie to Derby Testing
Hi I've been getting a lot of help on Testing Derby..Thanks for that... But i'm still not able to run a single functional test. I am a newbie into development of derby... I've been reading the README.html under /trunk/java/testing/. It says that the classpath requires the files called: - db2jcc.jar - db2jcc_license_c.jar in the classpath and it says it can be obtained from this site: http://www.ibm.com/developerworks/db2/downloads/jcc/index.html But the link on this site is pointing to some other file called : db2_clients_linux.zip thus, i can't get that done too... It will be really helpfull if someone can give me a simple walkthrough to run a single test..
Junit test problem
I made a code change and then when i run the junit test: org.apache.derbyTesting.functionTests.suites.All some 5 tests get passed and then some E occurs and then the test never gets further. No error message comes out too... This is the same state for 12 hours.. What could be the reason.?
Schema Creation
Hi, I just wanted to know this. In the embedded ij tool, is a schema created when the user is created, or at some later point of time?
SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY
Hi I would like to know if SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY in SystemProcedures.java is used only only when issuing a VALUES SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY() function call? If not, when is it otherwise executed? Just give one eg. if possible. I am working on a bug and the answer to this query will be very helpfull. Thanks..
Re: SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY
Thanks for that one Rick.
But I was actually asking if any tools like ij run this function implicitly
for any reason such as authenticating a user etc.
I want to make sure that this function is called only when a VALUES
SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('');
is issued by the end user.
Is it like that.?
On Thu, Feb 14, 2008 at 3:18 AM, Rick Hillegas <[EMAIL PROTECTED]>
wrote:
> Jazarine Jamal wrote:
> > Hi
> >
> > I would like to know if
> > SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY in SystemProcedures.java is
> > used only only when issuing a VALUES
> > SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY() function call?
> > If not, when is it otherwise executed? Just give one eg. if possible.
> >
> > I am working on a bug and the answer to this query will be very
> helpfull.
> >
> > Thanks..
> Hi Jazarine,
>
> I don't know if this is what you are looking for, but here is an example
> of invoking get_database_property in a query:
>
> create function intToString
> (
>intVal int
> )
> returns varchar( 10 )
> language java
> parameter style java
> no sql
> external name 'java.lang.Integer.toString'
> ;
>
> select t2.*
>from
>sys.systables systabs,
>table (syscs_diag.space_table(systabs.tablename)) as t2
>where systabs.tabletype = 'T'
>and intToString( t2.pagesize
> )=syscs_util.syscs_get_database_property( 'derby.storage.pageSize' )
> ;
>
> Hope this helps,
> -Rick
>
Re: SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY
Thanks Rick,
That was helpful..
On Thu, Feb 14, 2008 at 7:03 PM, Rick Hillegas <[EMAIL PROTECTED]>
wrote:
> Hi Jazarine,
>
> I don't see any references to that function in the tools code.
>
> Regards,
> -Rick
>
> Jazarine Jamal wrote:
> > Thanks for that one Rick.
> > But I was actually asking if any tools like ij run this function
> > implicitly for any reason such as authenticating a user etc.
> > I want to make sure that this function is called only when a VALUES
> > SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('');
> > is issued by the end user.
> > Is it like that.?
> >
> > On Thu, Feb 14, 2008 at 3:18 AM, Rick Hillegas
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Jazarine Jamal wrote:
> > > Hi
> > >
> > > I would like to know if
> > > SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY in SystemProcedures.java is
> > > used only only when issuing a VALUES
> > > SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY() function call?
> > > If not, when is it otherwise executed? Just give one eg. if
> > possible.
> > >
> > > I am working on a bug and the answer to this query will be very
> > helpfull.
> > >
> > > Thanks..
> > Hi Jazarine,
> >
> > I don't know if this is what you are looking for, but here is an
> > example
> > of invoking get_database_property in a query:
> >
> > create function intToString
> > (
> >intVal int
> > )
> > returns varchar( 10 )
> > language java
> > parameter style java
> > no sql
> > external name 'java.lang.Integer.toString'
> > ;
> >
> > select t2.*
> >from
> >sys.systables systabs,
> >table (syscs_diag.space_table(systabs.tablename)) as t2
> >where systabs.tabletype = 'T'
> >and intToString( t2.pagesize
> > )=syscs_util.syscs_get_database_property( 'derby.storage.pageSize' )
> > ;
> >
> > Hope this helps,
> > -Rick
> >
> >
>
>
[jira] Resolved: (DERBY-2993) Duplicated description of java.sql.ResultSet#beforeFirst() is written in reference manual
[ https://issues.apache.org/jira/browse/DERBY-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal resolved DERBY-2993. --- Resolution: Fixed > Duplicated description of java.sql.ResultSet#beforeFirst() is written in > reference manual > - > > Key: DERBY-2993 > URL: https://issues.apache.org/jira/browse/DERBY-2993 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefjdbc77156.html >Reporter: Tomohito Nakayama >Assignee: Abhilash T.G >Priority: Minor > Attachments: DERBY-2993.diff > > > In the table of "JDBC 2.0 ResultSet Methods Supported", there exists two rows > of beforeFirst(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2012) The Syntax of the UPDATE and DELETE statements is not correct in the reference manual
[ https://issues.apache.org/jira/browse/DERBY-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal resolved DERBY-2012. --- Resolution: Fixed > The Syntax of the UPDATE and DELETE statements is not correct in the > reference manual > - > > Key: DERBY-2012 > URL: https://issues.apache.org/jira/browse/DERBY-2012 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Christian d'Heureuse >Assignee: Abhilash T.G >Priority: Minor > Attachments: DERBY-2012.diff > > > The syntax description of the UPDATE and DELETE statements in the reference > manual does not imply that an alias name may be specified for the table name. > The statements are currently documented as: > UPDATE table-Name > SET ... > DELETE FROM table-Name > [ WHERE ... ] > This should be changed to: > UPDATE table-Name [ [ AS ] correlation-Name ] > SET ... > DELETE FROM table-Name [ [ AS ] correlation-Name ] > [ WHERE ... ] > (Table alias names for UPDATE and DELETE are important for the WHERE clauses, > e.g. when the same table is used a second time within a subquery in the WHERE > condition, e.g.: > UPDATE table1 a > SET ... > WHERE EXISTS ( > SELECT * FROM table1 b WHERE a.field1 = b.field2 ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3213) SQLChar.trim method is unused and could be removed
[ https://issues.apache.org/jira/browse/DERBY-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal resolved DERBY-3213. --- Resolution: Fixed > SQLChar.trim method is unused and could be removed > -- > > Key: DERBY-3213 > URL: https://issues.apache.org/jira/browse/DERBY-3213 > Project: Derby > Issue Type: Improvement > Components: Newcomer, SQL >Reporter: Bryan Pendleton >Assignee: Deepthi Devaki A R >Priority: Minor > Attachments: DERBY-3213.diff > > > As part of researching DERBY-2352, I came to the conclusion that > the trim() method in SQLChar.java is no longer used, and could be > removed. It appears that all calls to this method have been switched > to call ansiTrim() instead. > Hopefully, this just requires removing the code from SQLChar.java > and StringDataValue.java, and running all the tests to verify that > nothing is broken. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2585) Mistaken description in page of CLOB
[ https://issues.apache.org/jira/browse/DERBY-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal resolved DERBY-2585. --- Resolution: Fixed > Mistaken description in page of CLOB > - > > Key: DERBY-2585 > URL: https://issues.apache.org/jira/browse/DERBY-2585 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.3.1.4 > Environment: http://db.apache.org/derby/docs/dev/ref/rrefclob.html >Reporter: Tomohito Nakayama >Assignee: Sandeep A > Attachments: derby-2585.zip, derby2585.diff > > > There existed next description in page of CLOB. > > A CLOB without a specified length is defaulted to two gigabytes > > (2,147,483,647). > However, this page explains that length of CLOB is counted as number of > characters and not as number of bytes. > Then I think above description should be written as two giga characters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2615) Minor errata in page of "Where dynamic parameters are allowed" of reference manual
[
https://issues.apache.org/jira/browse/DERBY-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jazarine Jamal resolved DERBY-2615.
---
Resolution: Fixed
> Minor errata in page of "Where dynamic parameters are allowed" of reference
> manual
> --
>
> Key: DERBY-2615
> URL: https://issues.apache.org/jira/browse/DERBY-2615
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Environment:
> http://db.apache.org/derby/docs/dev/ref/rrefsqlj1083019.html
>Reporter: Tomohito Nakayama
>Assignee: Sandeep A
>Priority: Minor
> Attachments: DERBY-2615.diff, derby-2615.zip
>
>
> In this page, next example was written.
> WHERE ? BETWEEN DATE('1996-01-01') AND ?
> -- types assumed to be DATES
> WHERE DATE('1996-01-01') BETWEEN ? AND ?
> -- types assumed to be DATES
> DATES should be DATE
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3246) Minor cleanup in the Derby JUnit classes
[ https://issues.apache.org/jira/browse/DERBY-3246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal resolved DERBY-3246. --- Resolution: Fixed > Minor cleanup in the Derby JUnit classes > > > Key: DERBY-3246 > URL: https://issues.apache.org/jira/browse/DERBY-3246 > Project: Derby > Issue Type: Improvement > Components: Test >Affects Versions: 10.3.2.1, 10.4.0.0 >Reporter: Kristian Waagan >Assignee: Abhilash T.G >Priority: Trivial > Fix For: 10.3.2.2, 10.4.0.0 > > Attachments: derby-3246-1a_unused-imports.diff > > > Several of the JUnit classes have grown/developed and need various types of > cleanup; > - remove unused imports > - improve/add JavaDoc > - remove unused methods > - etc... > This issue is basically a placeholder for the patches. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3408) Wrong message when using SHOW in ij.
[ https://issues.apache.org/jira/browse/DERBY-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616855#action_12616855 ] Jazarine Jamal commented on DERBY-3408: --- Very goood improvement indeed! Knut's comment is important too. We could have an another option of including all the errors falling under the category: message 42X01 (the general all-purpose 'syntax error' message) in the help command. What do everyone think of this? Will it increase the footprint size considerably? > Wrong message when using SHOW in ij. > > > Key: DERBY-3408 > URL: https://issues.apache.org/jira/browse/DERBY-3408 > Project: Derby > Issue Type: Bug > Components: SQL >Reporter: Jazarine Jamal >Priority: Minor > Attachments: suggestHelp.diff > > > When running the show command using ij, it gives out a wrong message. > eg.: > ij> show schema; > ERROR 42X01: Syntax error: Encountered "show" at line 2, column 1. > The message should be something like: > Syntax error: Encountered "schema" at line 2,column 1:no such thing as > "schema" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-887) Select statement returns wrong number of rows if you compare an integer column with a boolean expression in the where clause
[ https://issues.apache.org/jira/browse/DERBY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547622 ] Jazarine Jamal commented on DERBY-887: -- i encoutnered the following problem when trying to run the queries. ij> create table test887(id bigint); 0 rows inserted/updated/deleted ij> INSERT INTO TEST887 VALUES (801), (802), (803), (804); ij> select * from test887 where id = 0<3; ID 801 802 803 804 ij> select * from test887 where id = true; ERROR 42X01: Syntax error: true. i dont understand why is the second statement giving a syntax error while the first one generates the correct output both (0<3) and true are equivalent > Select statement returns wrong number of rows if you compare an integer > column with a boolean expression in the where clause > > > Key: DERBY-887 > URL: https://issues.apache.org/jira/browse/DERBY-887 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6 > Environment: Java : java version "1.5.0_02" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09) > Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode) > Classpath : c:/pantry/derby.jar;c:/pantry/derbytools.jar; > OS: Windows XP Professional >Reporter: Manjula Kutty > Attachments: bug887_interim.diff, bug887_interim.diff, DERBY-887.sql > > > I have a table with 2 columns one is BIGINT which is Generated always > starting with 1 and increment by1 and the other one is timestamp > ij> select id,date from inbox where id = 0<3; > ID |DATE > --- > 25 |2006-01-26 14:35:46.584 > 34 |2006-01-26 14:36:16.588 > 21 |2006-01-26 14:34:46.455 > 22 |2006-01-26 14:34:47.176 > 27 |2006-01-26 14:35:47.054 > 24 |2006-01-26 14:35:16.58 > 28 |2006-01-26 14:35:47.305 > 35 |2006-01-26 14:36:18.771 > 31 |2006-01-26 14:35:48.496 > 32 |2006-01-26 14:35:48.887 > 33 |2006-01-26 14:35:49.308 > 11 rows selected > ij> select id,date from inbox where id = true; > ID |DATE > --- > 21 |2006-01-26 14:34:46.455 > 1 row selected > Both queries should return same number of rows > Also If I delete the first row from the table then select id,date from inbox > where id = true; returns the second row > ij> delete from inbox where id=21; > 1 row inserted/updated/deleted > Then again run > ij> select id ,date from inbox where id=true; > ID |DATE > --- > 22 |2006-01-26 14:35:16.58 > Which indicates that the select returns only the first row and then is > getting closed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-1666) Show Views and Show Synonyms has confusing column names in results
[ https://issues.apache.org/jira/browse/DERBY-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal reassigned DERBY-1666: - Assignee: Jazarine Jamal i JUST STARTED WORKING ON THE BUG.. > Show Views and Show Synonyms has confusing column names in results > -- > > Key: DERBY-1666 > URL: https://issues.apache.org/jira/browse/DERBY-1666 > Project: Derby > Issue Type: Bug > Components: Tools >Affects Versions: 10.2.1.6 >Reporter: David Van Couvering > Assignee: Jazarine Jamal >Priority: Minor > > When you run SHOW VIEWS and SHOW SYNONYMS, the column names are confusing. > They use TABLE_SCHEM and TABLE_NAME instead of VIEW_SCHEM/VIEW_NAME and > SYNONYM_SCHEM/SYONYM_NAME > === Examples === > ij> show views; > TABLE_SCHEM |TABLE_NAME |REMARKS > > APP |AA_FLIGHTS | > ij> show synonyms; > TABLE_SCHEM |TABLE_NAME|REMARKS > > APP |COLUMNS | > APP |TRIGGERS | -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable
[ https://issues.apache.org/jira/browse/DERBY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal reassigned DERBY-2592: - Assignee: Jazarine Jamal > Wrong description of IndexName field in public JavaDoc for LockTable > > > Key: DERBY-2592 > URL: https://issues.apache.org/jira/browse/DERBY-2592 > Project: Derby > Issue Type: Bug > Components: Javadoc >Affects Versions: 10.3.1.4 >Reporter: Olav Sandstaa > Assignee: Jazarine Jamal >Priority: Trivial > > The public JavaDoc for LockTable says the following in the description of the > INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE: >INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the > index, this can only happen if this is not a user transaction. > I think the last part is wrong. Normal user transactions might also have a > value in the INDEXNAME. For example, here is part of the lock table for three > user transactions: > XID |TYPE |MODE|TABLENAME |LOCKNAME |STATE|TABLETYPE|INDEXNAME > - > 186 |ROW |X |T2|(1,9) |GRANT|T|NULL > 184 |ROW |S |T2|(1,9) |WAIT |T|NULL > 188 |ROW |X |T1|(1,11)|GRANT|T|NULL > 186 |ROW |S |T1|(1,11)|WAIT |T|NULL > 186 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 188 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 184 |ROW |X |T1|(1,7) |GRANT|T|NULL > 188 |ROW |S |T1|(1,7) |WAIT |T|NULL > Two of the lock entries have an index. I expect this to be the Scan lock that > have been set during traversal of the B-tree. > Proposed fix: remove the last part of the sentence. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563176#action_12563176 ] Jazarine Jamal commented on DERBY-2239: --- I just looked upon this documentation and reproduced it in ij... I have this proposed changes: SELECT COUNT(*),WORK_DEPT,AVG(SALARY) FROM EMPLOYEE GROUP BY WORK_DEPT ORDER BY 3; Please provide feedback on this. > Example of SelectExpression for GROUP BY clause is mistaken > --- > > Key: DERBY-2239 > URL: https://issues.apache.org/jira/browse/DERBY-2239 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html >Reporter: Tomohito Nakayama >Assignee: Jazarine Jamal > > There is next example. > -- List head count of each department, > -- the department number (WORKDEPT), and the average departmental salary > (SALARY) > -- for all departments in the EMPLOYEE table. > -- Arrange the result table in ascending order by average departmental salary. > SELECT WORKDEPT, AVG(SALARY) > FROM EMPLOYEE > GROUP BY WORKDEPT > ORDER BY 1 > Comment told that head count of each department is listed, but not exaxtly. > I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal reassigned DERBY-2239: - Assignee: Jazarine Jamal > Example of SelectExpression for GROUP BY clause is mistaken > --- > > Key: DERBY-2239 > URL: https://issues.apache.org/jira/browse/DERBY-2239 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html >Reporter: Tomohito Nakayama >Assignee: Jazarine Jamal > > There is next example. > -- List head count of each department, > -- the department number (WORKDEPT), and the average departmental salary > (SALARY) > -- for all departments in the EMPLOYEE table. > -- Arrange the result table in ascending order by average departmental salary. > SELECT WORKDEPT, AVG(SALARY) > FROM EMPLOYEE > GROUP BY WORKDEPT > ORDER BY 1 > Comment told that head count of each department is listed, but not exaxtly. > I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable
[ https://issues.apache.org/jira/browse/DERBY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-2592: -- Attachment: DERBY-2592.diff I just removed the last part of the sentence and now I think the documentation is right.. > Wrong description of IndexName field in public JavaDoc for LockTable > > > Key: DERBY-2592 > URL: https://issues.apache.org/jira/browse/DERBY-2592 > Project: Derby > Issue Type: Bug > Components: Javadoc >Affects Versions: 10.3.1.4 >Reporter: Olav Sandstaa > Assignee: Jazarine Jamal >Priority: Trivial > Attachments: DERBY-2592.diff > > > The public JavaDoc for LockTable says the following in the description of the > INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE: >INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the > index, this can only happen if this is not a user transaction. > I think the last part is wrong. Normal user transactions might also have a > value in the INDEXNAME. For example, here is part of the lock table for three > user transactions: > XID |TYPE |MODE|TABLENAME |LOCKNAME |STATE|TABLETYPE|INDEXNAME > - > 186 |ROW |X |T2|(1,9) |GRANT|T|NULL > 184 |ROW |S |T2|(1,9) |WAIT |T|NULL > 188 |ROW |X |T1|(1,11)|GRANT|T|NULL > 186 |ROW |S |T1|(1,11)|WAIT |T|NULL > 186 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 188 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 184 |ROW |X |T1|(1,7) |GRANT|T|NULL > 188 |ROW |S |T1|(1,7) |WAIT |T|NULL > Two of the lock entries have an index. I expect this to be the Scan lock that > have been set during traversal of the B-tree. > Proposed fix: remove the last part of the sentence. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable
[ https://issues.apache.org/jira/browse/DERBY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563506#action_12563506 ] Jazarine Jamal commented on DERBY-2592: --- The problem was that there was a statement:"This can only happen if this is not a user transaction" In the example, there are two lock entries that have an index. Thus the whole sentence is re-framed into: INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the index. I hope this resolves the problem... > Wrong description of IndexName field in public JavaDoc for LockTable > > > Key: DERBY-2592 > URL: https://issues.apache.org/jira/browse/DERBY-2592 > Project: Derby > Issue Type: Bug > Components: Javadoc >Affects Versions: 10.3.1.4 >Reporter: Olav Sandstaa >Assignee: Jazarine Jamal >Priority: Trivial > Attachments: DERBY-2592.diff > > > The public JavaDoc for LockTable says the following in the description of the > INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE: >INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the > index, this can only happen if this is not a user transaction. > I think the last part is wrong. Normal user transactions might also have a > value in the INDEXNAME. For example, here is part of the lock table for three > user transactions: > XID |TYPE |MODE|TABLENAME |LOCKNAME |STATE|TABLETYPE|INDEXNAME > - > 186 |ROW |X |T2|(1,9) |GRANT|T|NULL > 184 |ROW |S |T2|(1,9) |WAIT |T|NULL > 188 |ROW |X |T1|(1,11)|GRANT|T|NULL > 186 |ROW |S |T1|(1,11)|WAIT |T|NULL > 186 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 188 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 184 |ROW |X |T1|(1,7) |GRANT|T|NULL > 188 |ROW |S |T1|(1,7) |WAIT |T|NULL > Two of the lock entries have an index. I expect this to be the Scan lock that > have been set during traversal of the B-tree. > Proposed fix: remove the last part of the sentence. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable
[ https://issues.apache.org/jira/browse/DERBY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-2592: -- Derby Info: [Patch Available] > Wrong description of IndexName field in public JavaDoc for LockTable > > > Key: DERBY-2592 > URL: https://issues.apache.org/jira/browse/DERBY-2592 > Project: Derby > Issue Type: Bug > Components: Javadoc >Affects Versions: 10.3.1.4 >Reporter: Olav Sandstaa > Assignee: Jazarine Jamal >Priority: Trivial > Attachments: DERBY-2592.diff > > > The public JavaDoc for LockTable says the following in the description of the > INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE: >INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the > index, this can only happen if this is not a user transaction. > I think the last part is wrong. Normal user transactions might also have a > value in the INDEXNAME. For example, here is part of the lock table for three > user transactions: > XID |TYPE |MODE|TABLENAME |LOCKNAME |STATE|TABLETYPE|INDEXNAME > - > 186 |ROW |X |T2|(1,9) |GRANT|T|NULL > 184 |ROW |S |T2|(1,9) |WAIT |T|NULL > 188 |ROW |X |T1|(1,11)|GRANT|T|NULL > 186 |ROW |S |T1|(1,11)|WAIT |T|NULL > 186 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 188 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 184 |ROW |X |T1|(1,7) |GRANT|T|NULL > 188 |ROW |S |T1|(1,7) |WAIT |T|NULL > Two of the lock entries have an index. I expect this to be the Scan lock that > have been set during traversal of the B-tree. > Proposed fix: remove the last part of the sentence. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2592) Wrong description of IndexName field in public JavaDoc for LockTable
[ https://issues.apache.org/jira/browse/DERBY-2592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-2592: -- Attachment: DERBY-2592_v2.diff I've attached the latest patch as DERBY-2592_v2.diff Please review this patch for committing.. I deleted the extra part, generated the javadoc for the project. The new javadoc does'nt contain the deleted part. > Wrong description of IndexName field in public JavaDoc for LockTable > > > Key: DERBY-2592 > URL: https://issues.apache.org/jira/browse/DERBY-2592 > Project: Derby > Issue Type: Bug > Components: Javadoc >Affects Versions: 10.3.1.4 >Reporter: Olav Sandstaa >Assignee: Jazarine Jamal >Priority: Trivial > Attachments: DERBY-2592.diff, DERBY-2592_v2.diff > > > The public JavaDoc for LockTable says the following in the description of the > INDEXNAME retrieved from SYSCS_DIAG.LOCK_TABLE: >INDEXNAME varchar(128) - normally null. If non-null, a lock is held on the > index, this can only happen if this is not a user transaction. > I think the last part is wrong. Normal user transactions might also have a > value in the INDEXNAME. For example, here is part of the lock table for three > user transactions: > XID |TYPE |MODE|TABLENAME |LOCKNAME |STATE|TABLETYPE|INDEXNAME > - > 186 |ROW |X |T2|(1,9) |GRANT|T|NULL > 184 |ROW |S |T2|(1,9) |WAIT |T|NULL > 188 |ROW |X |T1|(1,11)|GRANT|T|NULL > 186 |ROW |S |T1|(1,11)|WAIT |T|NULL > 186 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 188 |ROW |S |T1|(1,1) |GRANT|T|SQL070425023213370 > 184 |ROW |X |T1|(1,7) |GRANT|T|NULL > 188 |ROW |S |T1|(1,7) |WAIT |T|NULL > Two of the lock entries have an index. I expect this to be the Scan lock that > have been set during traversal of the B-tree. > Proposed fix: remove the last part of the sentence. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-2239: -- Derby Info: [Patch Available] > Example of SelectExpression for GROUP BY clause is mistaken > --- > > Key: DERBY-2239 > URL: https://issues.apache.org/jira/browse/DERBY-2239 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html >Reporter: Tomohito Nakayama >Assignee: Jazarine Jamal > Attachments: DERBY2239-ref.diff, newref.zip > > > There is next example. > -- List head count of each department, > -- the department number (WORKDEPT), and the average departmental salary > (SALARY) > -- for all departments in the EMPLOYEE table. > -- Arrange the result table in ascending order by average departmental salary. > SELECT WORKDEPT, AVG(SALARY) > FROM EMPLOYEE > GROUP BY WORKDEPT > ORDER BY 1 > Comment told that head count of each department is listed, but not exaxtly. > I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-2239: -- Attachment: newref.zip DERBY2239-ref.diff I have made changes to the file trunk/src/ref/rrefselectexpression.dita. The following lines : SELECT WORKDEPT, AVG(SALARY) FROM EMPLOYEE GROUP BY WORKDEPT ORDER BY 1 have been replaced with: SELECT COUNT(*),WORK_DEPT,AVG(SALARY) FROM EMPLOYEE GROUP BY WORK_DEPT ORDER BY 3; I build the new file with ant html and the resulting html page: rrefselectexpression.html contains the corrected code. The file newref.zip contains the corrected page. Please have a look at it. > Example of SelectExpression for GROUP BY clause is mistaken > --- > > Key: DERBY-2239 > URL: https://issues.apache.org/jira/browse/DERBY-2239 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html >Reporter: Tomohito Nakayama >Assignee: Jazarine Jamal > Attachments: DERBY2239-ref.diff, newref.zip > > > There is next example. > -- List head count of each department, > -- the department number (WORKDEPT), and the average departmental salary > (SALARY) > -- for all departments in the EMPLOYEE table. > -- Arrange the result table in ascending order by average departmental salary. > SELECT WORKDEPT, AVG(SALARY) > FROM EMPLOYEE > GROUP BY WORKDEPT > ORDER BY 1 > Comment told that head count of each department is listed, but not exaxtly. > I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2239) Example of SelectExpression for GROUP BY clause is mistaken
[ https://issues.apache.org/jira/browse/DERBY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal resolved DERBY-2239. --- Resolution: Fixed > Example of SelectExpression for GROUP BY clause is mistaken > --- > > Key: DERBY-2239 > URL: https://issues.apache.org/jira/browse/DERBY-2239 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html >Reporter: Tomohito Nakayama >Assignee: Jazarine Jamal > Attachments: DERBY2239-ref.diff, newref.zip > > > There is next example. > -- List head count of each department, > -- the department number (WORKDEPT), and the average departmental salary > (SALARY) > -- for all departments in the EMPLOYEE table. > -- Arrange the result table in ascending order by average departmental salary. > SELECT WORKDEPT, AVG(SALARY) > FROM EMPLOYEE > GROUP BY WORKDEPT > ORDER BY 1 > Comment told that head count of each department is listed, but not exaxtly. > I think count(*) is needed here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal reassigned DERBY-1824: - Assignee: Jazarine Jamal > Permission/privlege names in exceptions should be in upper case as keywords, > not lower case. > > > Key: DERBY-1824 > URL: https://issues.apache.org/jira/browse/DERBY-1824 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Daniel John Debrunner > Assignee: Jazarine Jamal >Priority: Minor > > E.g. > ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. > should be > ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567291#action_12567291 ] Jazarine Jamal commented on DERBY-1824: --- I tried reproducing this error. I created two users and created a table for one of the user ME. I revoked the select privilege from the second user. i got the same error but with a different error code:ERROR 42502. This is the error message that i got: ERROR 42502: User 'ME2' does not have select permission on column 'SS' of table 'ME'.'METEST'. Is this is the same error or different? > Permission/privlege names in exceptions should be in upper case as keywords, > not lower case. > > > Key: DERBY-1824 > URL: https://issues.apache.org/jira/browse/DERBY-1824 > Project: Derby > Issue Type: Improvement > Components: SQL > Reporter: Daniel John Debrunner >Assignee: Jazarine Jamal >Priority: Minor > > E.g. > ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. > should be > ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2547) possible NullPointerException in client/am/ProductLevel
[ https://issues.apache.org/jira/browse/DERBY-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568222#action_12568222 ] Jazarine Jamal commented on DERBY-2547: --- What do you think should be the value of versionLevel_ if productID is NULL. > possible NullPointerException in client/am/ProductLevel > --- > > Key: DERBY-2547 > URL: https://issues.apache.org/jira/browse/DERBY-2547 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.3.1.4 >Reporter: Myrna van Lunteren >Assignee: Abhilash T.G >Priority: Trivial > > Encountered a NPE that doesn't make it to the application/end-user when > debugging test jdbcapi/DataSourceTest in one of my eclipse workspaces; > org/apache/derby/client/am/ProductLevel > constructor; > versionLevel_ = Integer.parseInt(productID.substring(3,5)); > NPE because productID was null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3408) Wrong message when using SHOW in ij.
Wrong message when using SHOW in ij. Key: DERBY-3408 URL: https://issues.apache.org/jira/browse/DERBY-3408 Project: Derby Issue Type: Bug Components: SQL Reporter: Jazarine Jamal When running the show command using ij, it gives out a wrong message. eg.: ij> show schema; ERROR 42X01: Syntax error: Encountered "show" at line 2, column 1. he message should be something like: Syntax error: Encountered "schema" at line 2,column 1:no such thing as "schema" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3408) Wrong message when using SHOW in ij.
[ https://issues.apache.org/jira/browse/DERBY-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-3408: -- Description: When running the show command using ij, it gives out a wrong message. eg.: ij> show schema; ERROR 42X01: Syntax error: Encountered "show" at line 2, column 1. The message should be something like: Syntax error: Encountered "schema" at line 2,column 1:no such thing as "schema" was: When running the show command using ij, it gives out a wrong message. eg.: ij> show schema; ERROR 42X01: Syntax error: Encountered "show" at line 2, column 1. he message should be something like: Syntax error: Encountered "schema" at line 2,column 1:no such thing as "schema" > Wrong message when using SHOW in ij. > > > Key: DERBY-3408 > URL: https://issues.apache.org/jira/browse/DERBY-3408 > Project: Derby > Issue Type: Bug > Components: SQL >Reporter: Jazarine Jamal > > When running the show command using ij, it gives out a wrong message. > eg.: > ij> show schema; > ERROR 42X01: Syntax error: Encountered "show" at line 2, column 1. > The message should be something like: > Syntax error: Encountered "schema" at line 2,column 1:no such thing as > "schema" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568172#action_12568172 ] Jazarine Jamal commented on DERBY-1824: --- I made some changes in the StatementTablePermission.java...in the function getPrivName. In the function, there are the privlege names in lowercase. I changed them to UPPERCASE. I build the code and then tested it with the ij tool. The required change is found. I'm doing the junit functional tests for this now. Please comment. > Permission/privlege names in exceptions should be in upper case as keywords, > not lower case. > > > Key: DERBY-1824 > URL: https://issues.apache.org/jira/browse/DERBY-1824 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Daniel John Debrunner >Assignee: Jazarine Jamal >Priority: Minor > > E.g. > ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. > should be > ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3014) Make SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.') return NULL instead of the hash value of the password
[
https://issues.apache.org/jira/browse/DERBY-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568558#action_12568558
]
Jazarine Jamal commented on DERBY-3014:
---
A call to SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.')
property returns NULL evenn if the does not exist.
So, I was thinking if the system function returns a ** instead of null.
> Make SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY('derby.user.') return
> NULL instead of the hash value of the password
> ---
>
> Key: DERBY-3014
> URL: https://issues.apache.org/jira/browse/DERBY-3014
> Project: Derby
> Issue Type: Improvement
> Components: Security
>Reporter: Daniel John Debrunner
>Assignee: R VIDYA LAKSHMI
>
> Increases security by providing less information to any attacker. The current
> returned hash value could be used in an off-line dictionary based attack to
> find a valid password.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3408) Wrong message when using SHOW in ij.
[ https://issues.apache.org/jira/browse/DERBY-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-3408: -- Priority: Minor (was: Major) > Wrong message when using SHOW in ij. > > > Key: DERBY-3408 > URL: https://issues.apache.org/jira/browse/DERBY-3408 > Project: Derby > Issue Type: Bug > Components: SQL > Reporter: Jazarine Jamal >Priority: Minor > > When running the show command using ij, it gives out a wrong message. > eg.: > ij> show schema; > ERROR 42X01: Syntax error: Encountered "show" at line 2, column 1. > The message should be something like: > Syntax error: Encountered "schema" at line 2,column 1:no such thing as > "schema" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-1824: -- Derby Info: [Patch Available] > Permission/privlege names in exceptions should be in upper case as keywords, > not lower case. > > > Key: DERBY-1824 > URL: https://issues.apache.org/jira/browse/DERBY-1824 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Daniel John Debrunner > Assignee: Jazarine Jamal >Priority: Minor > Attachments: DERBY1824.diff > > > E.g. > ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. > should be > ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal updated DERBY-1824: -- Attachment: DERBY1824.diff I made changes to java/engine/org/apache/derby/iapi/sql/dictionary/StatementTablePermission.java The diff file has been attached. Please have look. I am running the junit tests for this fix. > Permission/privlege names in exceptions should be in upper case as keywords, > not lower case. > > > Key: DERBY-1824 > URL: https://issues.apache.org/jira/browse/DERBY-1824 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Daniel John Debrunner > Assignee: Jazarine Jamal >Priority: Minor > Attachments: DERBY1824.diff > > > E.g. > ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. > should be > ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568654#action_12568654 ] Jazarine Jamal commented on DERBY-1824: --- I built the project with the ccode change. Then, i reproduced the same error and the required change has been reflected. > Permission/privlege names in exceptions should be in upper case as keywords, > not lower case. > > > Key: DERBY-1824 > URL: https://issues.apache.org/jira/browse/DERBY-1824 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Daniel John Debrunner >Assignee: Jazarine Jamal >Priority: Minor > Attachments: DERBY1824.diff > > > E.g. > ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. > should be > ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-3418) Error message not helpful enough
Error message not helpful enough Key: DERBY-3418 URL: https://issues.apache.org/jira/browse/DERBY-3418 Project: Derby Issue Type: Improvement Reporter: Jazarine Jamal Priority: Minor When you start the ij tool, and before connecting, if u try to issue the CONNECT command, the error message which comes out is: IJ ERROR: Unable to establish connection. eg: bash-3.00# ij ij version 10.4 ij> CONNECT; IJ ERROR: Unable to establish connection This could be further improved into letting the user enter parameters or printing the right syntax for an existing command. This will be more helpful to the user. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-1824) Permission/privlege names in exceptions should be in upper case as keywords, not lower case.
[ https://issues.apache.org/jira/browse/DERBY-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jazarine Jamal resolved DERBY-1824. --- Resolution: Fixed > Permission/privlege names in exceptions should be in upper case as keywords, > not lower case. > > > Key: DERBY-1824 > URL: https://issues.apache.org/jira/browse/DERBY-1824 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Daniel John Debrunner > Assignee: Jazarine Jamal >Priority: Minor > Attachments: DERBY1824.diff > > > E.g. > ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. > should be > ERROR 28508: User 'MAMTA3' does not have SELECT permission on column 'C111' > of table 'MAMTA2'.'V21VIEWTEST'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
