from:"Satheesh Bandaram"





This patch is committed.

Sending   
java\engine\org\apache\derby\impl\sql\catalog\metadata_net.properties
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\metadataJdbc20.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\metadataJdbc20.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\metadataJdbc20.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\metadataJdbc20.java
Transmitting file data .
Committed revision 157015.

Satheesh

Mamta Satoor wrote:

  On Wed, 9 Mar 2005 08:41:52 +0100 (CET), Mamta A. Satoor (JIRA)
 wrote:
  
  
DatabaseMetaData calls related to changes made by others return incorrect values in Network Server mode.


Key: DERBY-169
URL: http://issues.apache.org/jira/browse/DERBY-169
Project: Derby
   Type: Bug
 Components: Network Server
   Versions: 10.0.2.1
   Reporter: Mamta A. Satoor
Assigned to: Mamta A. Satoor

I am working on getting updatable resultsets to work under Network Server mode. While running the test lang/updatableResultSet.java in Network Server mode, I came across following issue. DatabaseMetaData among other methods has 3 methods, othersUpdatesAreVisible, othersDeletesAreVisible and othersInsertsAreVisible. These 3 methods currently return true for TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE when running in Network Server mode. They should be returning false for TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE. The reason for that is
Derby does not yet implement scroll sensitive ResultSets and hence the 3 metadata calls mentioned above should return false. Also, scroll insensitive ResultSets by their definition do not see changes made by others and hence the 3 metadata calls should return false.

The fix for this is very easy and requires changes in apache\derby\impl\sql\catalog\metadata_net.properties.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
  http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
  http://www.atlassian.com/software/jira



  
  

Here is a very simple fix for the bug with the tests, I have run the
test suites and the fix hasn't caused any failures.

svn stat output
M  java\engine\org\apache\derby\impl\sql\catalog\metadata_net.properties
M  java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\metadataJdbc20.java
M  java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\metadataJdbc20.out
M  java\testing\org\apache\derbyTesting\functionTests\master\metadataJdbc20.out
M  java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\metadataJdbc20.out

Thanks,
Mamta
  
  

Index: java/engine/org/apache/derby/impl/sql/catalog/metadata_net.properties
===
--- java/engine/org/apache/derby/impl/sql/catalog/metadata_net.properties	(revision 156618)
+++ java/engine/org/apache/derby/impl/sql/catalog/metadata_net.properties	(working copy)
@@ -298,9 +298,9 @@
 	'',\
 	'',\
 	'',\
-	'1003,1004,1005',\
-	'1003,1004,1005',\
-	'1003,1004,1005',\
+	'1003',\
+	'1003',\
+	'1003',\
 	'',\
 	'',\
 	'',\
Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/metadataJdbc20.java
===
--- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/metadataJdbc20.java	(revision 156618)
+++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/metadataJdbc20.java	(working copy)
@@ -88,6 +88,21 @@
  			userNamedTypes[1] = java.sql.Types.STRUCT;
  			dumpRS(met.getUDTs("a", null, null, userNamedTypes));
 
+			System.out.println("Test the metadata calls related to visibility of changes made by others for different resultset types");
+			System.out.println("Since Derby materializes a forward only ResultSet incrementally, it is possible to see changes");
+			System.out.println("made by others and hence following 3 metadata calls will return true for forward only ResultSets.");
+			System.out.println("othersUpdatesAreVisible(ResultSet.TYPE_FORWARD_ONLY)? " + met.othersUpdatesAreVisible(ResultSet.TYPE_FORWARD_ONLY));
+			System.out.println("othersDeletesAreVisible(ResultSet.TYPE_FORWARD_ONLY)? " + met.othersDeletesAreVisible(ResultSet.TYPE_FORWARD_ONLY));
+			System.out.println("othersInsertsAreVisible(ResultSet.TYPE_FORWARD_ONLY)? " + met.othersInsertsAreVisible(ResultSet.TYPE_FORWARD_ONLY));
+			System.out.println("Scroll insensitive ResultSet by their definition do not see changes made by others and hence following metadata calls return false");
+			System.out.println("othersUpdatesAreVisible(ResultSet.TYPE_SCROLL_INSENSITIVE)? "

Re: [jira] Commented: (DERBY-172) Trigger activation

I personally think able to change values in BEFORE triggers would be
great to have. A SET new.column = xxx would be nice, but that falls
under SQL Stored Procedure language that Derby doesn't have. Commercial
databases like DB2 has DB2 SQL Procedure language, Oracle has PL/SQL and
Informix has support for SPL. It would be nice to add that capability to
Derby.

You can code your trigger logic in Derby Java functions, but Derby only
supports read-only operations in BEFORE triggers.

Satheesh

George Baklarz wrote:

>Thanks for the update. I was curious why it was supporting the syntax
>(well, close to it). The SYSTRIGGERS catalog table obviously had a slot for
>this type of trigger. I would have preferred the ability to change column
>values before having the statement execute though. Is there anything I can
>do from a logic perspective in a BEFORE trigger like a WHEN clause? Or does
>it always execute the statement:
>
>CREATE TRIGGER XXX NO CASCADE BEFORE INSERT ON A
>  REFERENCING OLD AS OLD NEW AS NEW FOR EACH ROW
> ... SELECT or VALUES...
>
>A SET NEW.column = xxx would have been nice.
>
>George
>___
>
>George Baklarz | Senior Manager, Worldwide DB2 Sales Support | (+1)
>905-413-2798 |  T/L 969-2798 | [EMAIL PROTECTED]
>
>
>   
> "Daniel John  
> Debrunner (JIRA)" 
> <[EMAIL PROTECTED]  To 
> che.org>  George Baklarz/Toronto/[EMAIL 
> PROTECTED]
>cc 
> 03/10/2005 09:11  
> PMSubject 
>   [jira] Commented: (DERBY-172)   
>   Trigger activation  
>   
>   
>   
>   
>   
>   
>
>
>
>
> [
>http://issues.apache.org/jira/browse/DERBY-172?page=comments#action_60634 ]
>
>Daniel John Debrunner commented on DERBY-172:
>-
>
>BEFORE triggers do work but they have the restriction that the trigger
>action must be read-only, that is a SELECT statement or a VALUES claues.
>The action statement can call a user defined Java function that could send
>e-mail or perform validation.
>
>Enabling the before triggers was last minute item before the code was
>contributed.
>
>  
>
>>Trigger activation
>>--
>>
>> Key: DERBY-172
>> URL: http://issues.apache.org/jira/browse/DERBY-172
>> Project: Derby
>>Type: Bug
>>  Components: Documentation
>>Versions: 10.0.2.0
>> Environment: Windows XP SP1 Windows
>>Reporter: George Baklarz
>>Priority: Minor
>>
>>
>
>  
>
>>I image that this is a documentation problem. The "words" around triggers
>>
>>
>seem to imply the ability to do actions "BEFORE" the INSERT/UPDATE/DELETE.
>For instance:
>  
>
>>"Along with constraints, triggers can help enforce data integrity rules
>>
>>
>with actions such as cascading deletes or updates. Triggers can also
>perform a variety of functions such as issuing alerts, updating other
>tables, sending e-mail, and other useful actions."
>  
>
>>Well, the CREATE TRIGGER command only allows AFTER as an option (even
>>
>>
>though the SYSTRIGGERS catalog uses "B" for before and "A" for after) and
>it won't allow a CALL statement to be processed. Seems to me that there
>aren't any ways to send an e-mail, issue alerts (no SIGNAL function
>either), or enforce integrity rules. How can you enforce integrity rules if
>invalid data comes in? I can't force a SIGNAL or error with the trigger, so
>this is useless for validating changes to the data.
>  
>
>>In addition, there appears to be some logic regarding BEFORE triggers in
>>
>>
>Derby, but its not currently working.
>  
>
>>CREATE TRIGGER CB NO CASCADE BEFORE
>>   INSERT ON BONUSES
>>  REFERENCING NEW AS n
>>  FOR EACH ROW MODE DB2SQL
>>  UPDATE BONUSES
>> SET BONUS =
>> CASE
>>WHEN (n.BONUS = 0) THEN 100
>>ELSE n.BONUS
>> END;
>>ERROR 42Z9D: 'UPDATE' statements are not allowed in 'BEFORE' triggers.
>>
>>
>
>--
>This message is automatically generated by JIR

Re: About improvement of DERBY-134

Hi Tomohito Nakayama,
(B
(BJust wanted to check how you are progressing on the patch update,
(Bfollowing comments by myself and Jack. I do think you are working on an
(Bimportant enhancement that not only yourself but other developpers have
(Bexpressed interest in. I strongly encourage you to continue working on
(Bthis and post any questions or comments you might have. You are pretty
(Bclose to addressing all issues.
(B
(BI am willing to help, if you need any, to continue taking this further.
(B
(BSatheesh
(B
(BTomohitoNakayama wrote:
(B
(B> Hello.
(B> Thanks for your reviewing.
(B>
(B> About 1:
(B> Handling any sortKey as expression is better structure.
(B> A little challenging but worth for it.
(B> I will try.
(B>
(B> About 2:
(B> Uh oh.
(B> Bug about starting value of element indexing in ResultColumnList 
(B> Test of comma separated lists of ORDER BY expressions in orderby.sql
(B> was needed.
(B>
(B> About 3:
(B> I see.
(B> It seems that it is certainly needed to add test case .
(B>
(B> I will continue this issue.
(B> Best regards.
(B>
(B> /*
(B>
(B> Tomohito Nakayama
(B> [EMAIL PROTECTED]
(B> [EMAIL PROTECTED]
(B>
(B> Naka
(B> http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B>
(B> */
(B> - Original Message - From: "Jack Klebanoff"
(B> <[EMAIL PROTECTED]>
(B> To: "Derby Development" 
(B> Sent: Sunday, February 20, 2005 8:37 AM
(B> Subject: Re: About improvement of DERBY-134
(B>
(B>
(B>> TomohitoNakayama wrote:
(B>>
(B>>> Hello.
(B>>>
(B>>> I have put some LOOKAHEAD to sqlgrammer.jj and
(B>>> add some test pattern to orderby.sql.
(B>>>
(B>>> Would someone review patch please ?
(B>>>
(B>>> Best regards.
(B>>>
(B>>> /*
(B>>>
(B>>> Tomohito Nakayama
(B>>> [EMAIL PROTECTED]
(B>>> [EMAIL PROTECTED]
(B>>>
(B>>> Naka
(B>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B>>>
(B>>> */
(B>>> - Original Message - From: "TomohitoNakayama"
(B>>> <[EMAIL PROTECTED]>
(B>>> To: "Derby Development" 
(B>>> Sent: Sunday, February 13, 2005 4:09 PM
(B>>> Subject: Re: About improvement of DERBY-134
(B>>>
(B>>>
(B>>>> Sorry.
(B>>>> Mistaken.
(B>>>>
(B>>>> LOOKAHEAD()
(B>>>>
(B>>>> /*
(B>>>>
(B>>>> Tomohito Nakayama
(B>>>> [EMAIL PROTECTED]
(B>>>> [EMAIL PROTECTED]
(B>>>>
(B>>>> Naka
(B>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B>>>>
(B>>>> */
(B>>>> - Original Message - From: "TomohitoNakayama"
(B>>>> <[EMAIL PROTECTED]>
(B>>>> To: "Derby Development" 
(B>>>> Sent: Sunday, February 13, 2005 3:42 PM
(B>>>> Subject: Re: About improvement of DERBY-134
(B>>>>
(B>>>>
(B>>>>> Hello.
(B>>>>>
(B>>>>> Thank's for your reviewing.
(B>>>>> Grammer ambiguity is very critical problem 
(B>>>>>
(B>>>>> I will try to put LOOKUP() and consider about testing..
(B>>>>>
(B>>>>> #World is not simple as I wish to be.
(B>>>>>
(B>>>>> Best regards.
(B>>>>>
(B>>>>> /*
(B>>>>>
(B>>>>> Tomohito Nakayama
(B>>>>> [EMAIL PROTECTED]
(B>>>>> [EMAIL PROTECTED]
(B>>>>>
(B>>>>> Naka
(B>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B>>>>>
(B>>>>> */
(B>>>>> - Original Message - From: Satheesh Bandaram
(B>>>>> To: Derby Development
(B>>>>> Sent: Saturday, February 12, 2005 4:10 AM
(B>>>>> Subject: Re: About improvement of DERBY-134
(B>>>>>
(B>>>>>
(B>>>>> I think the patch is a good start. But more work needs to be done.
(B>>>>> Based on a quick review, some of the items to be completed are:
(B>>>>> (there may be more)
(B>>>>>
(B>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch
(B>>>>> is written. Since orderby expression and orderby column can both
(B>>>>> start with an identifier, this causes ambiguity. Need to rewrite or
(B>>>>&g

Re: [jira] Commented: (DERBY-147) ERROR 42X79 not consistant ? - same column name specified twice





Hi Bernd,

Just following up to check how your patch making is comming along. You
already have the code change and you wanted to attempt to make a patch.
Let me know if you are stuck or need more assistance.

If changing test suites to add test cases seem daunting, let me know.
For this case, I am willing to work with you to add required testing
support.

Satheesh

Bernd Ruehlicke (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/DERBY-147?page=comments#action_59875 ]
 
Bernd Ruehlicke commented on DERBY-147:
---

Ok I made the changes and build Derby - and tested it - seams to work.

We may consider to make this change permanent. 

Any reason for this error log was added ?

Here the code snipled (need to chnage getOrderBy(String, String) and getOrderBy(String, String, int)

...
			if (columnName.equals( resultColumn.getName()) )
			{
if (retVal == null)
{
	retVal = resultColumn;
}
//	DERBY-147else if (index < size - orderBySelect)
//	DERBY-147{
//	DERBY-147	throw StandardException.newException(SQLState.LANG_DUPLICATE_COLUMN_FOR_ORDER_BY, columnName);
//	DERBY-147}
else
{// remove the column due to pullup of orderby item
	removeElement(resultColumn);
	decOrderBySelect();
	break;
}
			}
...


By the way - if already at the code - and since the code is more or less the same  would be handy to refactor the getOrderBy(String, String) to 

getOrderBy(String, String)
{
   return getOrderBy(String, String, null);
}

and handle "null" in the String, String, int method.


B-)

  
  
ERROR 42X79 not consistant ? - same column name specified twice
---

 Key: DERBY-147
 URL: http://issues.apache.org/jira/browse/DERBY-147
 Project: Derby
Type: Bug
Reporter: Bernd Ruehlicke

  
  
  
  
This happens from JDBC or ij. Here the output form ij>
ij version 10.0 
CONNECTION0* - 	jdbc:derby:phsDB 
* = current connection 
ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1 ORDER BY a1.XXX_foreign;
ERROR 42X79: Column name 'XXX_FOREIGN' appears more than once in the result of the query _expression_. 
But when removing the ORDER BY and keeping the 2 same column names it works
ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1;
XXX_FOREIGN |NATIVE  |KIND|XXX_FOREIGN  ---  
0 rows selected 
ij> 
So - it seams to be OK to specify the same column twice - as long as you do not add the ORDER BY clause.  
I woul dof course like that the system allows this - but at leats it should be consistant and either allow both or none of the two queries above.

Re: About improvement of DERBY-134

I agree with Jeremy Boynes view that order by number should only
(Brecognise simple numbers. I personnally think he has already provided a
(Bgood argument for that. If no one objects, I think the patch can proceed
(Bassuming a simple number for order by.
(B
(BSatheesh
(B
(BTomohitoNakayama wrote:
(B
(B> Hello.
(B>
(B> Sorry for my silence.
(B> I was in a little private trouble in these weeks.
(B>
(B> About for DERBY-134, I was at a loss how to treat column referenced by
(B> number.
(B>
(B> In point of view for implementation,
(B> it seem to be difficult to treat expression except for simple number
(B> as reference by number.
(B> I couldn't get value by getConstantValueAsObject() of BinaryOperatorNode.
(B>
(B> In point of view for specification, there exists topic which was
(B> written in mail of Jeremy Boynes .
(B> In addition to that, reference by number in order clause seems to be
(B> not recommended spec of SQL .
(B>
(B> I wonder allowing only simple number as reference to column may be
(B> reasonable spec.
(B>
(B> Best regards.
(B>
(B> /*
(B>
(B> Tomohito Nakayama
(B> [EMAIL PROTECTED]
(B> [EMAIL PROTECTED]
(B>
(B> Naka
(B> http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B>
(B> */
(B> - Original Message - From: "Satheesh Bandaram"
(B> <[EMAIL PROTECTED]>
(B> To: "Derby Development" 
(B> Sent: Saturday, March 12, 2005 6:59 AM
(B> Subject: Re: About improvement of DERBY-134
(B>
(B>
(B>> Hi Tomohito Nakayama,
(B>>
(B>> Just wanted to check how you are progressing on the patch update,
(B>> following comments by myself and Jack. I do think you are working on an
(B>> important enhancement that not only yourself but other developpers have
(B>> expressed interest in. I strongly encourage you to continue working on
(B>> this and post any questions or comments you might have. You are pretty
(B>> close to addressing all issues.
(B>>
(B>> I am willing to help, if you need any, to continue taking this further.
(B>>
(B>> Satheesh
(B>>
(B>> TomohitoNakayama wrote:
(B>>
(B>>> Hello.
(B>>> Thanks for your reviewing.
(B>>>
(B>>> About 1:
(B>>> Handling any sortKey as expression is better structure.
(B>>> A little challenging but worth for it.
(B>>> I will try.
(B>>>
(B>>> About 2:
(B>>> Uh oh.
(B>>> Bug about starting value of element indexing in ResultColumnList 
(B>>> Test of comma separated lists of ORDER BY expressions in orderby.sql
(B>>> was needed.
(B>>>
(B>>> About 3:
(B>>> I see.
(B>>> It seems that it is certainly needed to add test case .
(B>>>
(B>>> I will continue this issue.
(B>>> Best regards.
(B>>>
(B>>> /*
(B>>>
(B>>> Tomohito Nakayama
(B>>> [EMAIL PROTECTED]
(B>>> [EMAIL PROTECTED]
(B>>>
(B>>> Naka
(B>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B>>>
(B>>> */
(B>>> - Original Message - From: "Jack Klebanoff"
(B>>> <[EMAIL PROTECTED]>
(B>>> To: "Derby Development" 
(B>>> Sent: Sunday, February 20, 2005 8:37 AM
(B>>> Subject: Re: About improvement of DERBY-134
(B>>>
(B>>>
(B>>>> TomohitoNakayama wrote:
(B>>>>
(B>>>>> Hello.
(B>>>>>
(B>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and
(B>>>>> add some test pattern to orderby.sql.
(B>>>>>
(B>>>>> Would someone review patch please ?
(B>>>>>
(B>>>>> Best regards.
(B>>>>>
(B>>>>> /*
(B>>>>>
(B>>>>> Tomohito Nakayama
(B>>>>> [EMAIL PROTECTED]
(B>>>>> [EMAIL PROTECTED]
(B>>>>>
(B>>>>> Naka
(B>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B>>>>>
(B>>>>> */
(B>>>>> - Original Message - From: "TomohitoNakayama"
(B>>>>> <[EMAIL PROTECTED]>
(B>>>>> To: "Derby Development" 
(B>>>>> Sent: Sunday, February 13, 2005 4:09 PM
(B>>>>> Subject: Re: About improvement of DERBY-134
(B>>>>>
(B>>>>>
(B>>>>>> Sorry.
(B>>>>>> Mistaken.
(B>>>>>>
(B>>>>>> LOOKAHEAD()
(B>>>>>>
(B>>&g

Re: About improvement of DERBY-134

2005-03-12 Thread Satheesh Bandaram

Also, if we disallow C1/C1, how about (C1+C2)/(C2+C1)? Same question for
(C1+C1)/2*C1. How intelligent do we need to make this thing? I still
vote for the simplest approach, proposed by Jeremy. I also tried this on
DB2 that I have access to. This what is proposed by Tomohito and Jeremy
matches that behaviour.

Satheesh

db2 => select * from t
I   J
--- ---
  1   1
  2   2
  0   4
  5   0
db2 => select * from t order by 1+1
I   J
--- ---
  1   1
  2   2
  0   4
  5   0
db2 => select * from t order by 2
I   J
--- ---
  5   0
  1   1
  2   2
  0   4
Jeremy Boynes wrote:

> Daniel John Debrunner wrote:
>
>>
>  > If it made it clearer I would prefer that a compilation error is
> raised
>
>> for order by expressions that do resolve to constants, since supporting
>> them adds no value. How this error would be raised I'm not sure about.
>>
>> ORDER BY 1 - ok (column position 1)
>> ORDER BY C1 - ok
>> ORDER BY FN(C1) - ok
>> ORDER BY 1 + 1 - disallow
>> ORDER BY C1/C1 - disallow
>>
>
> The spec says that the sort keys are value expressions which would
> make both "ORDER BY 1+1" and "ORDER BY C1/C1" valid SQL so we can't
> raise an error.
>
> In both cases the result is implementation dependent as the key will
> be the same for all rows. I think /choosing/ to define the result when
> the value expression is a simple integer literal is useful so we can
> support the "ORDER BY 1,2" syntax common on other platforms; I believe
> anything more complex than that is going to be confusing.
>
> This may make the parser more complex, but that's a development issue
> not a user one :-)
>
> -- 
> Jeremy
>
>

Re: About improvement of DERBY-134

2005-03-13 Thread Satheesh Bandaram





I think new behavior is a bug... and should be addressed in the patch.
Since there is no column name called 'SQLCol1' in the user querry,
accepting an order by with that name is incorrect. Column names like
these are generated names when there is no exposed name or alias
provided for the result columns. Derby generates these names and should
be hidden to the end user.

It should be easy to address this. You probably need to mark any new
expressions you are adding as generated columns using
setNameGenerated(true) call.

Satheesh

TomohitoNakayama wrote:
Hello.
  
  
I tried to change handling single column name in order by clause , and
just finished coding.
  
Now single column name is treated as additiveExpression in afterPatch.
  
  
And I have found next difference in orderby.out between beforePatch and
afterPatch as follows.
  
I 'm confusing whether I should judge this is bug or not.
  
  
beforePatch
  
ij> -- . order by doesn't see generated names
  
values (1,0,1),(1,0,0),(0,0,1),(0,1,0);
  
1  |2  |3
  
---
  
1  |0  |1
  
1  |0  |0
  
0  |0  |1
  
0  |1  |0
  
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1";
  
ERROR 42X78: Column 'SQLCol1' is not in the result of the query
_expression_.
  
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2";
  
ERROR 42X78: Column 'SQLCol2' is not in the result of the query
_expression_.
  
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3;
  
1  |2  |3
  
---
  
0  |0  |1
  
0  |1  |0
  
1  |0  |0
  
1  |0  |1
  
  
afterPatch
  
ij> -- . order by doesn't see generated names ?
  
values (1,0,1),(1,0,0),(0,0,1),(0,1,0);
  
1  |2  |3
  
---
  
1  |0  |1
  
1  |0  |0
  
0  |0  |1
  
0  |1  |0
  
  -- now next was accepted.

  
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1";
  
1  |2  |3
  
---
  
0  |1  |0
  
0  |0  |1
  
1  |0  |0
  
1  |0  |1
  
  -- now next was accepted too.

  
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2";
  
1  |2  |3
  
---
  
0  |0  |1
  
1  |0  |0
  
1  |0  |1
  
0  |1  |0
  
ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3;
  
1  |2  |3
  
---
  
0  |0  |1
  
0  |1  |0
  
1  |0  |0
  
1  |0  |1
  
  
I have some question now.
  
  
Q1:
  
What is  "generated names" ?
  
<"> "SQLCol NUMBER" <"> seems to be called "generated
names".
  
  
Q2:
  
Why was it error to use "generated name" in order by caluse as seen in
beforePatch?
  
  
Q3:
  
Is it bug to accept "generated names" in order clause like as in
afterPatcch ?
  
  
Please give me some adivise...
  
  
Best regards.
  
  
/*
  
  
    Tomohito Nakayama
  
    [EMAIL PROTECTED]
  
    [EMAIL PROTECTED]
  
  
    Naka
  
    http://www5.ocn.ne.jp/~tomohito/TopPage.html
  
  
*/

Re: About improvement of DERBY-134

2005-03-13 Thread Satheesh Bandaram

Derby actually generates two different names... 1) Unique name for
unnamed references 2) Final exposed names for top level unnamed result
columns. The unique names are of the form 'SQLCol' and final
exposed names, that IJ shows, are of the form ''. The number
part of the names could be different. (Eg: 'SQLCol5' may map to '1' as
exposed name)

The SQLCol unique names can't be guessed correctly by end users. It may
change depending on how the query is compiled and can change totally
unexpectedly.(Like adding an extra union at the end of the query could
change top level result column names) So these are definitely not
suitable to be used by end users. It may be possible to use final
exposed names (like '1', '2') in order by clause, but Derby currently
doesn't allow it. It is not consistant to allow this only under some new
code path, as a side effect. We have to consistantly change it all over.
I don't know what the SQL standard says about this... I don't want to
look at that huge spec on a Sunday. :-)

I am not sure we should, even if we could... Like you said, these
numbers are implementation dependent, change from one vendor to another
and may even change from one release to another.  Shouldn't querries
instead use explicit aliasing to avoid all confusion, which is standards
based and portable?

Satheesh

Jeremy Boynes wrote

> I'm not so sure - I thought expressions were given implementation
> dependent names that could be referenced in a sort key. In our case
> the name is "SQLCol1" so referencing that would be valid but
> non-portable.
>
> I'm curious why ij is not labeling the columns that way and whether it
> should.
>
> -- 
> Jeremy

Re: About improvement of DERBY-134

2005-03-14 Thread Satheesh Bandaram





Not sure what you mean by the case where you are using VALUES to
construct a table,  Derby does allow naming those columns.

ij> values (1,1,1), (2,2,2);
1  |2  |3
---
1  |1  |1
2  |2  |2
ij> select * from (values (1,1,1), (2,2,2)) as t(i,j,k) order by i
desc;
I  |J  |K
---
2  |2  |2
1  |1  |1

Aren't these symantically the same?

Satheesh

Jeremy Boynes wrote:
Yes they
should. Unfortunately that is not always possible and I think the
case where you are using VALUES to construct a table is one of those.
In other words, Tomohito's test is reliant on implementation dependent
behaviour.
  
  
The spec does say that alias names are generated and so it should be
possible to reference them even if doing so is non-portable. Personally
I would prefer the  form because it is at least a legal
identifier; using <1> would mean having to quote the reference
which seems inconvenient and confusing e.g. ORDER BY "1"
  
  
Whatever the outcome I do think we need to document how the names are
generated so a user can figure it out.
  
  
--
  
Jeremy

Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs

2005-03-14 Thread Satheesh Bandaram

Oops... sorry. I didn't realize you were addressing those as a different
patch... I will get to it in a day or two.

Army tried to apply the patch, but it failed... Not sure why.. Should we
try to merge your changes with latest and generate a new patch? You have
to merge in anycase...right?

Satheesh

Mamta Satoor wrote:

>Hi Satheesh,
>
>I wondered if you got a chance to submit the patch I submitted couple
>weeks back. As per Dan's earlier post, the couple issues that are left
>on this feature can be sent as a separate patch. So, I will appreciate
>if you can submit the current patch for me.
>
>thanks,
>Mamta
>

Re: About improvement of DERBY-134


(B
(B
(B
(BSince you are working on an enhancement to Derby, you need to sign a
(BCLA with Apache.
(B
(BJean, is this the right CLA?
(Bhttp://www.apache.org/~tetsuya/db/agreement.html
(B
(BSatheesh
(B
(BTomohitoNakayama wrote:
(BHello.
(B  
(B  
(BI have finished coding and testing in orderby.sql.
(B  
(BI'm not sure test is enough.
(B  
(B  
(BWould you please review it ?
(B  
(B  
(BBest regards.
(B  
(B  
(B/*
(B  
(B  
(B    Tomohito Nakayama
(B  
(B    [EMAIL PROTECTED]
(B  
(B    [EMAIL PROTECTED]
(B  
(B  
(B    Naka
(B  
(B    http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B  
(B  
(B*/
(B  
(B- Original Message - From: "Satheesh Bandaram"
(B<[EMAIL PROTECTED]>
(B  
(BTo: "Derby Development" 
(B  
(BSent: Saturday, March 12, 2005 6:59 AM
(B  
(BSubject: Re: About improvement of DERBY-134
(B  
(B  
(B  
(B  Hi Tomohito Nakayama,
(B
(B
(BJust wanted to check how you are progressing on the patch update,
(B
(Bfollowing comments by myself and Jack. I do think you are working on an
(B
(Bimportant enhancement that not only yourself but other developpers have
(B
(Bexpressed interest in. I strongly encourage you to continue working on
(B
(Bthis and post any questions or comments you might have. You are pretty
(B
(Bclose to addressing all issues.
(B
(B
(BI am willing to help, if you need any, to continue taking this further.
(B
(B
(BSatheesh
(B
(B
(BTomohitoNakayama wrote:
(B
(B
(BHello.
(B  
(BThanks for your reviewing.
(B  
(B  
(BAbout 1:
(B  
(BHandling any sortKey as _expression_ is better structure.
(B  
(BA little challenging but worth for it.
(B  
(BI will try.
(B  
(B  
(BAbout 2:
(B  
(BUh oh.
(B  
(BBug about starting value of element indexing in ResultColumnList 
(B  
(BTest of comma separated lists of ORDER BY expressions in orderby.sql
(B  
(Bwas needed.
(B  
(B  
(BAbout 3:
(B  
(BI see.
(B  
(BIt seems that it is certainly needed to add test case .
(B  
(B  
(BI will continue this issue.
(B  
(BBest regards.
(B  
(B  
(B/*
(B  
(B  
(BTomohito Nakayama
(B  
(B[EMAIL PROTECTED]
(B  
(B[EMAIL PROTECTED]
(B  
(B  
(BNaka
(B  
(Bhttp://www5.ocn.ne.jp/~tomohito/TopPage.html
(B  
(B  
(B*/
(B  
(B- Original Message - From: "Jack Klebanoff"
(B  
(B<[EMAIL PROTECTED]>
(B  
(BTo: "Derby Development" 
(B  
(BSent: Sunday, February 20, 2005 8:37 AM
(B  
(BSubject: Re: About improvement of DERBY-134
(B  
(B  
(B  
(B  TomohitoNakayama wrote:
(B
(B
(BHello.
(B  
(B  
(BI have put some LOOKAHEAD to sqlgrammer.jj and
(B  
(Badd some test pattern to orderby.sql.
(B  
(B  
(BWould someone review patch please ?
(B  
(B  
(BBest regards.
(B  
(B  
(B/*
(B  
(B  
(BTomohito Nakayama
(B  
(B[EMAIL PROTECTED]
(B  
(B[EMAIL PROTECTED]
(B  
(B  
(BNaka
(B  
(Bhttp://www5.ocn.ne.jp/~tomohito/TopPage.html
(B  
(B  
(B*/
(B  
(B- Original Message - From: "TomohitoNakayama"
(B  
(B<[EMAIL PROTECTED]>
(B  
(BTo: "Derby Development" 
(B  
(BSent: Sunday, February 13, 2005 4:09 PM
(B  
(BSubject: Re: About improvement of DERBY-134
(B  
(B  
(B  
(B  Sorry.
(B
(BMistaken.
(B
(B
(BLOOKAHEAD()
(B
(B
(B/*
(B
(B
(BTomohito Nakayama
(B
(B[EMAIL PROTECTED]
(B
(B[EMAIL PROTECTED]
(B
(B
(BNaka
(B
(Bhttp://www5.ocn.ne.jp/~tomohito/TopPage.html
(B
(B
(B*/
(B
(B- Original Message - From: "TomohitoNakayama"
(B
(B<[EMAIL PROTECTED]>
(B
(BTo: "Derby Development" 
(B
(BSent: Sunday, February 13, 2005 3:42 PM
(B
(BSubject: Re: About improvement of DERBY-134
(B
(B
(B
(BHello.
(B  
(B  
(BThank's for your reviewing.
(B  
(BGrammer ambiguity is very critical problem 
(B  
(B  
(BI will try to put LOOKUP() and consider about testing..
(B  
(B  
(B#World is not simple as I wish to be.
(B  
(B  
(BBest regards.
(B  
(B  
(B/*
(B  
(B  
(BTom

Re: About improvement of DERBY-134





I am still new to Apache processes. According to the following DB
project guidelines,  "All contributors should have a Contributor License
Agreement on file." I know bug patches are exempt from this
requirement.

http://db.apache.org/source.html

Satheesh

Jeremy Boynes wrote:
Satheesh
Bandaram wrote:
  
  Since you are working on an enhancement to
Derby, you need to sign a CLA with Apache.


  
  
A CLA is usually only required when someone becomes a committer. There
is a flag in Jira which indicates whether code attached to issues is
licensed to the ASF; patches submitted to the list are public
contributions.
  
  
--
  
Jeremy

Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs





+1. I think Dan has already voted on this. We need another +1 vote
before I can commit.

Mamta Satoor wrote:

  On Mon, 14 Mar 2005 13:03:46 -0800, Mamta Satoor <[EMAIL PROTECTED]> wrote:
  
  
On Mon, 14 Mar 2005 12:35:02 -0800, Satheesh Bandaram
<[EMAIL PROTECTED]> wrote:


  Oops... sorry. I didn't realize you were addressing those as a different
patch... I will get to it in a day or two.

Army tried to apply the patch, but it failed... Not sure why.. Should we
try to merge your changes with latest and generate a new patch? You have
to merge in anycase...right?

Satheesh

Mamta Satoor wrote:

  
  
Hi Satheesh,

I wondered if you got a chance to submit the patch I submitted couple
weeks back. As per Dan's earlier post, the couple issues that are left
on this feature can be sent as a separate patch. So, I will appreciate
if you can submit the current patch for me.

thanks,
Mamta


  
  
  

OK, I will work on merging and generating a new patch.

Mamta

Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs





Submitted this patch. I think Mamta already voted +1, so we are good!

Satheesh
Sending    java\engine\org\apache\derby\iapi\reference\SQLState.java
Sending    java\engine\org\apache\derby\iapi\types\SQLClob.java
Sending   
java\engine\org\apache\derby\impl\jdbc\EmbedDatabaseMetaData.java
Sending   
java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
Sending   
java\engine\org\apache\derby\impl\jdbc\EmbedResultSet20.java
Sending    java\engine\org\apache\derby\loc\messages_en.properties
Adding
java\testing\org\apache\derbyTesting\functionTests\master\jdk14
Adding
java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\parameterMapping.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\resultsetJdbc30.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultsetJdbc30.java
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\build.xml
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
Transmitting file data .
Committed revision 157592.

Satheesh Bandaram wrote:

  
  
+1. I think Dan has already voted on this. We need another +1 vote
before I can commit.
  
Mamta Satoor wrote:
  
On Mon, 14 Mar 2005 13:03:46 -0800, Mamta Satoor <[EMAIL PROTECTED]> wrote:
  

  On Mon, 14 Mar 2005 12:35:02 -0800, Satheesh Bandaram
<[EMAIL PROTECTED]> wrote:

  
Oops... sorry. I didn't realize you were addressing those as a different
patch... I will get to it in a day or two.

Army tried to apply the patch, but it failed... Not sure why.. Should we
try to merge your changes with latest and generate a new patch? You have
to merge in anycase...right?

Satheesh

Mamta Satoor wrote:

  

  Hi Satheesh,

I wondered if you got a chance to submit the patch I submitted couple
weeks back. As per Dan's earlier post, the couple issues that are left
on this feature can be sent as a separate patch. So, I will appreciate
if you can submit the current patch for me.

thanks,
Mamta



  
  
  OK, I will work on merging and generating a new patch.

Mamta

Re: LIMIT with Select Statement

2005-03-16 Thread Satheesh Bandaram





Derby allows limiting the number of rows returned by a query using
JDBC. You can use java.sql.Statement.setMaxRows() method.


Satheesh

Devang wrote:

  
  
  
  
  

  
  
  Hi
   
  Is it possible to use  “LIMIT”  keyword with
select statement?
  Or is there any other
alternative for the same?
   
  Thanx
   
  Devang

Re: [PATCH] Derby-174

2005-03-23 Thread Satheesh Bandaram

I will submit your patches after your changes.

Satheesh

Shreyas Kaushik wrote:

> I guess this is an IDE trick , I'll change this.
>
> ~ Shreyas
>
> Army wrote:
>
>> <[EMAIL PROTECTED]> wrote
>>
>>>
>>> -import java.sql.Date;
>>> -import java.sql.Time;
>>> -import java.sql.Timestamp;
>>> -import java.sql.Types;
>>> -import java.sql.ResultSet;
>>> -import java.sql.SQLException;
>>> +import java.sql.*;
>>
>>
>>
>> I apologize if this is overly picky, but isn't inclusion of a package
>> via the "*" wildcard generally considered an unfavorable programming
>> practice?  I think it's fine to do so when writing tests, but as far
>> as I know, the Derby codeline generally avoids using wildcard
>> imports.  And even if there are existing places where such imports
>> are used, it seems to me that _replacing_ existing imports with the
>> wildcard import is probably not a habit to encourage.
>>
>> Even if functionally speaking there's no difference, to do this is to
>> introduce a style of imports that's doesn't agree with the rest of
>> the codeline--is that something to avoid?
>>
>> 'Course, maybe that's just unfounded paranoia on my part...
>>
>> *shrug*
>> Army
>>
>
>
>

Re: [PATCH]Enabling negative test for scroll sensitive updatable resultset in Network Server mode

2005-03-23 Thread Satheesh Bandaram





Submitted this patch.

Satheesh

Sending   
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
Transmitting file data .
Committed revision 158821.

Mamta Satoor wrote:

  Hi,

Derby does not support scroll sensitive updatable resultsets. There is
already a test for this in embedded mode. Enabling the same test for
Network Server. The new Derby Net Client driver will correctly
downgrade the resultset type to scroll insensitive read only
resultset. JCC driver does not do that and there is already a JIRA
entry 154 for it.

svn stat
M  java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableRe
sultSet.java
M  java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updata
bleResultSet.out
M  java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\
updatableResultSet.out
M  java\testing\org\apache\derbyTesting\functionTests\master\updatableResult
Set.out
M  java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatable
ResultSet.out

thanks,
Mamta
  
  

Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java
===
--- java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java	(revision 158774)
+++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java	(working copy)
@@ -247,7 +247,6 @@
 			//have to close the resultset because by default, resultsets are held open over commit
 			rs.close();
 
-			if (TestUtil.isEmbeddedFramework()) {
 			System.out.println("Negative Test2 - request for scroll sensitive updatable resultset will give a read only scroll insensitive resultset");
 			stmt = conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE);
 			while (warnings != null)
@@ -257,6 +256,7 @@
 			}
 			conn.clearWarnings();
   System.out.println("requested TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE but that is not supported");
+			System.out.println("Jira issue Derby-154 : When client connects to Network Server using JCC, it incorrectly shows support for scroll sensitive updatable resultsets"); 
   System.out.println("Make sure that we got TYPE_SCROLL_INSENSITIVE? " +  (stmt.getResultSetType() == ResultSet.TYPE_SCROLL_INSENSITIVE));
   System.out.println("Make sure that we got CONCUR_READ_ONLY? " +  (stmt.getResultSetConcurrency() == ResultSet.CONCUR_READ_ONLY));
 			System.out.println("JDBC 2.0 updatable resultset api will fail on this resultset because this is not an updatable resultset");
@@ -281,7 +281,6 @@
 			rs.next();
 			//have to close the resultset because by default, resultsets are held open over commit
 			rs.close();
-			}
 
 			System.out.println("Negative Test3 - request a read only resultset and attempt deleteRow and updateRow on it");
 			stmt = conn.createStatement();//the default is a read only forward only resultset
Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out
===
--- java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out	(revision 158774)
+++ java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out	(working copy)
@@ -12,6 +12,16 @@
 Got expected exception This method cannot be invoked while the cursor is on the insert row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY.
 SQL State : null
 Got expected exception This method cannot be invoked while the cursor is on the insert row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY.
+Negative Test2 - request for scroll sensitive updatable resultset will give a read only scroll insensitive resultset
+requested TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE but that is not supported
+Jira issue Derby-154 : When client connects to Network Server using JCC, it incorrectly shows support for scroll sensitive updatable resultsets
+Make sure that we got TYPE_SCROLL_INSENSITIVE? false
+Make sure that we got CONCUR_READ_ONLY? false
+JDBC 2.0 updatable resultset api will fail on this resultset because this is not an updatable resultset
+SQL State : null
+Got expected exception This method cannot be invoked while the cursor is on the insert row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY.
+SQL State : null
+Got expected exception This method cannot be invoked while the cursor is on the insert row or if the concurre

Re: [jira] Commented: (DERBY-147) ERROR 42X79 not consistant ? - same column name specified twice





I think we should to enumerate all cases that cause ambiguity. Some are
possibly OK(multiple references to same column), some should raise
error(cases where there is an explicit alias). There is a need to also
check what SQL standard says here. Here are some of the queries
and what DB2 does with those, though we should follow SQL guidance for
Derby.

db2> select i, i from t order by i
I   I
--- ---
  0   0
  1   1
  2   2
db2> select i, j as i from t order by i
I   I
--- ---
  0   4
  1   1
  2   2
db2> select i as A, j as A from t order by A  <== Explicit
alias. Error.
Error.

Satheesh

Jack Klebanoff wrote:
It is
not so simple. The order by specification may be ambiguous. Derby
allows the following:
  
 select t.c1 as a, t.c2 as a from t
  
What should we do if you add "order by a" to the above select? "a" is
truly ambiguous.
  
  
I can think of several alternatives:
  
1. Prohibit duplicate select list column names, whether or not there is
an order by clause.
  
2. Change ORDER BY processing. When it finds an ambiguous column name
check whether all the columns with that name are really the same. Allow
the ORDER BY if so. Remember that Tomohito Nakayama is working on
allowing general expressions in the ORDER BY clause, so this is not so
easy.
  
3. Change ORDER BY processing. When it finds an ambiguous column name
check whether the sort key names a column in an underlying table (not a
correlation name). Allow the ORDER BY if so. Throw an SQLException if
not, even if all the possible columns have the same value. This fixes
the case in the bug report.
  
4. Keep the error checking as is but improve the error message.
Something like "ORDER BY column 'xx' is ambiguous".
  
5. Do nothing.
  
  
Jack Klebanoff
  
Diljeet Dhillon (JIRA) wrote:
  
  
      [
http://issues.apache.org/jira/browse/DERBY-147?page=comments#action_61483
]

    Diljeet Dhillon commented on DERBY-147:

---


Hi,

Have we established whether a possible patch/fix will be provided for
this issue. and what the possible timescales may be?





 


ERROR 42X79 not consistant ? - same column
name specified twice
  
---
  
  
    Key: DERBY-147
  
    URL: http://issues.apache.org/jira/browse/DERBY-147
  
    Project: Derby
  
   Type: Bug
  
   Reporter: Bernd Ruehlicke
  
   


 


This happens from JDBC or ij. Here the
output form ij>
  
ij version 10.0 CONNECTION0* - jdbc:derby:phsDB * = current
connection ij> select a1.XXX_foreign, a1.native, a1.kind,
a1.XXX_foreign FROM slg_name_lookup a1 ORDER BY a1.XXX_foreign;
  
ERROR 42X79: Column name 'XXX_FOREIGN' appears more than once in the
result of the query _expression_. But when removing the ORDER BY and
keeping the 2 same column names it works
  
ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM
slg_name_lookup a1;
  
XXX_FOREIGN
|NATIVE 
|KIND   
|XXX_FOREIGN 
--- 
0 rows selected ij> So - it seams to be OK to specify the same
column twice - as long as you do not add the ORDER BY clause.  I woul
dof course like that the system allows this - but at leats it should be
consistant and either allow both or none of the two queries above.

Re: Adding framework scripts to bundle

I also think they are useful. Some of these scripts are present in the
derby source download, though they could be improved. It would be nice
to be able to start Derby Network server as a service in Windows, for
example. Any volunteers? :-)

Satheesh

Amit Handa wrote:

> Hi,
>
> Can we add framework scripts like startNetworkto bundle available for
> download ?
>
> The bundles only packages the  derby jars, adding these scripts can be
> a useful thing for developers.
>
> Is there a plan to do so ?
>
> thanks,
> Amit
>
>
>

Re: [Fwd: [PATCH] Derby-157 Patch, plus 2 other minor server fixes.]





Thanks for the reminder. I have submitted this patch. I am wondering if
previously failing test cases should be added to Network server tests.

Satheesh 

Sending    java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
Transmitting file data .
Committed revision 158935.

Army wrote:
Committers,
  
  
I submitted this rather simple patch three weeks ago, but it looks like
it fell through the cracks.  I'm re-attaching a
  
newly created version of the patch (against the most recent codeline).
  
  
This is a fix for DERBY-157.  I ran the derbynetmats suite with these
changes and there were no failures.  As all changes in this patch are
specific to the Network Server, I don't think any other tests need to
be run.
  
  
Could someone please commit?
  
  
Thanks,
  
Army
  
  
 Original Message 
  
Subject: [PATCH]  Derby-157 Patch, plus 2 other minor server fixes.
  
Date: Thu, 03 Mar 2005 16:05:09 -0800
  
From: Army <[EMAIL PROTECTED]>
  
Reply-To: Derby Development 
  
To: Derby Development 
  
  
Attached is a patch that does the following three (pretty minor)
things:
  
  
1) First and foremost, it resolves DERBY-157.  If a datetime string
that is not recognized by the server is received
  
from the client, the server will now catch the resultant Java exception
and throw a valid SQLException with SQLSTATE
  
22007 ("The syntax of the string representation of a datetime value is
incorrect").  The old behavior was to throw a
  
DRDA protocol exception and deallocate the connection.
  
  
2) It corrects a small problem in the way the server treats timestamp
strings.  This problem, like DERBY-157, only
  
happens with non-JCC clients: users who insert a timestamp value into a
Derby table by binding a _string_ value (ex.
  
"1948-04-08 02:24:48") to a _timestamp_ parameter will actually get a
different value back when they do a SELECT because
  
the value is 'warped' by the server before insertion.  In particular,
extra 0's are added to the end of the string--ex.
  
"1948-04-08 02:24:48000"--which are then treated as seconds when the
server calls java.sql.Timestamp.valueOf(), and thus
  
the wrong value is inserted.
  
  
This doesn't happen with JDBC drivers because the code in question is
only executed when a _string_ value is being bound
  
to a _Timestamp_ parameter--basically, the user would have to do
something like
  
  
ps.setTimestamp(1, "1948-04-08 02:24:48")
  
  
--but JDBC doesn't allow that, because the second argument has to be a
Timestamp object.  With an ODBC client, though,
  
this kind of thing is possible, and so this problem should be fixed.
  
  
3) It removes an extraneous call to "finalizeChain()" that was
introduced as part of the "Multiple EXCSAT fix" patch
  
(see
http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200501.mbox/[EMAIL PROTECTED]). 
This
  
extra call doesn't lead to any bad behavior, but since it is
unnecessary and technically incorrect, it's good to remove
  
it.  It's a simple one-line removal, so if no one minds, I figure it
can be made with this patch, since all of the
  
changes in this patch are to the same file and they are all pretty
minor.
  
  
In terms of tests, I haven't modified or added any test cases because
these are problems that can only be seen with a
  
non-Java driver--and as far as I know, the current Derby test harness
has no means of introducing such a driver.
  
  
I have run the derbynetmats suite (on Windows using jdk142) with these
very minor changes and all tests passed.
  
  
Committers, please commit when you can...
  
  
Thanks,
  
Army
  
  
  
  
  

Index: java/drda/org/apache/derby/impl/drda/DRDAConnThread.java
===
--- java/drda/org/apache/derby/impl/drda/DRDAConnThread.java	(revision 158925)
+++ java/drda/org/apache/derby/impl/drda/DRDAConnThread.java	(working copy)
@@ -806,7 +806,6 @@
 case CodePoint.EXCSAT:
 	parseEXCSAT();
 	writeEXCSATRD();
-	finalizeChain();
 	break;
 case CodePoint.ACCSEC:
 	int securityCheckCode = parseACCSEC();
@@ -4039,7 +4038,17 @@
 String paramVal = reader.readStringData(10).trim();  //parameter may be char value
 if (SanityManager.DEBUG) 
 	trace("ndate parameter value is: \""+paramVal+"\"");
-ps.setDate(i+1, java.sql.Date.valueOf(paramVal));
+try {
+	ps.setDate(i+1, java.sql.Date.valueOf(paramVal));
+} catch (java.lang.IllegalArgumentException e) {
+	// Just use SQLSTATE as message since, if user wants to
+	// retrieve it, the message will be looked up by the
+	// sqlcamessage() proc, which will get the localized
+	// message based on SQLSTATE, and will ignore the
+	// the message we use here...
+	throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION,
+		SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5));
+}
 break;
 			}
 			case FdocaConstants.DRDA_TYPE_NTIME:
@@ -4047,20 +4056,37 @@
 String paramVal = re

Re: [VOTE] Reject tally of logo votes





+1. Reject the tally. 

Satheesh

Kathey Marsden wrote:

  
Vote 
+1 Reject the tally. New method of choosing a logo is determined by the community.
-1 Not to reject the tally. Keep the vote tally as is with 32 as the winner.



 


  
  Oops forgot  to vote

+1 Reject the tally. New method of choosing a logo is determined by the community.

Re: [jira] Commented: (DERBY-127) Aliased Columns not recognized after "group by... order by" combination

2005-03-25 Thread Satheesh Bandaram





I am just describing the current behavior. Definitely not saying it
can't be changed. If the statement is SQL standard based, then anyone
can address the issue and submit a patch.

Satheesh

Fawzi Karachi wrote:

  That's strange. The statement is SQL-92 compliant and supported by all
the databases I have tried including MS SQL, Oracle, DB2 and Mckoi.
Is derby not SQL-92 compliant?
Are you planning not to fix it in the next release of derby?
Please let me know as I have a system currenlty running against McKoi
and was planning to migrate it to Derby. But if this bug won't be
fixed, we will probably stay with McKoi or try Oracle Lite.

Thank you. 

Fawzi.


On Thu, 24 Mar 2005 21:10:21 +0100 (CET), Satheesh Bandaram (JIRA)
 wrote:
  
  
[ http://issues.apache.org/jira/browse/DERBY-127?page=comments#action_61513 ]

Satheesh Bandaram commented on DERBY-127:
-

Derby, in general, doesn't allow order by sort keys to be exposed names, if they also have a correlation name. (alias name) When a correlation name is specified, ORDER BY, specially requires using the correlation name or a simple-integer number. (like order by 1)

Going by this, the third query that works also should not. (Query without group by)



  Aliased Columns not recognized after "group by... order by" combination
---

 Key: DERBY-127
 URL: http://issues.apache.org/jira/browse/DERBY-127
 Project: Derby
Type: Bug
  Components: SQL
Versions: 10.0.2.1
 Environment: Windows XP Professional
JDK 1.4
(first found in relation to Mondrian 1.0.1)
Reporter: Thomas Browne
  


  I've been doing work to try and integrate Derby with the Mondrian ROLAP engine, which has uncovered a bug in Derby when a query involves column aliasing, a group by clause, and an order by clause.
For example:  Mondrian will generate the following query:
select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME
which should be valid SQL.  I have tested this query outside of the Mondrian environment and still receive the same error which is:
"Column 'STORE.STORE_COUNTRY' is not in any table in the FROM list or it appears within a join specification and is outside the scope of the join specification or it appears in a HAVING clause and is not in the GROUP BY list.
SQL State: 42x04
Error Code: 3
However, if I remove any one of the three elements (aliasing, group by, order by) or if the order by uses the aliased names, the query works.  It is only the combination of all 3 elements that is causing a problem.
[ie. all of the following queries work correctly]
select STORE.STORE_COUNTRY , STORE.STORE_STATE , STORE.STORE_CITY , STORE.STORE_NAME , STORE.STORE_TYPE , STORE.STORE_MANAGER , STORE.STORE_SQFT , STORE.GROCERY_SQFT , STORE.FROZEN_SQFT , STORE.MEAT_SQFT , STORE.COFFEE_BAR , STORE.STORE_STREET_ADDRESS from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME
select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS
select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME
select STORE.STORE_COUNTRY as c

Re: [jira] Commented: (DERBY-147) ERROR 42X79 not consistant ? - same column name specified twice

2005-03-28 Thread Satheesh Bandaram





I will work to get this into 10.1 release. Patch may have to be changed
to address some issues raised by Jack.

Satheesh

Bernd Ruehlicke (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/DERBY-147?page=comments#action_61646 ]
 
Bernd Ruehlicke commented on DERBY-147:
---

So - how do I make sure this stuff makes it into the 10.1 release ?

  
  
ERROR 42X79 not consistant ? - same column name specified twice
---

 Key: DERBY-147
 URL: http://issues.apache.org/jira/browse/DERBY-147
 Project: Derby
Type: Bug
Reporter: Bernd Ruehlicke
 Attachments: derby-147-10.0.2.1.diff, derby-147.diff

This happens from JDBC or ij. Here the output form ij>
ij version 10.0 
CONNECTION0* - 	jdbc:derby:phsDB 
* = current connection 
ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1 ORDER BY a1.XXX_foreign;
ERROR 42X79: Column name 'XXX_FOREIGN' appears more than once in the result of the query _expression_. 
But when removing the ORDER BY and keeping the 2 same column names it works
ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1;
XXX_FOREIGN |NATIVE  |KIND|XXX_FOREIGN  ---  
0 rows selected 
ij> 
So - it seams to be OK to specify the same column twice - as long as you do not add the ORDER BY clause.  
I woul dof course like that the system allows this - but at leats it should be consistant and either allow both or none of the two queries above.

Re: [Patch] Re: About improvement of DERBY-134

2005-03-29 Thread Satheesh Bandaram

I will work on committing this patch. Since you are working on an
improvement, would you mind submitting this patch through Jira? Use
AttachFile option and you also need to select "Grant ASF license to
include in ASF works"  option. (URL:
http://issues.apache.org/jira/secure/AttachFile!default.jspa?id=29790)
This would help committers in accepting the patch.

Also, you might want to consider signing ICLA with Apache.
(http://www.apache.org/licenses/icla.txt) This will help process your
contributions faster. This is also a requirement to becoming a committer
at a future time.

Satheesh

TomohitoNakayama wrote:

> Waiting 1 day and no error was found.
> Can I ask committers to commit this patch ?
>
> Or I should commit it by myself ?
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> - Original Message - From: "Jack Klebanoff"
> <[EMAIL PROTECTED]>
> To: "Derby Development" 
> Sent: Tuesday, March 29, 2005 4:31 AM
> Subject: Re: [Patch] Re: About improvement of DERBY-134
>
>
>> TomohitoNakayama wrote:
>>
>>> Hello.
>>>
>>> I have added some test to orderby.sql (and correspond result to
>>> orderby.out) ,
>>> which was suggested by Jack Klebanoff.
>>>
>>> And I have executed derbylang test and coulud not found error exept
>>> for lang/floattypes.sql.
>>> I think this error is not caused by my patch.
>>>
>>> derbylang_report.txt is attached to this mail.
>>>
>>> Please check this patch from a point of other person's view.
>>>
>>> best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> [EMAIL PROTECTED]
>>> [EMAIL PROTECTED]
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>
>>
>> The latest patch looks good to me. I looked at the changes, applied
>> the patch to recently updated Derby source, and successfully ran the
>> derbylang test suite. (I did not even see the failure in
>> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby
>> updates I picked up today).
>>
>> Jack Klebanoff
>>
>>
>>
>> -- 
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>
>>
>
>

Re: [PATCH] Derby-174

2005-03-29 Thread Satheesh Bandaram

I have submitted this patch. Thanks for adding new test case to test
both. But the new test is not part of any test suite, so it may not get
run even though it is there.  Can you add the test case into 'jdbcapi'
or 'derbylang' test suites?

Sendingjava\engine\org\apache\derby\iapi\types\SQLBlob.java
Sendingjava\engine\org\apache\derby\iapi\types\SQLTimestamp.java
Adding
java\testing\org\apache\derbyTesting\functionTests\master\prepStmtNull.out
Adding
java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\prepStmtNull.java
Transmitting file data 
Committed revision 159445.

Shreyas Kaushik wrote:

> Sateesh,
>
> Did you have a chance to look into this?
>
> ~ Shreyas
>
> Shreyas Kaushik wrote:
>
>> Attached is the latest patch with the changes.
>>
>> thanks
>> Shreyas
>>
>> Satheesh Bandaram wrote:
>>
>>> I will submit your patches after your changes.
>>>
>>> Satheesh
>>>
>>> Shreyas Kaushik wrote:
>>>
>>>  
>>>
>>>> I guess this is an IDE trick , I'll change this.
>>>>
>>>> ~ Shreyas
>>>>
>>>> Army wrote:
>>>>
>>>>  
>>>>
>>>>> <[EMAIL PROTECTED]> wrote
>>>>>
>>>>>
>>>>>
>>>>>> -import java.sql.Date;
>>>>>> -import java.sql.Time;
>>>>>> -import java.sql.Timestamp;
>>>>>> -import java.sql.Types;
>>>>>> -import java.sql.ResultSet;
>>>>>> -import java.sql.SQLException;
>>>>>> +import java.sql.*;
>>>>>>   
>>>>>
>>>>>
>>>>>
>>>>> I apologize if this is overly picky, but isn't inclusion of a package
>>>>> via the "*" wildcard generally considered an unfavorable programming
>>>>> practice?  I think it's fine to do so when writing tests, but as far
>>>>> as I know, the Derby codeline generally avoids using wildcard
>>>>> imports.  And even if there are existing places where such imports
>>>>> are used, it seems to me that _replacing_ existing imports with the
>>>>> wildcard import is probably not a habit to encourage.
>>>>>
>>>>> Even if functionally speaking there's no difference, to do this is to
>>>>> introduce a style of imports that's doesn't agree with the rest of
>>>>> the codeline--is that something to avoid?
>>>>>
>>>>> 'Course, maybe that's just unfounded paranoia on my part...
>>>>>
>>>>> *shrug*
>>>>> Army
>>>>>
>>>>> 
>>>>
>>>>
>>>>
>>>>   
>>>
>>>
>>>
>>>  
>>>
>> 
>>
>> Index: java/engine/org/apache/derby/iapi/types/SQLTimestamp.java
>> ===
>> --- java/engine/org/apache/derby/iapi/types/SQLTimestamp.java   
>> (revision 158017)
>> +++ java/engine/org/apache/derby/iapi/types/SQLTimestamp.java   
>> (working copy)
>> @@ -45,12 +45,15 @@
>> import org.apache.derby.iapi.types.SQLDouble;
>> import org.apache.derby.iapi.types.SQLTime;
>>
>> +
>> +
>> import java.sql.Date;
>> import java.sql.Time;
>> import java.sql.Timestamp;
>> import java.sql.Types;
>> import java.sql.ResultSet;
>> import java.sql.SQLException;
>> +import java.sql.PreparedStatement;
>>
>> import java.util.Calendar;
>> import java.util.GregorianCalendar;
>> @@ -65,7 +68,7 @@
>> /**
>>  * This contains an instance of a SQL Timestamp object.
>>  * 
>> - * SQLTimestamp is stored in 3 ints - an encoded date, an encoded
>> time and + * SQLTimestamp is stored in 3 ints - an encoded date, an
>> encoded time and
>>  *nanoseconds
>>  * encodedDate = 0 indicates a null WSCTimestamp
>>  *
>> @@ -989,5 +992,12 @@
>> currentCal.setTime(value);
>> return SQLTime.computeEncodedTime(currentCal);
>> }
>> +
>> ++public void setInto(PreparedStatement ps, int position)
>> throws SQLException, StandardException {
>> +
>> +  ps.setTimestamp(position, getTimestamp((Calendar)
>> null));
>> + }
>> }
>>
>> +
>>  
>>
>
>
>

Re: [PATCH] Derby-174

2005-03-30 Thread Satheesh Bandaram





Submitted this patch.

Satheesh

Sending   
java\testing\org\apache\derbyTesting\functionTests\suites\jdbcapi.runall
Transmitting file data .
Committed revision 159474.

Shreyas Kaushik wrote:
Thanks
Satheesh.
  
  
Please find the patch attached, after adding this test to the
jdbcapi.runall file.
  
  
~ Shreyas
  
  
Satheesh Bandaram wrote:
  
  
  I have submitted this patch. Thanks for
adding new test case to test

both. But the new test is not part of any test suite, so it may not get

run even though it is there.  Can you add the test case into 'jdbcapi'

or 'derbylang' test suites?


Sending    java\engine\org\apache\derby\iapi\types\SQLBlob.java

Sending   
java\engine\org\apache\derby\iapi\types\SQLTimestamp.java

Adding   
java\testing\org\apache\derbyTesting\functionTests\master\prepStmtNull.out

Adding   
java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\prepStmtNull.java

Transmitting file data 

Committed revision 159445.


Shreyas Kaushik wrote:


 


Sateesh,
  
  
Did you have a chance to look into this?
  
  
~ Shreyas
  
  
Shreyas Kaushik wrote:
  
  
   
  Attached is the latest patch with the
changes.


thanks

Shreyas
    
    
Satheesh Bandaram wrote:


 
I will submit your patches after your
changes.
  
  
Satheesh
  
  
Shreyas Kaushik wrote:
  
  
  
  
   
  I guess this is an IDE trick , I'll
change this.


~ Shreyas


Army wrote:




 
<[EMAIL PROTECTED]>
wrote
  
  
  
   
  -import java.sql.Date;

-import java.sql.Time;

-import java.sql.Timestamp;

-import java.sql.Types;

-import java.sql.ResultSet;

-import java.sql.SQLException;

+import java.sql.*;

  
  
  
I apologize if this is overly picky, but isn't inclusion of a package
  
via the "*" wildcard generally considered an unfavorable programming
  
practice?  I think it's fine to do so when writing tests, but as far
  
as I know, the Derby codeline generally avoids using wildcard
  
imports.  And even if there are existing places where such imports
  
are used, it seems to me that _replacing_ existing imports with the
  
wildcard import is probably not a habit to encourage.
  
  
Even if functionally speaking there's no difference, to do this is to
  
introduce a style of imports that's doesn't agree with the rest of
  
the codeline--is that something to avoid?
  
  
'Course, maybe that's just unfounded paranoia on my part...
  
  
*shrug*
  
Army
  
  
      


 

 
  
  
  
  
   




Index: java/engine/org/apache/derby/iapi/types/SQLTimestamp.java

===

--- java/engine/org/apache/derby/iapi/types/SQLTimestamp.java  
(revision 158017)

+++ java/engine/org/apache/derby/iapi/types/SQLTimestamp.java  
(working copy)

@@ -45,12 +45,15 @@

import org.apache.derby.iapi.types.SQLDouble;

import org.apache.derby.iapi.types.SQLTime;


+

+

import java.sql.Date;

import java.sql.Time;

import java.sql.Timestamp;

import java.sql.Types;

import java.sql.ResultSet;

import java.sql.SQLException;

+import java.sql.PreparedStatement;


import java.util.Calendar;

import java.util.GregorianCalendar;

@@ -65,7 +68,7 @@

/**

* This contains an instance of a SQL Timestamp object.

* 

- * SQLTimestamp is stored in 3 ints - an encoded date, an encoded

time and + * SQLTimestamp is stored in 3 ints - an encoded date, an

encoded time and

*    nanoseconds

* encodedDate = 0 indicates a null WSCTimestamp

*

@@ -989,5 +992,12 @@

   currentCal.setTime(value);

   return SQLTime.computeEncodedTime(currentCal);

   }

+

+    +    public void setInto(PreparedStatement ps, int position)

throws SQLException, StandardException {

+

Re: [jira] Commented: (DERBY-190) Derby build should be incremental

2005-03-30 Thread Satheesh Bandaram





Is 5-10 minutes for a full build too long? On my laptop, (with only 512
MB memory) full build takes about 6 minutes. Running tests is another
matter... Takes hours to run full test suite, though Derby has
sub-suites that run only parts of the suites.

Satheesh

David Van Couvering (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/DERBY-190?page=comments#action_61851 ]
 
David Van Couvering commented on DERBY-190:
---

Forgot to add this.  Section 4.1 of BUILDING.txt says


  clobber: remove all built objects except jars. You should run
   this target if you have source code upgrade or
   you changed the source code and you are getting
   some errors.

Every time I do a svn update it's a source code upgrade and I should do a clobber.  One concern I have is that because of this many developers will not want to deal with a source code upgrade and their local svn tree will get stale. 

  
  
Derby build should be incremental
-

 Key: DERBY-190
 URL: http://issues.apache.org/jira/browse/DERBY-190
 Project: Derby
Type: Improvement
  Components: Build tools
Versions: 10.0.2.2
Reporter: David Van Couvering

  
  
  
  
You should not have to clobber and rebuild from scratch each time you update or modify your source.  This is time-consuming and affects overall productivity.

Re: more background threads

2005-04-01 Thread Satheesh Bandaram

Very interesting plans. What kind of application are you thinking of
running on these 4-way or 8 way machines? Will you be using embedded
driver or client-server network driver?

I am also wondering how is the scalability of Java VMs these days? I
know earlier VMs (a few years back) weren't scaling well beyond 3 or 4
CPUs. Is that any better with Sun or IBM VMs?

Satheesh

David Van Couvering wrote:

> Hi, Mike, thanks for the response and very helpful overview.  At first
> blush it seems like the single daemon could easily be converted to a
> thread pool approach where work is posted to a "dispatcher" who grabs
> a thread and dispatches the work to it.  I say this without having yet
> looked at the code, but in the meantime any reasons why this obviously
> won't work would be much appreciated.
>
> I can work on building up a test case that fills up the background
> thread so we can "prove" that whatever solution we come up with helps
> the system scale better.  I can post a test plan prior to actually
> creating the test to see if you all agree the test looks to be what we
> want it to be.
>
> I can also look into testing Derby scalability on a 4-way or 8-way
> machine, I think some of these are available in our lab.  I would also
> like to do some testing on some of Sun's new multi-core chips, where
> you have 8 threads per core and 4-8 cores per CPU.  Derby seems to be
> well-suited to this architecture but it would be good to see if there
> are any gotchas.  Again, I would proposed these as plans first and get
> your feedback.
>
> What protocol do I use to sort of "identify" this is a sub-project and
> track its progress?  Do I create a JIRA item labelled as an
> "improvement" and assign it to myself?
>
> Thanks,
>
> David
>
> Mike Matrigali wrote:
>
>> I have changed the subject, as I completely missed the original post
>> which had something to do with adding Junit tests.
>>
>> I am not sure what is the right solution here, but getting a discussion
>> going would be good.
>>
>> Currently a number of store actions are queued in "post commit" mode,
>> which means they should be executed until after the transaction which
>> queued them commits.  Currently there is one background thread which
>> processes these, if it gets too full then the work is done by the actual
>> thread which queued the work.   Most of the post commit work involves
>> claiming space from deleted rows after their transaction commits.
>>
>> Going forward there is going to be a need for more background work.  I
>> soon will be posting the first phase of work to allow for returning
>> space back to the operating system, eventually it would be best if this
>> work was also done in background, somehow automatically queued by the
>> system.
>>
>> I would also recommend coming up with a usage scenario which shows a
>> problem before coding up a solution.  I believe a test with lots of
>> users doing insert and delete should eventually show the background task
>> being bogged down -- but I am not sure if moving work to additional
>> threads is much better than just spreading the work out across the
>> existing user threads.
>>
>> The code for the current background thread can be found in:
>> opensource/java/engine/org/apache/derby/impl/services/daemon
>>
>> An example of one of the unit of work put on the queue is in:
>> opensource/java/engine/org/apache/derby/impl/store/access/heap/heappostcommit.java
>>
>>
>> Dan is probably the person who most recently worked on this code, and
>> should have some comments in this area.  He should be back active on the
>> list early next week.
>>
>> Note another interesting area of research/coding would be to see how
>> derby scales on larger number of processor machines.  Not much work has
>> been done at all on machines with more than 2 processors.  The system
>> has been designed from bottom up to be multi-threaded, but not much
>> testing/monitoring has been done on 4 or more processor machines.   The
>> following single threading points exist in derby:
>>o each user query is executed by a single thread.
>>o the locking system in protected by a single java synchonization
>> point.
>>o copying log records into the log is a single sync point
>>o finding a buffer in the buffer cache is a single sync point
>>
>> All of these seemed to be reasonable designs for 1, 2 and 4 way
>> machines.
>>
>> /mikem
>>
>>
>> David Van Couvering wrote:
>>
>>  
>>
>>> I noticed on the todo list there is a need to have more than one
>>> background thread to enable better scalability with lots of client
>>> connections.  I'm trying to find a way to gently work my way into doing
>>> some work on Derby, and this seemed like a project of small enough
>>> scope
>>> to get my feet wet.  Is there any background on this, or should I just
>>> jump right in?  I didn't see any discussion of this on the list...
>>>
>>> Thanks,
>>>
>>> David
>>>
>>>   
>>
>
>
>

Re: [jira] Commented: (DERBY-186) isFirst() returns true when relative(x) goes beyond result set

2005-04-01 Thread Satheesh Bandaram

I will do it today... Got side tracked for few days..

Satheesh

Shreyas Kaushik wrote:

> Did anyone get  a chance to look at this and commit it?
>
> ~ Shreyas
>
> Shreyas Kaushik wrote:
>
>> Attached the latest patch. This addition to this patch from the old
>> one is that I have added the test
>> in the jdbcapi.runall file for it to run in both Embedded and Network
>> Server mode.
>>
>> ~ Shreyas
>>
>> Shreyas Kaushik wrote:
>>
>>> Hi Mamta,
>>>
>>> Thanks for all the info. This definitely gave more insight into this
>>> test framework.
>>> I recently submitted a patch for Derby-174 and Derby-175 for which I
>>> have just submitted a
>>> patch for for jdbcapi.runall file. After that gets in I will
>>> definitely add this one as well
>>> and submit all of it in a fresh patch. I am waiting for that to go
>>> in as there could be conflicts
>>> in the jdbcapi.runall file.
>>>
>>> ~ Shreyas
>>>
>>> Mamta Satoor wrote:
>>>
 On Tue, 29 Mar 2005 22:45:24 +0530, Shreyas Kaushik
 <[EMAIL PROTECTED]> wrote:
  

> Hi Mamta,
>
> Thanks for all the info.
> From this I see that adding it in jdbcapi will run in both
> embedded and
> netwrok server mode.
> Should I add some properties file specifically for my test?
> I'm sorry I ask this again, I'm not clear what changes I have to
> do to
> my patch ?
>
> ~ Shreyas
>
>   




 Hi Shreyas,

 You will see that each of the directories under functionTests/tests
 have their own default properties file. If a newly added test does not
 have a test specific properties file, then the default properties file
 gets picked up. For eg, test declareGlobalTempTableJavaJDBC30.java has
 its own properties file because we do not want the test to be run with
 some jdks and we speify that
 declareGlobalTempTableJavaJDBC30_app.properties. Since the test you
 are adding has no special requirements, you donot need a properties
 file for it and harness will automatically use the default properties
 file for your test.

 Feel free to ask more questions if you have any. Since I have been
 working on this test harness for so long, I might not be visualizing
 some questions that a new developer might have.

 thanks,
 Mamta
  

>> 
>>
>> Index:
>> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java
>>
>> ===
>> ---
>> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java
>>
>> (revision 159474)
>> +++
>> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java
>>
>> (working copy)
>> @@ -750,6 +750,7 @@
>> else
>> {
>> afterLast = true;
>> +currentPosition = positionInSource + 1;
>> }
>> }
>>
>> Index:
>> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
>>
>> ===
>> ---
>> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
>>
>> (revision 0)
>> +++
>> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
>>
>> (revision 0)
>> @@ -0,0 +1,98 @@
>> +package org.apache.derbyTesting.functionTests.tests.jdbcapi;
>> +
>> +
>> +import java.sql.*;
>> +
>> +import org.apache.derby.tools.ij;
>> +import org.apache.derby.tools.JDBCDisplayUtil;
>> +
>> +public class testRelative {
>> +   public static void main(String[] args) {
>> +test1(args);+}
>> ++public static void test1(String []args) {  
>> +Connection con;
>> +ResultSet rs;
>> +PreparedStatement stmt = null;
>> +PreparedStatement pStmt = null;
>> +Statement stmt1 = null;
>> +String returnValue = null;
>> +
>> +System.out.println("Test testRelative starting");
>> +
>> +try
>> +{
>> +// use the ij utility to read the property
>> file and
>> +// make the initial connection.
>> +ij.getPropertyArg(args);
>> +con = ij.startJBMS();
>> +   
>> +   
>> con.setAutoCommit(false); 
>> ++stmt =
>> con.prepareStatement("create table testRelative(name varchar(10), i
>> int)");
>> +   stmt.executeUpdate();
>> +   con.commit();
>> +  
>> +   pStmt = con.prepareStatement("insert into
>> testRelative values (?,?)");
>> + 
>> +   pStmt.setString(1,"work1");
>> +pStmt.setNull(2,

Re: [Patch] Re: About improvement of DERBY-134

2005-04-02 Thread Satheesh Bandaram

Submitted this patch. Thanks for patiently addressing all concerns.
Final patch looks really good. Hope you will continue working on
enhancing Derby. If you would like some ideas on what to tackle next, I
can help... :-)   

I think this improvement has been asked by several others in the community.

Satheesh

Sending   
java\engine\org\apache\derby\impl\sql\compile\IntersectOrExceptNode.java
Sending   
java\engine\org\apache\derby\impl\sql\compile\OrderByColumn.java
Sendingjava\engine\org\apache\derby\impl\sql\compile\TableName.java
Sendingjava\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\orderby.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\orderby.sql
Transmitting file data ..
Committed revision 159746.

TomohitoNakayama wrote:

> Hello.
>
> Thanks.
> I see. I re-sended patch via JIRA.
>
> I will send ICLA in days.
> Because it is a bit substantial , I need time ...
>
> Best regards.
>
> /*
>
> Tomohito Nakayama
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> Naka
> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>
> */
> - Original Message - From: "Satheesh Bandaram"
> <[EMAIL PROTECTED]>
> To: "Derby Development" 
> Sent: Wednesday, March 30, 2005 3:43 AM
> Subject: Re: [Patch] Re: About improvement of DERBY-134
>
>
>> I will work on committing this patch. Since you are working on an
>> improvement, would you mind submitting this patch through Jira? Use
>> AttachFile option and you also need to select "Grant ASF license to
>> include in ASF works"  option. (URL:
>> http://issues.apache.org/jira/secure/AttachFile!default.jspa?id=29790)
>> This would help committers in accepting the patch.
>>
>> Also, you might want to consider signing ICLA with Apache.
>> (http://www.apache.org/licenses/icla.txt) This will help process your
>> contributions faster. This is also a requirement to becoming a committer
>> at a future time.
>>
>> Satheesh
>>
>> TomohitoNakayama wrote:
>>
>>> Waiting 1 day and no error was found.
>>> Can I ask committers to commit this patch ?
>>>
>>> Or I should commit it by myself ?
>>>
>>> Best regards.
>>>
>>> /*
>>>
>>> Tomohito Nakayama
>>> [EMAIL PROTECTED]
>>> [EMAIL PROTECTED]
>>>
>>> Naka
>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>
>>> */
>>> - Original Message - From: "Jack Klebanoff"
>>> <[EMAIL PROTECTED]>
>>> To: "Derby Development" 
>>> Sent: Tuesday, March 29, 2005 4:31 AM
>>> Subject: Re: [Patch] Re: About improvement of DERBY-134
>>>
>>>
>>>> TomohitoNakayama wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> I have added some test to orderby.sql (and correspond result to
>>>>> orderby.out) ,
>>>>> which was suggested by Jack Klebanoff.
>>>>>
>>>>> And I have executed derbylang test and coulud not found error exept
>>>>> for lang/floattypes.sql.
>>>>> I think this error is not caused by my patch.
>>>>>
>>>>> derbylang_report.txt is attached to this mail.
>>>>>
>>>>> Please check this patch from a point of other person's view.
>>>>>
>>>>> best regards.
>>>>>
>>>>> /*
>>>>>
>>>>> Tomohito Nakayama
>>>>> [EMAIL PROTECTED]
>>>>> [EMAIL PROTECTED]
>>>>>
>>>>> Naka
>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html
>>>>>
>>>>> */
>>>>
>>>>
>>>>
>>>> The latest patch looks good to me. I looked at the changes, applied
>>>> the patch to recently updated Derby source, and successfully ran the
>>>> derbylang test suite. (I did not even see the failure in
>>>> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby
>>>> updates I picked up today).
>>>>
>>>> Jack Klebanoff
>>>>
>>>>
>>>>
>>>> -- 
>>>> No virus found in this incoming message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> -- 
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27
>>
>>
>
>

Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs

2005-04-02 Thread Satheesh Bandaram





This patch is committed. Thanks for improving performance by moving
checks from runtime to compile time.

Satheesh

Mamta Satoor wrote:

  On Wed, 09 Mar 2005 09:34:35 -0800, Daniel John Debrunner
<[EMAIL PROTECTED]> wrote:
  
  
+0.8

I think the functionality is correct, but there are some issues in the
method checksBeforeUpdateOrDelete(). They could be addressed in a
subsequent patch.

- The code at the end of  checksBeforeUpdateOrDelete to get the table
descriptor and perform column correlation name checks is expensive, and
seems like it could be done once, rather than on every updateXXX. A
final solution would ideally address these concerns at compile time and
not runtime, e.g. part of compilation could be identifying if a
statement is suitable for updateable result sets.

- Making method behaviour depend on the name of the calling method is
not a common programming practise in Derby, and again is expensive. Now
every updateXXX() call has to perform three String comparisions that are
not needed. Ie. this code.

 //the remaining checks only apply to updateXXX methods
+  if (methodName.equals("updateRow") ||
methodName.equals("deleteRow") || methodName.equals("cancelRowUpdates"))
+return;

The typical way to address this would be to have the code before this in
a separate method, have deleteRow, updateRow and cancelRowUpdate methods
call that new method, and have checksBeforeUpdateOrDelete call that
method (rather than duplicate code).

- The lack of synchronization for the updateXXX() methods is also an
area of concern. As coded two threads performing concurrent updateXXX()
calls on the same result set will mess each other up, leading to missed
update values or possibly NullPointerException later if cancelRowUpdates
is called. But synchronization is a performance hit, and multiple
threads executing concurrent operations on a JDBC object is not
recommended. So maybe we can survive without it?
[Putting the synchronization in getDVDforColumnUpdates() would be the
logical place, not each updateXXX method.]

Dan.



  
  
I have a patch which takes care of first 2 points raised by Dan. 

Derby does not support correlation name for updatable columns. This
check was earlier made at runtime everytime an updateXXX was issued. I
have moved the check for correlation name to compile time in
CursorNode.java. If the cursor sql has a correlation name for an
updatable column, compile time code will throw an exception. The new
exception code and message has been added to SQLState.java and
messages_en.properties respectively.

The changes in EmbedResultSet.java is to remove the runtime check for
correlation name and to make the various other checks prior to
updateXXX, updateRow and cancelRowUpdates and deleteRow more
efficient.

In addition, I have changed the existing tests to have couple more
checks for compile time catch of correlation name.

Can a commiter please commit this patch for me?

svn stat
M  java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
M  java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
M  java\engine\org\apache\derby\iapi\reference\SQLState.java
M  java\engine\org\apache\derby\loc\messages_en.properties
M  java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
M  java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out
M  java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out

thanks,
Mamta
  
  

Index: java/engine/org/apache/derby/impl/sql/compile/CursorNode.java
===
--- java/engine/org/apache/derby/impl/sql/compile/CursorNode.java	(revision 159525)
+++ java/engine/org/apache/derby/impl/sql/compile/CursorNode.java	(working copy)
@@ -716,6 +716,7 @@
 		int size = updatableColumns.size();
 		TableDescriptor tableDescriptor;
 		String columnName;
+		ResultColumnList rcls = resultSet.getResultColumns();
 
 		for (int index = 0; index < size; index++)
 		{
@@ -723,9 +724,22 @@
 		tableDescriptor = targetTable.getTableDescriptor();
 		if ( tableDescriptor.getColumnDescriptor(columnName) == null)
 		{
-			throw StandardException.newException(SQLState.LANG_COLUMN_NOT_FOUND, columnName);
+	throw StandardException.newException(SQLState.LANG_COLUMN_NOT_FOUND, columnName);
 		}
 
+		ResultColumn rc;
+		//make sure that we are not using correlation names for updatable columns. 
+		//eg select c11 as col1, 2, c13 as col3 from t1 for update of c11, c12
+		//In the eg above, correlation name for c11 will cause exception because Derby does not support correlation name for updatable columns
+		//But correlation name for c13 is ok because it is a read only column
+		for (int rclsIndex = 0; rclsIndex < rcls.size(); rclsIndex++) {//look through each column in the resultset for cursor
+	rc = ((ResultColumn) rcls.elementAt(rclsIndex));
+	if (rc.

Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134

2005-04-03 Thread Satheesh Bandaram





Right... Option 1, adding GENERATED BY DEFAULT AS IDENTITY would be
great.

Satheesh

Kathey Marsden wrote:

  Danesh Irani wrote:

  
  
Hello Kathey,

Christian when reporting Derby-167 had a few possible solutions, is
Satheesh's proposed SQL Standard way included in one of those? If not
could you perhaps elaborate a little on what Satheesh proposed.
Personally I think all 3 of Christians solutions would add value in
terms of flexibility to Derby.

Thanks
~Danesh
 



  
  I couldn't find Satheesh's mail but yes it was regarding option 1,
generated by default.  I  looked up the SQL syntax  in the sql standard
and put a comment in the JIRA  entry. 

Kathey

Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134

2005-04-05 Thread Satheesh Bandaram





Hi Tomohito,

I thought a column that is GENERATED BY DEFAULT AS IDENTITY
would allow you to insert any user specified value. System would
generate a value only if there is no explicit value provided, so I am
not sure if there is a need to disable "identity" feature for the
column. I looked very briefly at the SQL spec. This is what it says: If
 is specified,then:

  If ALWAYS is specified, then an indication that values are always
generated.
  If BY DEFAULT is specified, then an indication that values are
generated by default.

Derby already has GENERATED ALWAYS option. I think it would be great to
add GENERATED BY DEFAULT option.

I ran some sample querries on DB2 that I have access to. This is what
it does.

CREATE TABLE TBL1(COL1 INT GENERATED ALWAYS AS IDENTITY,
COL2 INT)
CREATE TABLE TBL2(COL1 INT GENERATED BY DEFAULT AS IDENTITY,
COL2 INT)

CASE1: Any insert value for COL1 is not specified explicitly or
provided as DEFAULT.

INSERT INTO TBL1(COL2) VALUES(10)
INSERT INTO TBL2(COL2) VALUES(10)
INSERT INTO TBL1(COL1, COL2) VALUES(DEFAULT, 10)
INSERT INTO TBL2(COL1, COL2) VALUES(DEFAULT, 10)

In this case, all of above-mentioned insert statements set COL1 to a
sequence value.

CASE2: An insert value for COL1 is supplied explicitly by a table value
constructor.

INSERT INTO TBL1(COL1, COL2) VALUES(1, 10)
INSERT INTO TBL2(COL1, COL2) VALUES(1, 10)

In this case, the first insert fails, but the second passes. Second
insert may cause a duplicate value to be inserted into the identity
column. If needed, a unique or primay key constraint can be used to
prevent duplicate values for the case of GENERATED BY DEFAULT option.

CASE3: An update value that is not a default specification is specified
for COL1.

UPDATE TBL1 SET COL1 = 1 WHERE COL2 = 10
UPDATE TBL2 SET COL1 = 1 WHERE COL2 = 10

First update statement raises an error. (case of GENERATED AS ALWAYS)
Second update succeeds. (GENERATED BY DEFAULT). Again, this update may
cause duplicate COL1 values, but that could be prevented by using a
unique or primay key constraint.

Satheesh

TomohitoNakayama wrote:
Hello.
  
  
  
2:being able to disable the "identity"
feature for a column
  
3:being able to generate a column as non identity and after data is
  
populated, alter table to add the "identity" to the column
  

  
  
I think those are needed to allow user to enable loading data "AND"
keep values at identity column tidy.
  
(Now "tidy" means user can't decide pk value at their discretion.)
  
  
We should have both approaches after all ...
  
  
Then I think this is matter of priority.
  
  
/*
  
  
ÂÂÂ Tomohito Nakayama
  
ÂÂÂ [EMAIL PROTECTED]
  
ÂÂÂ [EMAIL PROTECTED]
  
  
ÂÂÂ Naka
  
ÂÂÂ http://www5.ocn.ne.jp/~tomohito/TopPage.html
  
  
*/
  
- Original Message - From: "Kathey Marsden"
<[EMAIL PROTECTED]>
  
To: "Derby Development" 
  
Sent: Sunday, April 03, 2005 11:12 PM
  
Subject: Re: (Derby 167) was Re: [Patch] Re: About improvement of
DERBY-134
  
  
  
  TomohitoNakayama wrote:


Hello.
  
  
I was interested in issue of Derby-167...
  
  
I recognized there was proposed three options.
  
1:being able to "generate by default as identity"
  
2:being able to disable the "identity" feature for a column
  
3:being able to generate a column as non identity and after data is
  
populated, alter table to add the "identity" to the column
  
  
In my opinion , option 2 and option 3Â increase statuses which table
  
can take , identity feature working state and not working state,
  
so they would make it complex to maintain db.
  
On the other hand, if we take option 1, we need to prevent it from to
  
have same value in identity column.
  
  

I think it's ok to let the user prevent duplicatesÂ with a primary key

if they want to.

When creating the table,Â the user would need to make sure that they

used START WITHÂ to ensure that generation starts with the maximum
value

+ 1.Â I put a comment in the bug with how I think the process would go.


A bit precarious I know if you forget to create your table properly,
but

at least it makes it *possible* to load data.

Later we could enhance support for ALTER TABLE to alter the identity

column specification to specify a RESTART WITH value.


Thanks



Kathey








--Â
No virus found in this incoming message.

Checked by AVG Anti-Virus.

Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 2005/04/01

Re: [jira] Commented: (DERBY-186) isFirst() returns true when relative(x) goes beyond result set

2005-04-06 Thread Satheesh Bandaram

This patch is committed.

Satheesh

Sending   
java\engine\org\apache\derby\impl\sql\execute\ScrollInsensitiveResultSet.java
Adding
java\testing\org\apache\derbyTesting\functionTests\master\testRelative.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\suites\jdbcapi.runall
Adding
java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\testRelative.java
Transmitting file data 
Committed revision 160247.

Shreyas Kaushik wrote:

> Did anyone get  a chance to look at this and commit it?
>
> ~ Shreyas
>
> Shreyas Kaushik wrote:
>
>> Attached the latest patch. This addition to this patch from the old
>> one is that I have added the test
>> in the jdbcapi.runall file for it to run in both Embedded and Network
>> Server mode.
>>
>> ~ Shreyas
>>
>> Shreyas Kaushik wrote:
>>
>>> Hi Mamta,
>>>
>>> Thanks for all the info. This definitely gave more insight into this
>>> test framework.
>>> I recently submitted a patch for Derby-174 and Derby-175 for which I
>>> have just submitted a
>>> patch for for jdbcapi.runall file. After that gets in I will
>>> definitely add this one as well
>>> and submit all of it in a fresh patch. I am waiting for that to go
>>> in as there could be conflicts
>>> in the jdbcapi.runall file.
>>>
>>> ~ Shreyas
>>>
>>> Mamta Satoor wrote:
>>>
 On Tue, 29 Mar 2005 22:45:24 +0530, Shreyas Kaushik
 <[EMAIL PROTECTED]> wrote:

> Hi Mamta,
>
> Thanks for all the info.
> From this I see that adding it in jdbcapi will run in both
> embedded and
> netwrok server mode.
> Should I add some properties file specifically for my test?
> I'm sorry I ask this again, I'm not clear what changes I have to
> do to
> my patch ?
>
> ~ Shreyas
>
>   

 Hi Shreyas,

 You will see that each of the directories under functionTests/tests
 have their own default properties file. If a newly added test does not
 have a test specific properties file, then the default properties file
 gets picked up. For eg, test declareGlobalTempTableJavaJDBC30.java has
 its own properties file because we do not want the test to be run with
 some jdks and we speify that
 declareGlobalTempTableJavaJDBC30_app.properties. Since the test you
 are adding has no special requirements, you donot need a properties
 file for it and harness will automatically use the default properties
 file for your test.

 Feel free to ask more questions if you have any. Since I have been
 working on this test harness for so long, I might not be visualizing
 some questions that a new developer might have.

 thanks,
 Mamta

>> 
>>
>> Index:
>> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java
>>
>> ===
>> ---
>> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java
>>
>> (revision 159474)
>> +++
>> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java
>>
>> (working copy)
>> @@ -750,6 +750,7 @@
>> else
>> {
>> afterLast = true;
>> +currentPosition = positionInSource + 1;
>> }
>> }
>>
>> Index:
>> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
>>
>> ===
>> ---
>> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
>>
>> (revision 0)
>> +++
>> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
>>
>> (revision 0)
>> @@ -0,0 +1,98 @@
>> +package org.apache.derbyTesting.functionTests.tests.jdbcapi;
>> +
>> +
>> +import java.sql.*;
>> +
>> +import org.apache.derby.tools.ij;
>> +import org.apache.derby.tools.JDBCDisplayUtil;
>> +
>> +public class testRelative {
>> +   public static void main(String[] args) {
>> +test1(args);+}
>> ++public static void test1(String []args) {  
>> +Connection con;
>> +ResultSet rs;
>> +PreparedStatement stmt = null;
>> +PreparedStatement pStmt = null;
>> +Statement stmt1 = null;
>> +String returnValue = null;
>> +
>> +System.out.println("Test testRelative starting");
>> +
>> +try
>> +{
>> +// use the ij utility to read the property
>> file and
>> +// make the initial connection.
>> +ij.getPropertyArg(args);
>> +con = ij.startJBMS();
>> +   
>> +   
>> con.setAutoCommit(false); 
>> ++

Re: jdbcapi/testRelative failing & Derby-186

2005-04-07 Thread Satheesh Bandaram





I will take a look. I submitted the patch for Shreyas and made sure the
test passes on embedded driver, but didn't check Network framework.
Will do so now..

Satheesh

Daniel John Debrunner wrote:

  I'm seeing jdbcapi/testRelative failing when running with the IBM DB2
universal client and network server. This would seem to be related to
Derby-186. Is anyone looking at this to see if it's a test issue, IBM
DB2 driver issue or a Derby issue?

http://issues.apache.org/jira/browse/DERBY-186

Dan.


*** Start: testRelative jdk1.4.2_06 DerbyNet derbynetmats:jdbcapi
2005-04-07 11:45:44 ***
6 del
< isFirst=false isLast=false isAfterLast=true
7 del
< FAIL -- unexpected exception
8 del
< SQLSTATE(24000): SQL Exception: Invalid cursor state - no current row.
9 del
< SQL Exception: Invalid cursor state - no current row.
9 add
  
  
isFirst=false isLast=false isAfterLast=false
Value=work1

  
  Test Failed.
*** End:   testRelative jdk1.4.2_06 DerbyNet derbynetmats:jdbcapi
2005-04-07 11:46:01 ***

Re: UpdatableResultSet test failing ?

2005-04-12 Thread Satheesh Bandaram





Done... Let me know if you still have problems.

Satheesh

Myrna van Lunteren wrote:

  I've not tried this test on a solaris box (last time I tried on
solaris was before this test was added) but both the test & the .out
do not have the svn:eol-style property set. That c/would be the cause
of the problem.

Can one of the committers please set the svn:eol-style property to
native on the .java & the master .out file?

Thx...
Myrna


On Apr 12, 2005 9:52 AM, Shreyas Kaushik <[EMAIL PROTECTED]> wrote:
  
  
Hi all,

 I did a fresh check out of the Derby source on a Solaris box. When the
I ran the tests,  the updatableResultSet.java test failed as there were
"Control-M" characters at the end of every line. Is any one seeing this?

This could be a windoze problem as the file could have been checked in
from there.

~ Shreyas

Re: Is EXCEPT/INTERSECT complete?

2005-04-12 Thread Satheesh Bandaram





My understanding was that it was mostly complete, so do file a JIRA
entry with a test case. If you are interested in addressing the bug, I
could provide some ideas ... :-) 

Satheesh

Bernt M. Johnsen wrote:

  

  

  

  

  

  

  Andrew McIntyre wrote (2005-04-12 10:51:40):
  

  

  

  

  

  

On Mar 15, 2005 7:43 AM, Bernt M. Johnsen <[EMAIL PROTECTED]> wrote:


  Running the latest on trunk (svn update today), I get
NullPointerException when doing EXCEPT and INTERSECT in a view.

If the implementation is supposed to be complete, I'll create an
issue.


  

Hi Bernt,

Did you create an issue for this? 

  
  
No, I did not. I was wondering if the implementation was complete or
if there was some unfinished work underway. I did not get any answer
and forgot about the whole thing.

  
  
I couldn't seem to find it in Jira.
Your repro also failed in my sane/debug build, but with a more
informative error message:

ij> create view view1 as select * from tab1 intersect select * from tab2;
0 rows inserted/updated/deleted
ij> select * from view1;
ERROR XJ001: Java exception: 'ASSERT FAILED costEstimate is not
expected to be null for org.apache.derby.impl.sql.compile.SelectNode:
org.apache.derby.iapi.services.sanity.AssertFailure'.
ij> exit;

andrew

Availability of Derby client ...

2005-04-13 Thread Satheesh Bandaram

As Kathy Saunders
announced in February, IBM is contributing attached
Derby client to Apache Derby project. Derby client is a type 4 JDBC
client driver that is designed to work with Derby Network Server.

I am attaching:

High-level functional specification of Derby client. This
document covers functionality, driver and datasource properties,
setting up CLASSPATH, tracing support, security mechanism and testing
support.
Patch with changes to Derby build. (DerbyClientPatch.txt)
Since Derby client code base was too large to for an attachment,
it can be
downloaded from: DerbyClientSource.jar

To build Derby client,
(Below ${derby.source} refers to the root of your derby source)

Apply the patch DerbyClientPatch.txt.
Unjar DerbyClientSource.jar into ${derby.source}/java directory.
This should create a 'client' directory under ${derby.source}/java,
with org.apache.derby.jdbc and org.apache.derby.client packages and a
total of 116 java files under the client directory.
The client code is built as part of the standard derby build, and
the buildjars target will also create derbyclient.jar.

To perform a clean jar build, go to ${derby.source} and
then
ant clobber
ant
ant buildjars

After this, derbyclient.jar would be placed under 'sane' or
'insane' sub-directories of ${derby.source}/jars depending on your SANE
property value.

I call for a vote to accept Derby client by end of next week. (April
22nd)

I am very excited to have this submission!!! I vote +1 to accept this
as part of Derby.

Satheesh

Title: Derby Network Client

Derby Network Client

Last update: 4/11/05

Contents

Overview
Functionality
JDBC Driver and DataSource names
Ways to Connect using the Derby Client Driver
Data Source properties
Tracing

ClientDataSource Tracing Examples
DriverManager Tracing Examples
Changing the Default Trace Level

Security
Packaging, Distribution and Versioning

Comparision and/or differences with the Derby Embedded Driver
Effects to existing documentation
Miscellaneous

Overview
The Derby network client provides network connectivity to the Derby Network
Server. It is distributed as an additional jar file, derbyclient.jar, with an
entirely independent code base from the embedded driver.
The Derby network client is a type 4, JDBC compliant Driver, which attempts
to match the Derby Embedded JDBC driver as much as possible. Initially, it will
have some differences from the embedded driver, for example, some SQL States
will remain null and error messages will not be localized in the initial
offering. Hopefully, over time the functionality of the two drivers will
converge.

Functionality

All functionality for the Derby network client is packaged in the
derbyclient.jar file which will be added to the Derby distribution. The client
application needs only to include the new jar and application classes in its
classpath. derbyclient.jar has no dependencies on the tools, server, or derby database engine classes, nor do those classes depend on derbyclient.jar. Some new client classes are in the same package as the embedded driver, such as
org.apache.derby.jdbc.ClientDriver, but the actual classes are contained only in
the client jar file.
The Derby network client allows connections via JDBC URL using DriverManager by its implementations of JDBC20 data sources, javax.sql.DataSource, javax.sql.ConnectionPoolDataSource. An implementation of javax.sql.XADataSource is also provided for network XA Support.
The Derby network client provides a tracing facility to collect JDBC trace information and view protocol flows for debugging. Security mechanisms are also provided for user and password encryption.
DataSource properties and connection attributes can be used to enable tracing, as well as security settings.

Tools support for ij and dblook as well as test harness support is provided.

The sections that follow will describe the functionality and provide examples
of using each characteristic mentioned here.

JDBC Driver and DataSource names
The Derby network client classes and JDBC interfaces they implement are
listed below.

JDBC Interface
Derby network client class

java.sql.Driver
org.apache.derby.jdbc.ClientDriver

javax.sql.DataSource
org.apache.derby.jdbc.ClientDataSource

javax.sql.XADataSource
org.apache.derby.jdbc.ClientXADataSource

javax.sql.ConnectionPoolDataSource
org.apache.derby.jdbc.ClientConnectionPoolDataSource
Connection URL Format
The protocol for the client URL is jdbc:derby://. The embedded and client
attributes are specified the same way. The embedded driver has been changed to
reject URL's with a // following derby:
Derby network client URL Format
jdbc:derby://server[:port]/databaseName[;attributeKey=value]..

An example of using this URL to connect to the Derby network server running
on the localhost at port

Re: engine javadoc on the web

2005-04-14 Thread Satheesh Bandaram





This is really cool!... Thanks for getting this going.

Satheesh

Andrew McIntyre wrote:

  On 4/7/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
  
  
Andrew McIntyre wrote:



  There was some interest a while back about having the Derby engine
javadoc posted somewhere on the web.
  

It would be excellent to keep this updated automatically in a known place.

One addition needed would be a generation data and/or svn revision
number on the index page, or maybe in each header or footer.

  
  
I've set up a nightly sync of all the javadoc at the following URL,
per Jean's suggestion:

http://incubator.apache.org/derby/javadoc/

The sync should begin this evening. Engine javadoc specifically is here:

http://incubator.apache.org/derby/javadoc/engine/

I've also set up a nightly sync of built user documentation to:

http://incubator.apache.org/derby/docs/

Currently, the modification date on the directories at the URLs listed
above will give a general idea of how recently it was built, but I
will file JIRA entries for adding timestamps to both the javadoc and
userdoc build.

andrew

Re: Availability of Derby client ...

2005-04-15 Thread Satheesh Bandaram

Good catch... I will remove Microsoft Office headers...

Satheesh

Jeremy Boynes wrote:

> Myrna van Lunteren wrote:
>
>> I had used Mozilla's html editor when I created the file.
>> What's the Microsoft Office junk you refer to?
>>
>
> Stuff like that below taken from the patch ... the Microsoft
> proprietary markup makes editing the file difficult using a real HTML
> editor (like vi) which is what we will need to do going forward.
>
> ===
> --- java/testing/README.htm(revision 161156)
> +++ java/testing/README.htm(working copy)
> @@ -1,1189 +1,2159 @@
>  
> -
> + +xmlns:w="urn:schemas-microsoft-com:office:word"
> +xmlns:st1="urn:schemas-microsoft-com:office:smarttags"
> +xmlns="http://www.w3.org/TR/REC-html40";>
> +
>  
> -   - http-equiv="content-type">
> -  readme.htm
> +
> +
> +
> +
> +
> +readme.htm
> + namespaceuri="urn:schemas-microsoft-com:office:smarttags"
> + name="date"/>
> + namespaceuri="urn:schemas-microsoft-com:office:smarttags"
> + name="City"/>
> + namespaceuri="urn:schemas-microsoft-com:office:smarttags"
> + name="State"/>
> + namespaceuri="urn:schemas-microsoft-com:office:smarttags"
> + name="place"/>
> + namespaceuri="urn:schemas-microsoft-com:office:smarttags"
> + name="time"/>
> +

Re: how to specify join strategy and index

2005-04-16 Thread Satheesh Bandaram

Derby doesn't have a way specify join strategy or index. There has been
some discussion on this topic in the past, but currently Derby doesn't
support 'optimizer-hints' or 'optimizer-overrides'. Some of the previous
postings include:

http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200412.mbox/[EMAIL 
PROTECTED]
http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200412.mbox/[EMAIL 
PROTECTED]
http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200412.mbox/[EMAIL 
PROTECTED]

Satheesh

?? ? wrote:

> Hi, developers
>
>> From the documentation, we know if we don't like the join strategy
>> and index 
>
> choosed by derby system for us, users can speicfy their own.
>
> But how to specify join strategy or index when querying over derby?
> in query statement? or anywhere else?
>
> If anyone konw, please give me an exmaple.
> Thanks.
>
> _
> Express yourself instantly with MSN Messenger! Download today it's
> FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
>

[VOTE] accept derby client contribution

I just realized I called for a vote to accept Derby client without the
[VOTE] subject header, in the middle of a longish email. I would like to
reissue the call for vote. I call for all those who voted already to
vote again, please...

[ ] +1: Accept the contribution of the derby client
[ ] -1: Reject the contribution of the derby client

The voting is open till end of  22nd April, 2004. (GMT)

Satheesh

Re: [VOTE] accept derby client contribution

[X] +1: Accept the contribution of the derby client

Satheesh

Satheesh Bandaram wrote:

>I just realized I called for a vote to accept Derby client without the
>[VOTE] subject header, in the middle of a longish email. I would like to
>reissue the call for vote. I call for all those who voted already to
>vote again, please...
>
>[ ] +1: Accept the contribution of the derby client
>[ ] -1: Reject the contribution of the derby client
>
>The voting is open till end of  22nd April, 2004. (GMT)
>
>Satheesh
>
>
>
>
>  
>

Re: Availability of Derby client ...





Thanks Myrna. If Derby client vote is accepted, I will apply your
changes as a patch to original Derby README file.

Satheesh

Myrna van Lunteren wrote:

  Hi Satheesh, Jeremy,

I looked at the changed java/testing/README.htm, & felt we should
replace the references to DerbyNet framework with DerbyNetClient in a
couple more places.
While I was at it, I also changed some of the notes. 

So, here is an updated README.htm to go with the DerbyClient offering. 
I started from the original, so this has no MS references.

Myrna

On 4/15/05, Satheesh Bandaram <[EMAIL PROTECTED]> wrote:
  
  
Good catch... I will remove Microsoft Office headers...

Satheesh

Jeremy Boynes wrote:



  Myrna van Lunteren wrote:

  
  
I had used Mozilla's html editor when I created the file.
What's the Microsoft Office junk you refer to?


  
  Stuff like that below taken from the patch ... the Microsoft
proprietary markup makes editing the file difficult using a real HTML
editor (like vi) which is what we will need to do going forward.

===
--- java/testing/README.htm(revision 161156)
+++ java/testing/README.htm(working copy)
@@ -1,1189 +1,2159 @@
 
-
+"http://www.w3.org/TR/REC-html40">
+
 
-  
-  readme.htm
+
+
+
+
+
+readme.htm
+
+
+
+
+
+>
  
  

Index: java/testing/README.htm
===
--- java/testing/README.htm	(revision 161498)
+++ java/testing/README.htm	(working copy)
@@ -13,7 +13,7 @@
 
 
 created by [EMAIL PROTECTED]
-last updated on 12/02/2004 by: [EMAIL PROTECTED]
+last updated on 04/18/2005 by: [EMAIL PROTECTED]
 
 
 
@@ -90,7 +90,9 @@
 Before you can run, you need to setup your environment:
 
 
-  Obtain a jdk or jre (based on jdk 1.3.1 specification or higher).
+  Obtain a jdk or jre (based on jdk 1.3.1 specification See Note1 or
+higher).
 Add the bin directory to your $PATH. Currently supported are:
   
 
@@ -134,9 +136,11 @@
     derby tools classes for tools like ij
 and dblookderbynet.jar
   
-    derby network server classesdb2jcc.jar
-and db2jcc_license_c.jar 
+    derby network server classesderbyclient.jar
   
+    derby client classesdb2jcc.jar
+and db2jcc_license_c.jar
+  
     IBM Universal JDBC Driver classes. (See
 IBM "http://www-106.ibm.com/developerworks/db2/downloads/jcc/">developerworks
 for download)
@@ -158,12 +162,14 @@
   
 
   (note that $jardir is
-only a convenience variable and that the command below has carriage
+only a convenience variable and that the set CLASSPATH command below
+has carriage
 returns for formatting reasons):
   set jardir=/local/derbyjar
 set
-CLASSPATH="$jardir/derby.jar:$jardir/derbytools.jar:$jardir/derbynet.jar:$jardir/db2jcc.jar:
-$jardir/db2jcc_license_c.jar:$jardir/derbyTesting.jar:/local/derby/tools/java/jakarta-oro-2.0.8.jar:
+CLASSPATH="$jardir/derby.jar:$jardir/derbytools.jar:$jardir/derbynet.jar:$jardir/derbyclient.jar:
+$jardir/db2jcc.jar:$jardir/db2jcc_license_c.jar:
+$jardir/derbyTesting.jar:/local/derby/tools/java/jakarta-oro-2.0.8.jar:
 $jardir/derbyLocale_de_DE.jar:$jardir/derbyLocale_es.jar:$jardir/derbyLocale_fr.jar:
 $jardir/derbyLocale_it.jar:$jardir/derbyLocale_ja_JP.jar:$jardir/derbyLocale_ko_KR.jar:
 $jardir/derbyLocale_pt_BR.jar:$jardir/derbyLocale_zh_CN.jar:$jardir/derbyLocale_zh_TW.jar:
@@ -205,12 +211,13 @@
 org.apache.derbyTesting.functionTests.harness.RunTest
 lang/supersimple.sql
   
-To run a test with network server, add -Dframework=DerbyNet to the run.
+To run a test with network server, using the derbyclient driver, add
+-Dframework=DerbyNetClient to the run.
 The test harness will to start
 network server at port 1527 or connect to a running one, run the test,
 and stop network server thereafter.
 for example:
-        java -Dframework=DerbyNet
+        java -Dframework=DerbyNetClient
   org.apache.derbyTesting.functionTests.harness.RunTest
 lang/supersimple.sql

@@ -275,16 +282,24 @@
 tested on a variety of hardware takes from 1.15m to 2.00 hours
 
   
+  derbynetclientmats
+  
+basic network server tests using the derby client
+
+variety of tests, including some from derbylang suite
+tested on a variety of hardware takes from 15 to 30 minutes
+  
   derbynetmats
   
-basic network server tests.
+basic network server tests using the IBM Universal JDBC driver
+
 variety of tests, including some from derbylang suite
 tested on a variety of hardware takes from 15 to 30 minutes
   
   derbynetautostart
   
-tests networkserver functionality without requiring
-networkserver framework
+tests network server functionality without requiring
+network server framework
 
   
   propertyinfo
@@ -424,7 +439,8 @@
   
   i18nTest
   
-tests that characters outside simple ascii scope do not

Re: [jira] Commented: (DERBY-229) Column names on ResultSet.updateXXX and getXXX methods are handled incorrectly





Looks like this bug has all the information needed to reproduce and to
generate a patch. Is there any interest to submit a patch for this
relatively easy fix? A complete patch would include a fix, along the
general idea provided here and a test case added to jdbcapi test suite.
Good opportunity for anyone wanting to get started modifying Derby
code. Any volunteers?  :-) 

I am willing to help, if needed.

Satheesh

Mamta A. Satoor (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/DERBY-229?page=comments#action_63128 ]
 
Mamta A. Satoor commented on DERBY-229:
---

The getter [updater] methods with column names (in EmbedResultSet.java) use the protected method findColumnName(String columnName) to determine the column index for the passed column name. And the loop for the lookup starts from the end towards the beginning of the ResultDescription and that seems to be the problem behind the current behavior. 
	ResultDescription rd = resultDescription;

	// 1 or 0 based? assume 1 (probably wrong)
	for (int i=rd.getColumnCount(); i>=1; i--) {

		String name = rd.getColumnDescriptor(i).getName();
		if (StringUtil.SQLEqualsIgnoreCase(columnName, name)) {
			return i;
		}
	}


  
  
Column names on ResultSet.updateXXX and getXXX methods are handled incorrectly
--

 Key: DERBY-229
 URL: http://issues.apache.org/jira/browse/DERBY-229
 Project: Derby
Type: Bug
  Components: JDBC
Versions: 10.1.0.0, 10.0.2.1
Reporter: Daniel John Debrunner
 Attachments: x.java

Sections 14.2.3 and [14.2.3] of JDBC 3.0 spec say
Column names supplied to getter [updater] methods are case insensitive. If a select list
contains the same column more than once, the first instance of the column will be
returned [updated].
Derby returns or updates the last column in the select list, not the first. With the attached Java class I see
PRE-UPDATE
1,100
POST-UPDATE
1,500
POST-UPDATE getXXX(name)
AB:500,ab500

Re: [PATCH] Re: [jira] Updated: (DERBY-219) EXCEPT/INTERSECT fails in views

2005-04-21 Thread Satheesh Bandaram





Submitted this patch.

Satheesh

Sending   
java\engine\org\apache\derby\impl\sql\compile\IntersectOrExceptNode.java
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\intersect.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\intersect.sql
Transmitting file data ...
Committed revision 162098.

Jack Klebanoff wrote:
I have
made a fix for the problem. Actually the bug affects any subquery, not
just a view.
  
  
The fix includes an expanded lang/intersect.sql test. The fix passes
the derbylang test suite.
  
  
The patch is included here and in Jira.
  
  
Jack Klebanoff
  
  

Index: java/engine/org/apache/derby/impl/sql/compile/IntersectOrExceptNode.java
===
--- java/engine/org/apache/derby/impl/sql/compile/IntersectOrExceptNode.java	(revision 161138)
+++ java/engine/org/apache/derby/impl/sql/compile/IntersectOrExceptNode.java	(working copy)
@@ -224,6 +224,18 @@
   RowOrdering rowOrdering)
   throws StandardException
 {
+		leftResultSet = optimizeSource(
+			optimizer,
+			leftResultSet,
+			(PredicateList) null,
+			outerCost);
+
+		rightResultSet = optimizeSource(
+			optimizer,
+			rightResultSet,
+			(PredicateList) null,
+			outerCost);
+
 		CostEstimate costEstimate = getCostEstimate(optimizer);
 CostEstimate leftCostEstimate = leftResultSet.getCostEstimate();
 CostEstimate rightCostEstimate = rightResultSet.getCostEstimate();
Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/intersect.sql
===
--- java/testing/org/apache/derbyTesting/functionTests/tests/lang/intersect.sql	(revision 161138)
+++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/intersect.sql	(working copy)
@@ -143,3 +143,20 @@
 -- Invalid order by
 select id,i1,i2 from t1 intersect select id,i1,i2 from t2 order by t1.i1;
 select id,i1,i2 from t1 except select id,i1,i2 from t2 order by t1.i1;
+
+-- views using intersect and except
+create view view_intr_uniq as select id,i1,i2 from t1 intersect select id,i1,i2 from t2;
+select * from view_intr_uniq order by 1 DESC,2,3;
+
+create view view_intr_all as select id,i1,i2 from t1 intersect all select id,i1,i2 from t2;
+select * from  view_intr_all order by 1,2,3;
+
+create view view_ex_uniq as select id,i1,i2 from t1 except select id,i1,i2 from t2;
+select * from view_ex_uniq order by 1,2,3;
+
+create view view_ex_all as select id,i1,i2 from t1 except all select id,i1,i2 from t2;
+select * from view_ex_all order by 1 DESC,2,3;
+
+-- intersect joins
+select t1.id,t1.i1,t2.i1 from t1 join t2 on t1.id = t2.id
+intersect select t1.id,t1.i2,t2.i2 from t1 join t2 on t1.id = t2.id;
Index: java/testing/org/apache/derbyTesting/functionTests/master/intersect.out
===
--- java/testing/org/apache/derbyTesting/functionTests/master/intersect.out	(revision 161138)
+++ java/testing/org/apache/derbyTesting/functionTests/master/intersect.out	(working copy)
@@ -350,4 +350,44 @@
 ERROR 42877: A qualified column name 'T1.I1' is not allowed in the ORDER BY clause.
 ij> select id,i1,i2 from t1 except select id,i1,i2 from t2 order by t1.i1;
 ERROR 42877: A qualified column name 'T1.I1' is not allowed in the ORDER BY clause.
+ij> -- views using intersect and except
+create view view_intr_uniq as select id,i1,i2 from t1 intersect select id,i1,i2 from t2;
+0 rows inserted/updated/deleted
+ij> select * from view_intr_uniq order by 1 DESC,2,3;
+ID |I1 |I2 
+---
+5  |NULL   |NULL   
+2  |1  |2  
+1  |1  |1  
+ij> create view view_intr_all as select id,i1,i2 from t1 intersect all select id,i1,i2 from t2;
+0 rows inserted/updated/deleted
+ij> select * from  view_intr_all order by 1,2,3;
+ID |I1 |I2 
+---
+1  |1  |1  
+2  |1  |2  
+5  |NULL   |NULL   
+ij> create view view_ex_uniq as select id,i1,i2 from t1 except select id,i1,i2 from t2;
+0 rows inserted/updated/deleted
+ij> select * from view_ex_uniq order by 1,2,3;
+ID |I1 |I2 
+---
+3  |1  |3  
+4  |1  |3  
+6  |NULL   |NULL   
+ij> create view view_ex_all as select id,i1,i2 from t1 except all select id,i1,i2 from t2;
+0 rows inserted/updated/deleted
+ij> select * from view_ex_all order by 1 DESC,2,3;
+ID |I1 |I2 
+---
+6  |NULL   |NULL   
+4  |1  |3  
+3  |1  |3  
+ij> -- intersect joins
+select t1.id,t1.i1,t2

Re: [PATCH] Some small test change for Network Server

2005-04-22 Thread Satheesh Bandaram





Committed this patch.

Satheesh

Sending   
java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\holdCursorIJ.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\scrollCursors1.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\holdCursorIJ.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\scrollCursors1.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\holdCursorIJ.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\scrollCursors1.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\holdCursorIJ.sql
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\scrollCursors1.sql
Transmitting file data .
Committed revision 164284.
[bandaram:satheesh]

Army wrote:
Attached
is a small patch that does the following two things:
  
  
1) Changes the "lang/holdCursorIJ.sql" and "lang/scrollCursors1.sql"
tests to clean up after each test case (by closing any opened
cursors).  Without this cleanup, some later versions of JCC can show
false failures for these two tests.
  
  
2) Adds a "sed" filter to the harness that will filter out some
unwanted JCC text that can be appended to certain error messages.  This
text isn't related to the actual errors in question and thus looks to
be irrelevant.  By filtering it out, we can avoid some false failures
that can occur with later versions of JCC.
  
  
Could a committer please commit?
  
  
Thanks,
  
Army
  
  

Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/scrollCursors1.sql
===
--- java/testing/org/apache/derbyTesting/functionTests/tests/lang/scrollCursors1.sql	(revision 164154)
+++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/scrollCursors1.sql	(working copy)
@@ -233,6 +233,7 @@
 update t1 set i = 666 where i = 2;
 first c1;
 rollback;
+close c1;
 
 -- verify that statement cache works
 -- correctly with scroll and forward only
Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/holdCursorIJ.sql
===
--- java/testing/org/apache/derbyTesting/functionTests/tests/lang/holdCursorIJ.sql	(revision 164154)
+++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/holdCursorIJ.sql	(working copy)
@@ -34,6 +34,10 @@
 close jdk4;
 next jdk4;
 
+-- clean up.
+close jdk1;
+close jdk2;
+
 -- second test - make sure that all the cursors (including holdability true)
 -- have their resultsets closed after rollback.
 
@@ -56,6 +60,11 @@
 next jdk2;
 next jdk4;
 
+-- clean up.
+close jdk1;
+close jdk2;
+close jdk4;
+
 -- third test - Define a hold cursor on a table. Shouldn't be able to drop that
 -- table before & after commit. Have to close the cursor before table can be dropped.

@@ -74,6 +83,9 @@
 close jdk4;
 drop table t1;
 
+-- clean up.
+close jdk1;
+
 -- recreate and populate the table for next test
 create table t1(c11 int, c12 int);
 insert into t1 values(1,1);
@@ -98,6 +110,9 @@
 close jdk4;
 set isolation to serializable;
 
+-- clean up.
+close jdk1;
+
 -- fifth test - try isolation level change alongwith changing the isolation
 -- level of just one statement
 get with hold cursor jdk4 as 'SELECT * FROM t1';
@@ -113,6 +128,9 @@
 set isolation READ UNCOMMITTED;
 set isolation RS;
 
+-- clean up.
+close jdk1;
+
 -- sixth test - try positioned update with hold cursor
 get with hold cursor jdk4 as 'SELECT * FROM t1 FOR UPDATE';
 -- following should give error because cursor is not positioned on any row
@@ -186,5 +204,8 @@
 next scrollCursor;
 update t1 set c12=c12+1 where current of scrollCursor;
 
+-- clean up.
+close scrollCursor;
 
 
+
Index: java/testing/org/apache/derbyTesting/functionTests/harness/Sed.java
===
--- java/testing/org/apache/derbyTesting/functionTests/harness/Sed.java	(revision 164154)
+++ java/testing/org/apache/derbyTesting/functionTests/harness/Sed.java	(working copy)
@@ -178,6 +178,10 @@
 		//Filter to suppress absould paths in error message for roll forward recovery tests 
 		searchStrings.addElement("Directory.*.wombat.already.exists");
 
+// Filter for "DB2ConnectionCorrelator" text that can be printed as
+// part of some JCC error messages.
+searchStrings.addElement("  DB2ConnectionCorrelator: [0-9A-Z.]*");
+
 Vector subStrings = new Vector();
 subStrings.addElement("");
 subStrings.addElement("");
@@ -222,6 +226,8 @@
 			subStrings.addElement("-");
 		}
 		subStrings.addElement("Directory DBLOCATION/wombat already exists");
+		// ignore the 'DB2ConnectionCorrelator' thing altogether.
+		subStrings.addElement("");
 		doWork(srcFile

Re: [PATCH] upgrade fix related to checksum support for transaction log to recognize out of order log writes during recovery (Derby-96)

2005-04-25 Thread Satheesh Bandaram





I wish eventually we could consolidate all the version checking logic
in one place, common to the whole engine. Current Derby client patch
has similar logic, in package org.apache.derby.client.am.ProductLevel,
though this is also used for other purpose.

Satheesh

Suresh Thalamati wrote:

Attached is the  new  patch  with the suggested changes to make
softupgrade correctly with the  transaction log
  
checksum feature in 10.1 Added  checkVersion() method  to log factory
it self,  becuase that is where
  
the  version numbers are read  from  from the log control file , but
did not export the call it to  the
  
rawstore factory  as it is not needed now.  (This can be done easlily
when there is a  need for upgrade
  
checks  in the other store modules..)
  
  
Thanks
  
-suresht
  
  
  
Mike Matrigali wrote:
  
  
  Ok, that is the info I needed.  Suresh could
you resubmit the change

with comments like the one dan has below.  And change the check to

simply check if the on disk version is is 10.0, no need to check

current version.


It would be nice to have some sort of store facility like the one

language has, but the problem for this case is that logging system

needs it during boot and there is not much else available until boot

is finished.




Daniel John Debrunner wrote:


Mike Matrigali wrote:
  
  
  
  Given that Dan is working on the upgrade
stuff, I think the change below

handles the current, and next release fine.  More changes can be made

as it becomes clear how rest of code is handling soft upgrade.


Going forward I would like to see a better model for the code below.
For

this discussion assume current release is 10.0.x and next 2 releases

are 10.1.x and 10.2.x.  If derby supports soft upgrade from 10.0.x

directly to 10.2.x then the code below will have to change, meaning

someone is going to have to remember to change it (maybe a sanity

statement could force an error if version is not what is expected?):

  
  
  
  
Soft upgrade is expected to work on any previous release, and the code
  
to handle it should work without having to change every release.
  
  
Take a language feature that was added in release X and cannot be used
  
in soft upgrade mode because it writes new information to the system
  
catalogs, that would not be understood by releases earlier than X.
  
  
The language layer handles this by checking that the database (on disk)
  
has been upgraded to at least release X before allowing compilation or
  
execution of the feature, by calling the method
  
DataDictionary.checkVersion().
  
  
E.g. for a routine with a method signature (new in 10.1) this check is
  
made (I'm just about to commit this code).
  
  
// Support for Java signatures in Derby was added in 10.1
  
// Check to see the catalogs have been upgraded to 10.1 before
  
// accepting such a method name for a routine. Otherwise
  
// a routine that works in 10.1 soft upgrade mode would
  
// exist when running 10.0 but not resolve to anything.
  
  
if (this.methodName.indexOf('(') != -1)
  
{
  
  getDataDictionary().checkVersion(
  
 DataDictionary.DD_VERSION_DERBY_10_1,
  
   "EXTERNAL NAME 'class.method()'");
  
  
}
  
  
This style of check will work with any future version so it's a safe
  
approach.
  
  
The store layer needs to have a similar policy.
  
  
Dan.
  
  
  
  



  
  
  

Index: java/engine/org/apache/derby/impl/store/raw/log/LogAccessFile.java
===
--- java/engine/org/apache/derby/impl/store/raw/log/LogAccessFile.java	(revision 164300)
+++ java/engine/org/apache/derby/impl/store/raw/log/LogAccessFile.java	(working copy)
@@ -35,6 +35,7 @@
 
 import org.apache.derby.iapi.services.io.FormatIdOutputStream;
 import org.apache.derby.iapi.services.io.ArrayOutputStream;
+import org.apache.derby.iapi.store.raw.RawStoreFactory;
 
 
 /**
@@ -116,7 +117,7 @@
 	private long checksumInstant = -1;
 	private int checksumLength;
 	private int checksumLogRecordSize;  //checksumLength + LOG_RECORD_FIXED_OVERHEAD_SIZE
-	private boolean writeChecksum = true;  //gets set to false incase of a soft upgrade.
+	private boolean writeChecksum; 
 	private ChecksumOperation checksumLogOperation;
 	private LogRecord checksumLogRecord;
 	private LogToFile logFactory;
@@ -152,7 +153,14 @@
 }
 
 		currentBuffer = (LogAccessFileBuffer) freeBuffers.removeFirst();
-
+		
+		// Support for Transaction Log Checksum in Derby was added in 10.1
+		// Check to see if the Store have been upgraded to 10.1 or later before
+		// writing the checksum log records.  Otherwise recovery will fail
+		// incas

[RESULT] [VOTE] accept derby client contribution

2005-04-26 Thread Satheesh Bandaram

Passed, with nine +1 votes and no -1 vote. However, Derby client checkin
into trunk may get delayed, pending resolution of CCLA discussion,
initialied by Geir:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
PROTECTED]

Follow up questions from Ken and Dan are pending still:
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
PROTECTED]
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
PROTECTED]

Satheesh

--- Begin Message ---
I just realized I called for a vote to accept Derby client without the
[VOTE] subject header, in the middle of a longish email. I would like to
reissue the call for vote. I call for all those who voted already to
vote again, please...

[ ] +1: Accept the contribution of the derby client
[ ] -1: Reject the contribution of the derby client

The voting is open till end of  22nd April, 2004. (GMT)

Satheesh




--- End Message ---

Re: [PATCH] Conversions to Date and Timestamp

2005-04-26 Thread Satheesh Bandaram





Submitted this patch. Nicely done patch. I added new
UnaryDateTimestampOperatorNode to the list of  nodes in
DBMSnodes.properties, so that Derby JAR build will pick up the class.
Otherwise, I suspect tests on JAR build might fail.

Satheesh

Sending    java\engine\org\apache\derby\iapi\reference\SQLState.java
Sending   
java\engine\org\apache\derby\iapi\sql\compile\C_NodeTypes.java
Sending   
java\engine\org\apache\derby\iapi\types\DataValueFactory.java
Sending   
java\engine\org\apache\derby\iapi\types\DataValueFactoryImpl.java
Sending    java\engine\org\apache\derby\iapi\types\SQLDate.java
Sending    java\engine\org\apache\derby\iapi\types\SQLTime.java
Sending    java\engine\org\apache\derby\iapi\types\SQLTimestamp.java
Sending   
java\engine\org\apache\derby\impl\sql\compile\C_NodeNames.java
Sending   
java\engine\org\apache\derby\impl\sql\compile\NodeFactoryImpl.java
Adding
java\engine\org\apache\derby\impl\sql\compile\UnaryDateTimestampOperatorNode.java
Sending   
java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
Sending    java\engine\org\apache\derby\loc\messages_en.properties
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\datetime.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\datetime.sql
Sending    tools\jar\DBMSnodes.properties
Transmitting file data ...
Committed revision 164873.

Jack Klebanoff wrote:
The
attached path contains some fixes to conversions to dates and
timestamps.
  
1. According to the Derby documentation the DATE and TIMESTAMP
functions provide some conversions beyond those handled by the normal
casts. This patch implements them. The DATE function converts a numeric
argument to a date by taking the integer portion of the number and
considering it as the number of days since Jan. 1 1970. The DATE
function also handles a string of length 7 in the format 'ddd'. It
is taken to indicate the ddd'th day of year . The TIMESTAMP
function handles string arguments of length 14 in the format
'MMddhhmmss'. Any other arguments to the DATE and TIMESTAMP
functions are handled as normal casts to date or timestamp.
  
  
(The TIME function does not do any special conversions. It is the same
as the CAST function).
  
  
2. The string to time cast has been made more lenient by making the
seconds field optional.
  
  
Previously the DATE and unary TIMESTAMP functions were implemented by
converting them to calls to CAST. This was done in the parser. The
patch changes this. The parser now generates a
UnaryDateTimestampOperatorNode to represent these functions. The
generated code calls new DataValueFactory methods. Most of the actual
work is done in the SQLDate and SQLTimestamp classes.
  
  
The patch passed the derbyall suite.
  
  
Jack Klebanoff
  
  

Index: java/engine/org/apache/derby/impl/sql/compile/NodeFactoryImpl.java
===
--- java/engine/org/apache/derby/impl/sql/compile/NodeFactoryImpl.java	(revision 164436)
+++ java/engine/org/apache/derby/impl/sql/compile/NodeFactoryImpl.java	(working copy)
@@ -554,6 +554,9 @@
 		  case C_NodeTypes.SAVEPOINT_NODE:
 		  	return C_NodeNames.SAVEPOINT_NODE_NAME;
 
+  case C_NodeTypes.UNARY_DATE_TIMESTAMP_OPERATOR_NODE:
+return C_NodeNames.UNARY_DATE_TIMESTAMP_OPERATOR_NODE_NAME;
+
 		  case C_NodeTypes.TIMESTAMP_OPERATOR_NODE:
 return C_NodeNames.TIMESTAMP_OPERATOR_NODE_NAME;
 
Index: java/engine/org/apache/derby/impl/sql/compile/UnaryDateTimestampOperatorNode.java
===
--- java/engine/org/apache/derby/impl/sql/compile/UnaryDateTimestampOperatorNode.java	(revision 0)
+++ java/engine/org/apache/derby/impl/sql/compile/UnaryDateTimestampOperatorNode.java	(revision 0)
@@ -0,0 +1,196 @@
+/*
+
+   Derby - Class org.apache.derby.impl.sql.compile.UnaryDateTimestampOperatorNode
+
+   Copyright 2004 The Apache Software Foundation or its licensors, as applicable.
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+
+ */
+
+package	org.apache.derby.impl.sql.compile;
+
+import org.apache.derby.iapi.types.DataValueFactory;
+import org.apache.derby.iapi.types.DataTypeDescriptor;
+import org.apache.derby.iapi.types.DataValueDescriptor;
+import org.apache.derby.iapi.types.DateTimeDataValue;
+import org.apache.derby.iapi.services.compiler.MethodBuilder;
+import org.

Re: [jira] Commented: (DERBY-229) Column names on ResultSet.updateXXX and getXXX methods are handled incorrectly

2005-04-27 Thread Satheesh Bandaram

Cool. Thanks! Let me know if I can help.

Satheesh

Shreyas Kaushik wrote:

> I will start looking at this. I volunteer ;-)
>
> ~ Shreyas
>
> Satheesh Bandaram wrote:
>
>> Looks like this bug has all the information needed to reproduce and
>> to generate a patch. Is there any interest to submit a patch for this
>> relatively easy fix? A complete patch would include a fix, along the
>> general idea provided here and a test case added to jdbcapi test
>> suite. Good opportunity for anyone wanting to get started modifying
>> Derby code. Any volunteers? :-)
>>
>> I am willing to help, if needed.
>>
>> Satheesh
>>
>> Mamta A. Satoor (JIRA) wrote:
>>
>>> [
>>> http://issues.apache.org/jira/browse/DERBY-229?page=comments#action_63128
>>> ]
>>> Mamta A. Satoor commented on DERBY-229:
>>> ---
>>>
>>> The getter [updater] methods with column names (in
>>> EmbedResultSet.java) use the protected method findColumnName(String
>>> columnName) to determine the column index for the passed column
>>> name. And the loop for the lookup starts from the end towards the
>>> beginning of the ResultDescription and that seems to be the problem
>>> behind the current behavior. ResultDescription rd =
>>> resultDescription;
>>>
>>>// 1 or 0 based? assume 1 (probably wrong)
>>>for (int i=rd.getColumnCount(); i>=1; i--) {
>>>
>>>String name = rd.getColumnDescriptor(i).getName();
>>>if (StringUtil.SQLEqualsIgnoreCase(columnName, name)) {
>>>return i;
>>>}
>>>}
>>>
>>>
>>>  
>>>
>>>> Column names on ResultSet.updateXXX and getXXX methods are handled
>>>> incorrectly
>>>> --
>>>>
>>>>
>>>> Key: DERBY-229
>>>> URL: http://issues.apache.org/jira/browse/DERBY-229
>>>> Project: Derby
>>>>Type: Bug
>>>>  Components: JDBC
>>>>Versions: 10.1.0.0, 10.0.2.1
>>>>Reporter: Daniel John Debrunner
>>>> Attachments: x.java
>>>>
>>>> Sections 14.2.3 and [14.2.3] of JDBC 3.0 spec say
>>>> Column names supplied to getter [updater] methods are case
>>>> insensitive. If a select list
>>>> contains the same column more than once, the first instance of the
>>>> column will be
>>>> returned [updated].
>>>> Derby returns or updates the last column in the select list, not
>>>> the first. With the attached Java class I see
>>>> PRE-UPDATE
>>>> 1,100
>>>> POST-UPDATE
>>>> 1,500
>>>> POST-UPDATE getXXX(name)
>>>> AB:500,ab500
>>>>   
>>>
>>>
>>>  
>>>
>
>
>

Re: Timing code in Derby

2005-04-27 Thread Satheesh Bandaram

That information can be seen using system procedures to get runtime
statistics. You can set statistics gathering using
SYSCS_SET_RUNTIMESTATISTICS() and get the statistics gathered after a
query is executed using SYSCS_GET_RUNTIMESTATISTICS(). There should be
more info about these in Derby manuals or you can check out some test
cases in 'lang' test directory.

Satheesh

Shreyas Kaushik wrote:

> Hi all,
>
>   I have seen code like the following lines in many places in Derby code.
>
>  *beginTime = getCurrentTimeMillis()*  and  *openTime +=
> getElapsedTime(beginTime).
> *
> I presume these methods are used to calculate the time taken to
> perform some operation like a fetch, open, etc. Is this information
> stored anywhere in the logs ? I could not see this anywhere. Is there
> something extra ( a parameter setting or some properties file) that
> needs to be done to enable this and see the results?
>
> ~ Shreyas
>
>
>
>

Re: [RESULT] [VOTE] accept derby client contribution

2005-04-28 Thread Satheesh Bandaram

Submitted Derby client source to trunk. Post any problems you notice
with Derby client.

Enjoy! Please use the functional spec for usage. I will work with Jean
to host it at Derby website.

Satheesh

Kathy Saunders wrote:

> Satheesh Bandaram wrote:
>
>> Passed, with nine +1 votes and no -1 vote. However, Derby client checkin
>> into trunk may get delayed, pending resolution of CCLA discussion,
>> initialied by Geir:
>> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
>> PROTECTED]
>>
>>
>> Follow up questions from Ken and Dan are pending still:
>> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
>> PROTECTED]
>>
>> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL 
>> PROTECTED]
>>
>>
>> Satheesh
>>  
>>
> Hi,
>
> IBM faxed an amended CCLA, which includes the contribution of the
> Derby client, to Apache this morning.
>
> Kathy
>
>
>

Derby client bugs ...

2005-04-28 Thread Satheesh Bandaram

I have created a new 'Network Client' component in Jira for Derby
project. If you encounter a bug with Derby client, either post it to
this alias or file it in Jira under this component.

Satheesh

Re: [jira] Assigned: (DERBY-13) Quoted names with embedded period mishandled in from list

U are correct... I think both of them seem to have been fixed, based on
the test case in the defect. I will close both of them, if everyone agrees.

Satheesh

Shreyas Kaushik wrote:

> I thought this was patched ??
>
> ~ Shreyas
>
> Jack Klebanoff (JIRA) wrote:
>
>> [ http://issues.apache.org/jira/browse/DERBY-13?page=all ]
>>
>> Jack Klebanoff reassigned DERBY-13:
>> ---
>>
>>Assign To: Jack Klebanoff
>>
>>  
>>
>>> Quoted names with embedded period mishandled in from list
>>> -
>>>
>>> Key: DERBY-13
>>> URL: http://issues.apache.org/jira/browse/DERBY-13
>>> Project: Derby
>>>Type: Bug
>>>  Components: SQL
>>>Versions: 10.0.2.0
>>>Reporter: Ramandeep Kaur
>>>Assignee: Jack Klebanoff
>>>Priority: Minor
>>> Attachments: Derby-13.diff, Derby-13.patch, derbylang_report.txt
>>>
>>> Opening this bug on behalf of Satheesh Bandaram
>>> -
>>> The compiler mishandles quoted names with embedded periods when
>>> checking uniqueness of table names in the from list of a SELECT.
>>> Consider the following SQL:
>>>  create table "S1.T1" (id int not null primary key, d1 int);
>>>  create schema s1;
>>>  create table s1.t1 (id int not null primary key, d2 int);
>>>  select * from s1.t1, "S1.T1" where s1.t1.id = "S1.T1".id;
>>> Derby throws an error on the final SELECT statement:
>>> "ERROR 42X09: The table or alias name 'S1.T1' is used more than once
>>> in the FROM list". However s1.t1 and "S1.T1" are different tables.
>>>   
>>
>>
>>  
>>
>
>
>

Re: [PATCH] Derby-250 With client setObject( parameterIndex, x, java.sql.DOUBLE) throws conversion exception if the object passed is a BigDecimal with more than 31 digits





+1. I suspect the change to TestRelative is for some other purpose, but
that looks right too. Not sure if Shreyas was going to checkin that
part, though.

Satheesh

Kathey Marsden wrote:

  This is a patch for Derby-250 to eliminate the conversion error when a
BigDecimal with more than
31 digits is  passed to setObject  with a targetSqlType.
public void setObject(int parameterIndex,
  Object x,
  int targetSqlType)
   throws SQLException
or
public void setObject(int parameterIndex,
  Object x,
  int targetSqlType,
  int scale)
   throws SQLException

The approach of the patch is to have setObject calls with a
targetSqlType  to always convert before sending to the value to the
server for all types.

Taking this approach exposed other issues with  the client's conversion
mechanism for Date, Time and Timestamp,
which were customized valueOf  methods to support ISO format.   Since
the extended format is not needed for Derby, I replaced these with the
standard .valueOf calls.

The patch also fixes issues with scale getting set properly when
specified for these calls.

I'll commit this afternoon if there are no objections.

Thanks

Kathey


  
  

Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
===
--- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java	(revision 165209)
+++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java	(working copy)
@@ -8,32 +8,34 @@
 
 public class testRelative {

-   static final String EXPECTED_SQL_STATE = "24000";
-   static Connection con;
-   static ResultSet rs;
-   static PreparedStatement stmt = null;
-   static PreparedStatement pStmt = null;
-   static Statement stmt1 = null;
-   static String returnValue = null;
-
+   static final String NO_CURRENT_ROW_SQL_STATE = "24000";
+  
public static void main(String[] args) {
-test1(args);
+	   System.out.println("Test testRelative starting");
+	   Connection con = null;
+	   try {
+		   // use the ij utility to read the property file and
+		   // make the initial connection.
+		   ij.getPropertyArg(args);
+		   con = ij.startJBMS();
+		   test1(con);
+	   } catch (Exception e)
+	   {
+		   unexpectedException(e);
+	   }
 }
 
-public static void test1(String []args) {   
-System.out.println("Test testRelative starting");
-
-try
-{
-// use the ij utility to read the property file and
-// make the initial connection.
-ij.getPropertyArg(args);
-con = ij.startJBMS();
-	
-			con.setAutoCommit(false);			  
-
-stmt = con.prepareStatement("create table testRelative(name varchar(10), i int)");
-   			stmt.executeUpdate();
+public static void test1(Connection con) {
+		ResultSet rs = null;
+		PreparedStatement pStmt = null;
+		Statement stmt1 = null;
+		String returnValue = null;
+		
+		try
+		{
+			con.setAutoCommit(false);
+			pStmt = con.prepareStatement("create table testRelative(name varchar(10), i int)");
+   			pStmt.executeUpdate();
			con.commit();
			
			pStmt = con.prepareStatement("insert into testRelative values (?,?)");
@@ -89,7 +91,7 @@
			System.out.println("Value="+returnValue);
 
  		} catch(SQLException sqle) {
- 		   dumpSQLExceptions(sqle);
+ 		   expectedException(sqle, NO_CURRENT_ROW_SQL_STATE);
  		} catch(Throwable e) {
  		   System.out.println("FAIL -- unexpected exception: "+e.getMessage());
e.printStackTrace(System.out);
@@ -98,28 +100,42 @@
   }
  
   /**
-* This is to print the expected Exception's details. We are here because we got an Exception
-* when we expected one, but checking to see that we got the right one.
-**/
-  static private void dumpSQLExceptions (SQLException se) {
-   if( se.getSQLState() != null && (se.getSQLState().equals(EXPECTED_SQL_STATE))) { 
+	   *  Print the expected Exception's details if the SQLException SQLState
+	   * matches the expected SQLState. Otherwise fail
+	   *
+	   * @param se  SQLException that was thrown by the test
+	   * @param expectedSQLState  The SQLState that we expect. 
+	   *
+	   **/
+	static private void expectedException (SQLException se, String expectedSQLState) {
+   if( se.getSQLState() != null && (se.getSQLState().equals(expectedSQLState))) { 
 System.out.println("PASS -- expected exception");
 while (se != null) {
 System.out.println("SQLSTATE("+se.getSQLState()+"): "+se.getMessage());
 se = se.getNextException();

Re: Use of 3rd party libraries

I agree that reuse is a great idea. I wonder if we should consider this
option for new development or when other significant changes are being
made, rather than change existing mechanisms just to use common
components. I think someone suggested enhancing network server scripts
to use NT service mechanism sometime ago. That could be a great project
to pilot some of the common frameworks.

Satheesh

Jeremy Boynes wrote:

> David Van Couvering wrote:
>
>> I like code reuse rather than having to write and maintain our own
>> work.  That's a big pull of open source is building from what others
>> have done.  I vote for including the libraries in derby.jar, rather
>> than having jar-file explosion.
>>
>
> The reuse aspect is really why I want to explore this. Re-implementing
> everything in Derby may be OK for simple stuff like command line
> parsing but will be problematic for more complex things like JMX.
>
> The open community aspect should not be underestimated - a project
> that refuses to even consider other open source solutions will very
> rapidly become isolated.
>
> I would not recommend bundling things inside derby.jar as that leads
> to classes being loaded from unexpected places (e.g. I would not
> expect org.apache.commons.cli.Something to come from derby.jar).
>
>> One concern is making sure we include third-party stuff with
>> compatible licensing.  What is the process for making we don't get
>> into some legal tangle?
>>
>
> The ASF has strict policies on what can be used by ASF projects to
> ensure that the final distribution is compatible with the Apache
> License. This basically comes down to only being able to use other
> software if its license is no more restrictive than the Apache License.
>
> -- 
> Jeremy
>
>
>

Re: assigning a jira

I have added 'lancea' to derby-developer list. Also added Shreyas. You
should be able to assign and close bugs now.

Satheesh

Lance J. Andersen wrote:

> thanks, i just sent him an email.
>
> Regards
> lance
>
> Andrew McIntyre wrote:
>
>>
>> On Apr 29, 2005, at 11:44 AM, Lance J. Andersen wrote:
>>
>>> Perhaps it is me, but I swear i used to be able to assign myself a
>>> jira.  Now i cannot find a way to do this.
>>>
>>> Any special access needed?
>>
>>
>>
>> To assign issues to yourself, you do need to be added as a developer
>> to a specific project, and I don't currently see you in the list of
>> Derby developers. Satheesh has admin rights to Jira I believe, so
>> send him your Jira userid and he should be able to add you to the
>> project.
>>
>> andrew
>>
>
>
>

Re: Assigned bugs in Jira





No problem.. You can keep it.  :-) 

I suspect Dan was making a general statement since we have seen more
active developers on the list recently. One should always assign a
defect they are actively working on, unassigns if they have stopped
working on it for any reason. Go Derby!

Satheesh

Lance J. Andersen wrote:

  
  
Sorry, I assumed when Mamta sent the email that it was the intent for
someone to take this  over.
  
I can reassign this back to Satheesh if you like.
  
I just assumed it was unassigned given the email was sent out.  I did
noticce when I assigned it that it showed Satheesh as the owner.
  
Just let me know.
  
Regards
Lance
  
Daniel John Debrunner wrote:
  
Lance J. Andersen wrote:


  

  I can take this if no one else wants it.

Mamta Satoor wrote:



  

  
I think this is a very easy bug to fix. So, if someone is looking for
an opportunity to start with a simple bug, this will be a good one.
  
  


  

  

 Key: DERBY-242
Assigned to: Satheesh Bandaram


  


Just as a point of order, hopefully a Jira bug being assigned to someone
means that they are actively working on it. So before trying to fix a
bug it's worth checking to see if it is assigned. If you are interested
in working on a bug that is assigned then you can of course offer to
help out or even take over the bug completely.

Dan.

Re: Question about softupgrade mode ..

I have now added you to 'derby-developer' list, as another Derby
developer. Now you should be able to assign bugs and close them once done.

Thanks for getting involved with Derby and tackling important enhancements.

Satheesh

TomohitoNakayama wrote:

>
> By the way, how can I assign myself to task?
> I saw next url, but could not found UI to assign myself to it...
> http://issues.apache.org/jira/browse/DERBY-134
>
>

Re: [jira] Commented: (DERBY-203) setNull(x,JDBCType.DATE) does not work when batching is turned on

Assign the bug to yourself, to indicate you are working on it. I have
added you to 'derby-developer' list now.

Satheesh

Shreyas Kaushik wrote:

> I am planning to work on this may be this week, but definitely next
> week. I did a similar fix for Blob and Timestamp. But as a part of the
> patch for this I want to solve this problem not just for this specific
> case but for all DataTypes where this problem could occur.
>
> ~ Shreyas
>
> Shreyas Kaushik (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/DERBY-203?page=comments#action_63028
>> ]
>> Shreyas Kaushik commented on DERBY-203:
>> ---
>>
>> I had fixed smilar problem with Blob and Timestamp. I will look into
>> this and other types with which this problem can arise.
>>
>>  
>>
>>> setNull(x,JDBCType.DATE) does not work when batching is turned on
>>> -
>>>
>>> Key: DERBY-203
>>> URL: http://issues.apache.org/jira/browse/DERBY-203
>>> Project: Derby
>>>Type: Bug
>>>  Components: JDBC
>>>Versions: 10.0.2.1
>>> Environment: -- Java Information --
>>> Java Version:1.4.2_07
>>> Java Vendor: Sun Microsystems Inc.
>>> Java home:   /usr/local/java/j2sdk1.4.2_07/jre
>>> Java classpath: 
>>> /home/oleg/prg/cs/lib/derby.jar:/home/oleg/prg/cs/lib/derbytools.jar:
>>> OS name: Linux
>>> OS architecture: i386
>>> OS version:  2.6.8.1-24mdk
>>> Java user name:  oleg
>>> Java user home:  /home/oleg
>>> Java user dir:   /usr/local/home/oleg/prg/cs/frameworks/embedded/bin
>>> - Derby Information 
>>> [/usr/local/home/oleg/prg/cs/lib/derby.jar] 10.0.2.0 - (30301)
>>> [/usr/local/home/oleg/prg/cs/lib/derbytools.jar] 10.0.2.0 - (30301)
>>> --
>>> - Locale Information -
>>> --
>>>Reporter: Oleg Anastasyev
>>>   
>>
>>
>>  
>>
>>> Trying to execute batch on which setNull(x,DATE) was called gives
>>> the following exception:
>>> SQL Exception: An attempt was made to get a data value of type
>>> 'DATE' from a data value of type 'null'.
>>>at
>>> org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java)
>>>at
>>> org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java)
>>>at
>>> org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java)
>>>at
>>> org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java)
>>>
>>>at
>>> org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(ConnectionChild.java)
>>>
>>>at
>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.dataTypeConversion(EmbedPreparedStatement.java)
>>>
>>>at
>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.setObject(EmbedPreparedStatement.java)
>>>
>>>at org.apache.derby.iapi.types.DataType.setInto(DataType.java)
>>>at
>>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeBatchElement(EmbedPreparedStatement.java)
>>>
>>>at
>>> org.apache.derby.impl.jdbc.EmbedStatement.executeBatch(EmbedStatement.java)
>>>
>>>at
>>> net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:54)
>>>
>>> DATE column is nullable in db schema, so it should pass there ok. I
>>> believe the problem is in org.apache.derby.iapi.types.SQLDate, which
>>> does not implement setInto method, so DataType.setInto method is
>>> executed, calling setObject(x,null). setObject thinks this is JDBC
>>> spec violation and fails on exception.
>>> Problem exists in both 10.0.2.1 and 10.0.2.0
>>>   
>>
>>
>>  
>>
>
>
>

Re: [RESULT] [VOTE] accept derby client contribution





Hi Susan,

Thanks for taking this up. I am OK with your suggestion. Should it be
forrest generated or posted as is? May be we could put the current
version for now and then modify it later?
;-) 

Satheesh

Susan Cline wrote:

  Hi Satheesh,
   
  I can get this ready for Jean to commit.
   
  I was thinking it could go under the 'Papers' tab, http://incubator.apache.org/derby/papers/index.html,
  and we could create a new category called 'Derby Network
Client'.  It wouldn't be
  appropriate under the 'Derby Engine' section.  Or, we could have
a new 'Functional Spec'
  category where any future Functional Spec for anything could go
as well.
   
  Do either of those sound okay?  If not, please suggest where you
would like the functional
  spec to go.
   
  Susan
  
  Satheesh Bandaram <[EMAIL PROTECTED]> wrote:
  Submitted
Derby client source to trunk. Post any problems you notice
with Derby client.

Enjoy! Please use the functional spec for usage. I will work with Jean
to host it at Derby website.

Satheesh

Re: Question about softupgrade mode ..

Since I merged your fix into trunk, I have marked it as FIXED and closed
the bug. In the future, you would be able to assign and close bugs yourself.

Satheesh

TomohitoNakayama wrote:

>
> By the way, how can I assign myself to task?
> I saw next url, but could not found UI to assign myself to it...
> http://issues.apache.org/jira/browse/DERBY-134

Re: Can someone please assign me to Derby-205





I have added Dag and Oystein to derby-developer list. This
should allow them to assign and resolve/close bugs. Do follow Jira
guidelines as mentioned in Dan's message:
 
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL PROTECTED]

Satheesh

Dag H. Wanvik wrote:

  Hi,

  
  
Rename org.apache.derby.impl.drda.DB2jServerImpl to
NetworkServerControlImpl

  
  
I volunteer to do this one, but I can't assign myself.

Dag

Re: [RESULT] [VOTE] accept derby client contribution

I am OK with formatting it. If forrest option is preferred, I can look
into that. I thought Jean was suggesting putting it up in HTML format?

Satheesh

Susan Cline wrote:

> ...  Okay, I'll modify the Papers tab to include a Derby Network
> Client section and add a link to the functional spec which is in raw
> html, unless you want to format it in forrest.xml.
> ...


Jean T. Anderson wrote:

> Susan Cline wrote:
>
>> ...  My feeling is whoever contributes a paper should take the
>> responsibility to format it in the desired way prior to asking
>> someone to update the site, just like patches need to be in a
>> specific format prior to submission.
>> ...
>
>
> +1
>
> That much said, volunteers with cycles/desire to improve the format of
> content are always welcome -- all you need do is offer and I'm sure
> you'll have many takers.
>
>  -jean
>
>
>
>

Re: DataSource class hierarchy in client

I suspect the class hierarchy has been made this way partly to match
Embedded driver. I am still thinking why the Embedded driver does this..

Satheesh

Jeremy Boynes wrote:

> The class hierarchy the client DataSources is:
>
> ClientBaseDataSource
>   |
>   +-- ClientDataSource
> |
> +-- ClientXADataSource
> |
> +-- ClientConnectionPoolDataSource
>
> The three standard interfaces DataSource, ConnectionPoolDataSource and
> XADataSource are not related to each other with different
> get??Connection methods that return different classes.
>
> I would like to propose refactoring this so that all three extend
> ClientBaseDataSource directly which will mean moving some of the
> properties from ClientDataSource down into the base class.
>
> Any thoughts on why this should not be done?
>
> -- 
> Jeremy
>
>
>

Re: [RESULT] [VOTE] accept derby client contribution

I agree with Jean... Functional specs might be better off posting in
HTML. I like option b)

Susan Cline wrote:

  Hi Satheesh,

  Sorry if I was confusing.  

  Submitting it in html is just fine, as per the info in the How
to Contribute Papers document:

  http://incubator.apache.org/derby/papers/index.html#How+to+Contribute+Papers

  What I was trying to say is if the person who
submits/contributes the original
  document wants it in forrest xml, it should be submitted that
way initially.  Or, 
  as Jean was saying, if someone wants to volunteer to reformat
  stuff once it is already on the site, they could volunteer to do
so.

  What I was volunteering to do was to update the Papers tab to
point to the html document.
  If you do want to reformat the document into forrest.xml I can
either

  a) hold off until you have it in forrest.xml or 
  b) update the site now with the raw html.

  Please let me know what you prefer.

  Thanks,

  Susan

  Satheesh Bandaram <[EMAIL PROTECTED]> wrote:
  I
am OK with formatting it. If forrest option is preferred, I can look
into that. I thought Jean was suggesting putting it up in HTML format?

Satheesh

Susan Cline wrote:

> ... Okay, I'll modify the Papers tab to include a Derby Network
> Client section and add a link to the functional spec which is in
raw
> html, unless you want to format it in forrest.xml.
> ...

Jean T. Anderson wrote:

> Susan Cline wrote:
>
>> ... My feeling is whoever contributes a paper should take the
>> responsibility to format it in the desired way prior to asking
>> someone to update the site, just like patches need to be in a
>> specific format prior to submission.
>> ...
>
>
> +1
>
> That much said, volunteers with cycles/desire to improve the
format of
> content are always welcome -- all you need do is offer and I'm sure
> you'll have many takers.
>
> -jean
>
>
>
>

Re: Derby Newtork Client documentation

2005-05-03 Thread Satheesh Bandaram

+1. I think we should include JCC section, for the benifit of current
10.0 users.

Let me know if I can help in anyway.

Satheesh

Jeff Levitt wrote:

>I'd like to take a shot at updating the documentation
>to include the Derby Client.  I've been mulling
>several ways to do this, seeing as the current docs
>use the IBM DB2 JCC Driver, db2jcc.jar etc.
>
>So do want to replace all that with information from
>the Derby Client (I would plan to use the Derby Client
>spec to do that).  All syntax and examples would have
>to be updated, but that's not too difficult.  The
>question is what to do with the existing information. 
>Do we want to create a new section, say in the Server
>Admin Guide appendix, that describes using the IBM JCC
>Client rather than the Derby Client for those who
>still want to use it?  Or should we take it out
>altogether, and maybe make a separate whitepaper?
>
>Either way, I think possibly a whitepaper on moving
>from the old client to the Derby client would be
>useful as well.
>
>Suggestions?  Concerns?
>
>
>
>  
>

Re: DERBY-104 (Was: Contributing to Derby, Tips and Tasks To Get You Started)

2005-05-03 Thread Satheesh Bandaram

You should have access now. Derby has 26 members in 'derby-developer'
alias... one of the highest.

Satheesh

>I'll volunteer for this one. Could somebody assign it to me (or give
>me access to aaign myself)?
>  
>

Re: [PATCH]Derby-229





Thanks for the patch. Couple of comments:

  New test caseInsensitiveColumn is not part of any testsuite. So,
the test will not get run. You would need to add this to an existing
suite.
  Also, you should consider enhancing an existing test script when
adding a new test, rather than creating a new test everytime. This
increases number of tests in a suite, taking it longer to run them.
Instead, updating an existing test is better.
  The patch needs to be generated from the trunk directory, so your
directory path wouldn't show in the patch. (/drivers/derby/trunk)


Satheesh

Shreyas Kaushik wrote:
Hi,
  
  
This is the latest patch.
  
I have taken care of comments from Mamta and Dan. Please let me know if
I have missed anything.
  
  
~ Shreyas
  
  

Index: /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/master/caseInsensitiveColumn.out
===
--- /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/master/caseInsensitiveColumn.out	(revision 0)
+++ /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/master/caseInsensitiveColumn.out	(revision 0)
@@ -0,0 +1,9 @@
+Test caseInsensitiveColumn starting
+Before updation...
+ResultSet is: 1
+ResultSet is: 346
+After update...
+Column Number 1: 900
+Column Number 2: 346
+Col COL1: 900
+Col col1: 900
Index: java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java
===
--- java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java	(revision 165091)
+++ java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java	(working copy)
@@ -3591,8 +3591,14 @@
 		ResultDescription rd = resultDescription;
 
 	// 1 or 0 based? assume 1 (probably wrong)
-	for (int i=rd.getColumnCount(); i>=1; i--) {
+// Changing the order in which columns are found from 1 till column count.
+// This is necessary in cases where the column names are the same but are in different cases.
+// This is because in updateXXX and getXXX methods column names are case insensitive
+// and in that case the first column should be returned.
+
+int columnCount = rd.getColumnCount();
 
+for(int i = 1 ; i<= columnCount;i++) {
 		String name = rd.getColumnDescriptor(i).getName();
 		if (StringUtil.SQLEqualsIgnoreCase(columnName, name)) {
 			return i;
Index: /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/caseInsensitiveColumn.java
===
--- /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/caseInsensitiveColumn.java	(revision 0)
+++ /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/caseInsensitiveColumn.java	(revision 0)
@@ -0,0 +1,97 @@
+package org.apache.derbyTesting.functionTests.tests.jdbcapi;
+
+
+import java.sql.*;
+
+import org.apache.derby.tools.ij;
+import org.apache.derby.tools.JDBCDisplayUtil;
+
+public class caseInsensitiveColumn {
+
+public static void main(String[] args) {
+test1(args);
+}
+
+public static void test1(String []args) {   
+Connection con;
+ResultSet rs;
+Statement stmt = null;
+PreparedStatement stmt1 = null;
+
+System.out.println("Test caseInsensitiveColumn starting");
+
+try
+{
+// use the ij utility to read the property file and
+// make the initial connection.
+ij.getPropertyArg(args);
+con = ij.startJBMS();
+	
+			con.setAutoCommit(false);			  
+
+stmt = con.createStatement(); 
+
+			// create a table with two columns, their names differ in they being in different cases.
+stmt.executeUpdate("create table caseiscol(COL1 int ,\"col1\" int)");
+
+   			con.commit();
+   			
+			stmt.executeUpdate("insert into caseiscol values (1,346)");
+
+			con.commit();
+
+// select data from this table for updating
+			stmt1 = con.prepareStatement("select COL1, \"col1\" from caseiscol FOR UPDATE",ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE);
+		rs = stmt1.executeQuery();
+
+			// Get the data and disply it before updating.
+System.out.println("Before updation...");
+			while(rs.next()) {
+			   System.out.println("ResultSet is: "+rs.getObject(1));
+			   System.out.println("ResultSet is: "+rs.getObject(2));
+			}
+rs.close();
+			rs = stmt1.executeQuery();
+			while(rs.next()) {
+			   // Update the two columns with different data.
+			   // Since update is case insensitive only the first column should get updated in both cases.
+			   rs.updateInt("col1",100

Re: Schedule for beta and release of 10.1

One month seems like a good amount time to figure out some of these, at
least just to formulate a plan. I am eager to see Derby client get
rigorous testing that precedes a full release and to get it to derby
users. I am concerned about potential resource leakage, platform
specific, multi-threading issues that may or may not be present. These
issues are typically found and addressed during a full release process.
I also think current dependence on JCC client driver in 10.0 hinders
wider adaptability of Derby.

You do raise some touch questions. :-) Like you suggested, we can
work on getting a plan in place for these soon.

Satheesh

> I think aiming for a release in a month or so would be good.
>
> However, I do not want to rush out the first version of the client as
> that will suddenly give us a legacy codebase. We have only just seen
> this code and there are a couple of areas that we should consider:
>
> * which JREs will it run on
> * do we need JSR-169 support
> * what are the plans for SSL transport, including client auth
> * what do we do with Referenceable
> * what are our plans for connector support
> * do we have the right properties
> * do we change the commmand line processing for NetworkServer
>
> and probably a few more things as well. We don't need to resolve all
> of these but at least figure out what the plan is.
>
> -- 
> Jeremy
>
>
>

Re: [jira] Created: (DERBY-242) DatabaseMetaData.supportsGetGeneratedKeys needs to return FALSE, since Derby only has limited support.





Committed this patch. I also searched for all references to
supportsGetGeneratedKeys() in the test & master files. This was the
only reference. Lance, can you RESOLVE the Jira entry and then CLOSE
it, please?

Satheesh


r168176 | bandaram | 2005-05-04 12:50:21 -0700 (Wed, 04 May 2005) | 3
lines

Derby-242: Make DatabaseMetadata.supportsMultipleOpenResults() return
FALSE.

Submitted by Lance Anderson. ([EMAIL PROTECTED])


Lance J. Andersen wrote:

  
  
Hi Mamta,
  
The only test I saw  and ran was DBMetaDataJdbc30 when I searched the
codeline. (You saw my notes on my other failures in jdk14 test run, but
this one passed)
  
I also noticed that the other drivers were already set to false.
  
Regards
Lance
  
Mamta Satoor wrote:
  
Hi Lance,

I looked at the review package and it looks good. Good comments in the
EmbedDatabaseMetaData.java. Just wondered if you ran the existing
tests to make sure nothing got affected by the change.

Mamta

On 5/4/05, Lance J. Andersen <[EMAIL PROTECTED]> wrote:
  

  Oh, I forgot to mention that i validated that the dbMetaDataJdbc30 in jdk14
passed.



Lance Andersen wrote:

Attached is the patch. 

Regards 
Lance 

Mamta Satoor wrote: 
Hi Lance, 

Thanks for taking it. Yes, it is for Embedded Driver. 

Mamta 

On 4/29/05, Lance J. Andersen <[EMAIL PROTECTED]> wrote: 

I take it this is with the Embedded Driver as it looks like the code for the
new Client Driver is returning false. 

I can take this if no one else wants it. 


Mamta Satoor wrote: 
Hi, 


I think this is a very easy bug to fix. So, if someone is looking 

for 

an opportunity to start with a simple bug, this will be a good 

one. 


Mamta 

On 4/26/05, Satheesh Bandaram (JIRA)  

wrote: 

  

DatabaseMetaData.supportsGetGeneratedKeys needs to return 
FALSE, since Derby only has limited 
support. 

--


Key: DERBY-242 

 URL: 

http://issues.apache.org/jira/browse/DERBY-242 

 Project: 

Derby 

 Type: Bug 
 Components: JDBC 
 Versions: 10.0.2.0 
Environment: ALL 

Reporter: Satheesh Bandaram 

Assigned to: Satheesh Bandaram 
 Fix For: 

10.1.0.0 


Derby only has partial support for retrieving generated 

values. 

Because of this, it is desirable to 

make 

DatabaseMetaData.supportsGetGeneratedKeys return 

FALSE. One 

of the restrictions include Jira entry Derby-201. Till this 

is 

fixed, we should change derby to return FALSE for this. 

This would also 

match Derby client behavior. 


-- 
This message is automatically generated by 

JIRA. 

- 
If you think it was sent incorrectly contact one of the 

administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa 

- 
For 

more information on JIRA, see: 
http://www.atlassian.com/software/jira 


  

  







Index:
  

  java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java


===
---
  

  java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java
(revision 168122)


+++
  

  java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java
(working copy)


@@ -2880,7 +2880,13 @@
 */
 public boolean
  

  supportsGetGeneratedKeys()


 {
- return true;
+ /*
+ * Currently reverting
  

  the returned value to false until there 


+ * is more support for
  

  autogenerated keys in Derby.


+ * (such as support for specifying the
  

  returned columns for


+ * the autogenerated key)
+ */
+ return false;
 }
 
  

  /**


Index:
  

  java/testing/org/apache/derbyTesting/functionTests/master/dbMetaDataJdbc30.out


===
---
  

  java/testing/org/apache/derbyTesting/functionTests/master/dbMetaDataJdbc30.out
(revision 168122)


+++
  

  java/testing/org/apache/derbyTesting/functionTests/master/dbMetaDataJdbc30.out
(working copy)


@@ -4,7 +4,7 @@
 supportsSavepoints() : true
  

  supportsNamedParameters() : false


 supportsMultipleOpenResults() :
  

  true


-supportsGetGeneratedKeys() : true
+supportsGetGeneratedKeys() : false
  

  supportsResultSetHoldability(HOLD_CURSORS_OVER_COMMIT) :
true


 supportsResultSetHoldability(CLOSE_CURSORS_AT_COMMIT)
  

  : true


 getJDBCMajorVersion() : 3
 
>

Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values





I am getting ready to submit this patch. 

Satheesh

Mamta Satoor wrote:

  Hi David,

I have attached a new patch to take care of the comments from your review.

1)Good catch about
impl.sql.compile.ResultColumnList.getResultColumnThroughExpression().
It is left over code from another solution I was trying to fix the
problem. I have taken it out of the review package attached to this
mail.

2)The change in ResultColumnDescriptor.java for getSourceSchemaName is
for clarity and consistency reasons (similar to getSourceTableName).
With this
change, EmbedResultSetMetaData now calls getSourceXXXName for
getTableName and getSchemaName. Similarly, in
GenericColumnDescriptor(which implements ResultColumnDescriptor), we
have getSourceXXXName to keep the source table and source schema name.

3)I have reformatted code and comments to not exceed 80 characters.
Also, changed the comments for method commonCodeForUpdateableBySql
from .. to /** and */

thanks,
Mamta
On 5/2/05, David Van Couvering <[EMAIL PROTECTED]> wrote:
  
  
Hi, Mamta, this looks good.  It built, and I ran as many tests as I
could before I had to leave for the day.  My God, those tests take a
long time to run.  But that's a topic for a separate discussion :)

Here are my comments and questions...

- What you have looks good and makes sense, but I don't know the code
well enough to know if you're missing something.  I guess the tests help
guarantee that, but someone more familiar with the code taking a look
would be great.

- I was curious how
impl.sql.compile.ResultColumnList.getResultColumnThroughExpression() was
used.  In NetBeans I searched for all usages of it and could find none.
  To double-check, I did a full search of the codeline and only found
it where it is defined, and no uses.  Is there a reason to have this
method if nothing uses it?

- in ResultColumnDescriptor.java, why did you change the method from
getSchemaName() to getSourceSchemaName()?  Is this just to make it more
clear what the method is doing?

- A lot of your comments and code seem to far exceed 80 characters in
length per line.  This makes it hard to read in diff output and
text-based editors, and it requires scrolling in IDEs.  Could you please
limit your source lines to 80 characters?

- The method commonCodeForUpdateableBySql in ResultColumnList.java
should have comments with /** and */ rather than //  It took me a while
in 'vi' to determine this was a new method, to the eye it looks like a
continuation of the previous method.

David

Mamta Satoor wrote:



  Hi,

I am sorry if I sound like a broken record, but please, will someone
review this? And if no concerns from anyone, will a commiter commit
it?

thanks,
Mamta

On 4/27/05, Mamta Satoor <[EMAIL PROTECTED]> wrote:

  
  
Hi,

I wondered if anyone got a chance to review this patch?

thanks,
Mamta

On 4/24/05, Mamta Satoor <[EMAIL PROTECTED]> wrote:



  Hi Dan,

I have a new patch for this bug which also fixes the problem you
brought up with sql select * from a.t as X. The fix for this required
change in impl.sql.compile.FromBaseTable's method genResultColList().
I changed the code such that we set the TableDescriptor on the
ColumnDescriptor instance. This TableDescriptor is later used by
ResultColumn.getTableName to get the base table name of the column. In
addition to that, I changed ColumnReference.getSourceTableName and
ColumnReference.getSourceSchemaName so that they don't look at the
user supplied correlation name (if any) to fetch the base table/schema
name.

I have also added some test cases for the code changes above in
jdbcapi/resultset.java

Other than this, the rest of the patch stays the same as what you
tried applying last week.

I have run the tests and there is no new failure because of my changes.

svn stat output
M  java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java
M  java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java
M  java\engine\org\apache\derby\impl\sql\compile\CursorNode.java
M  java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java
M  java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java
M  java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java
M  java\engine\org\apache\derby\impl\sql\compile\ValueNode.java
M  java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
M  java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java
M  java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java
M  java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java
M  java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java
M  java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java
M  java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java
M  java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java
M  java\testing\org\apa

Derby-12 and Derby-13 ...

Shreyas, since you worked on both these bugs, can close them after
confirming they are indeed fixed and we have a test case for both in our
testsuites? Since you can close bugs, it is best if you take action.

Satheesh

Does anyone know about Derby-179?

2005-05-05 Thread Satheesh Bandaram





I was briefly looking at Derby-179.
The bug started describing a problem that is actually unsupported
syntax on Derby. Then there were couple of notes indicating current
problem with Hibernate and Derby integration is Derby-127.
Jack seems to be working on Derby-127, so I was wondering if Derby-127
is addressed how can we test Derby-179?

I was looking at Derby-179 since it seems to have highest priority and
Hibernate integration would be good for Derby as well.

Satheesh

Re: DERBY-167 has done but ...

2005-05-05 Thread Satheesh Bandaram


(B
(B
(B
(BGreat job getting this done. This is indeed a very useful Enhancement
(Bto Derby.
(B
(BLooking briefly at the attached patch, some comments:
(B
(B  I think syntax for GENERATED BY DEFAULT needs to include the BY,
(Baccording to SQL standard.
(B  One of the main uses of this new clause is for importing data
(Binto IDENTITY columns. I would like to see some tests that import data
(Binto tables created with the new identity option. Import code actually
(Buses bulkInsert option, so it would be good to test this code path too.
(BI can help, if needed, on these tests. Before commiting the patch, it
(Bwould be good to add more tests in general.
(B  I couldn't fully apply the patch. Had issues with two files,
(BResultColumnList and ColumnDescriptor. I think these files might have
(Bbeen updated since you started working on the patch. It would be good
(Bif you can merge up to the latest version.
(B  
(B
(BAgain, great to see the patch.
(B
(BSatheesh
(B
(BTomohitoNakayama wrote:
(BHello.
(B  
(B  
(BI think coding for solution-1 of DERBY-167 has done.
(B  
(BI attach patch file to this mail for others to confirm it.
(B  
(B  
(BRelating test , autoincrement and columnDefaults , was passed.
(B  
(B  
(B  
(BHowever, In derbyall test , I found many errors which seems not caused
(Bby my modification.
(B  
(BErrors seems to be devided three kind ...
(B  
(B1:Error of parameterMapping. I don't know what is parameter Mapping
(Bmean,
(B  
(Bbut file names told so.
(B  
(B2:Error of i18n. It seems that English message was generated though
(Btest assume Spanish.
(B  
(B3:Error of derbynetclientmats.
(B  
(B  
(BI uploaded $TEST_DIR/derbyall_fail.txt and $TEST_DIR/derbyall_diff.txt
(Bto my web directory,
(B  
(Bbecause size was too large.
(B  
(Bhttp://www5.ocn.ne.jp/~tomohito/20050505/derbyall_fail.txt
(B  
(Bhttp://www5.ocn.ne.jp/~tomohito/20050505/derbyall_diff.txt
(B  
(B  
(BSomething is going on ...?
(B  
(B  
(B  
(BBest regards.
(B  
(B  
(B  
(B/*
(B  
(B  
(B    Tomohito Nakayama
(B  
(B    [EMAIL PROTECTED]
(B  
(B    [EMAIL PROTECTED]
(B  
(B  
(B    Naka
(B  
(B    http://www5.ocn.ne.jp/~tomohito/TopPage.html
(B  
(B  
(B*/
(B  
(B
(BNo virus found in this outgoing message.
(BChecked by AVG Anti-Virus.
(BVersion: 7.0.308 / Virus Database: 266.11.5 - Release Date: 2005/05/04
(B  
(B
(B
(B

Re: DataSource class hierarchy in client

2005-05-05 Thread Satheesh Bandaram

I think the ClientBaseDataSource was not meant to be a public class. We
tried to localize all public classes into the 'jdbc' package and use
only the jdbc package to generate public javadoc. That is one of the
reasons for putting all public tracing support in ClientDataSource.

I would also like to match API with Embedded driver as much as possible.
It would be real bad if applications need changes when using two
different driver offerings of Derby. Your suggestions probably don't
break this, but something to watch for. We tried to match Embedded
behavior, unless it was deemed WRONG.

Satheesh

Jeremy Boynes wrote:

> Satheesh Bandaram wrote:
>
>> I suspect the class hierarchy has been made this way partly to match
>> Embedded driver. I am still thinking why the Embedded driver does this..
>>
>
> I don't know if it is relevant but most of the implementation in the
> client code uses ClientDataSource instances rather than the base class
> - in fact, the base class itself is never really used at all. I have a
> feeling there is some legacy leftover here.
>
> I am going to go through the client code and switch the usages to the
> base class (which declares the methods being used) and then change the
> hierarchy here as proposed.
>
> -- 
> Jeremy
>
>
>

Re: [jira] Assigned: (DERBY-263) Remove IJ support for setting unicodeescape option.

2005-05-06 Thread Satheesh Bandaram





Hi Lance,

You are fast... I have a patch ready already, so if you don't mind, I
will submit it?

Satheesh

Lance Andersen (JIRA) wrote:

   [ http://issues.apache.org/jira/browse/DERBY-263?page=all ]

Lance Andersen reassigned DERBY-263:


Assign To: Lance Andersen

  
  
Remove IJ support for setting unicodeescape option.
---

 Key: DERBY-263
 URL: http://issues.apache.org/jira/browse/DERBY-263
 Project: Derby
Type: Sub-task
  Components: Tools
Versions: 10.1.0.0
Reporter: Satheesh Bandaram
Assignee: Lance Andersen
Priority: Minor

  
  
  
  
Derby doesn't support setting unicodeescape option in IJ. Need to remove the option from IJ, in addition to removing the documentation.

Re: Patch for Derby-263 ...

2005-05-10 Thread Satheesh Bandaram





Hi Lance,

Thanks for the review. I think ijConstants.java is a generated file...
Once we submit ij.jj change, new versions of this generated file should
not have references to UNICODEESCAPE.

Satheesh

I have committed this patch:

Sending   
java\testing\org\apache\derbyTesting\functionTests\master\UnicodeEscape_JP.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\ij.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\j9_13\ij.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\i18n\UnicodeEscape_JP.sql
Sending    java\tools\org\apache\derby\impl\tools\ij\Main.java
Sending    java\tools\org\apache\derby\impl\tools\ij\ij.jj
Sending    java\tools\org\apache\derby\loc\toolsmessages.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_de_DE.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_es.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_fr.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_it.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_ja_JP.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_ko_KR.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_pt_BR.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_zh_CN.properties
Sending   
java\tools\org\apache\derby\loc\toolsmessages_zh_TW.properties
Transmitting file data 
Committed revision 169502.

Lance J. Andersen wrote:

  
  
Hi Satheesh,
  
This looks good.
  
I noticed that ijConstants.java also has references to unicodeescape,
should these be removed as part of this patch?
  
Regards,
lance
  
Satheesh Bandaram wrote:
  
Simple patch to remove UNICODEESCAPE option in IJ.

Satheesh

  

Index: java/tools/org/apache/derby/impl/tools/ij/ij.jj
===
--- java/tools/org/apache/derby/impl/tools/ij/ij.jj	(revision 168631)
+++ java/tools/org/apache/derby/impl/tools/ij/ij.jj	(working copy)
@@ -610,7 +610,6 @@
 |	
 |	
 |	
-|	
 |	
 |	
 |	
@@ -973,7 +972,6 @@
 |	r=RunStatement()	
 |	r=SetConnectionStatement()	
 |	r=ShowConnectionsStatement()	
-|	r=UnicodeEscape()
 |	r=WaitForStatement()	
 |	r=XA_DataSourceStatement()
 |	r=XA_ConnectStatement()
@@ -2146,28 +2144,6 @@
 }
 
 /**
- * Unicodeescape controls ASCII Unicode escape processing
- * 
- * Syntax:
- *   UNICODEESCAPE [ ON | OFF ] ;
- */
-ijResult UnicodeEscape()
-:
-{
- 	Token on=null;
-}
-{
-	 
-	( on=
-	| 
-	)
-	{
-		LocalizedResource.setUnicodeEscape((on==null?false:true));
-		return null;
-	}
-}
-
-/**
  * ReadOnly lets you control this aspect of the connection.
  * REMIND: should have a general way to set all connection attributes,
  * this is a shortcut for immediate needs.
@@ -3128,7 +3104,6 @@
 |	tok = 
 |	tok = 
 |	tok = 
-|	tok = 
 |	tok = 
 |	tok = 
 |	tok = 
Index: java/tools/org/apache/derby/impl/tools/ij/Main.java
===
--- java/tools/org/apache/derby/impl/tools/ij/Main.java	(revision 168631)
+++ java/tools/org/apache/derby/impl/tools/ij/Main.java	(working copy)
@@ -85,7 +85,6 @@
 		String inputResourceName;
 		boolean gotProp;
 
-		String tmpUnicode = null;
 		Properties connAttributeDefaults = null;
 
 		// load the property file if specified
@@ -133,11 +132,6 @@
   		}
 	}
 
-		// set initial Unicode Escape Mode
-		tmpUnicode = util.getSystemProperty("ij.unicodeEscape");
-		if ((tmpUnicode != null) && tmpUnicode.toUpperCase(Locale.ENGLISH).equals("ON")) {
-			LocalizedResource.setUnicodeEscape(true);
-		} 
 		String outFile = util.getSystemProperty("ij.outfile");
 		if (outFile != null && outFile.length()>0) {
 			LocalizedOutput oldOut = out;
Index: java/tools/org/apache/derby/loc/toolsmessages_it.properties
===
--- java/tools/org/apache/derby/loc/toolsmessages_it.properties	(revision 168631)
+++ java/tools/org/apache/derby/loc/toolsmessages_it.properties	(working copy)
@@ -90,7 +90,6 @@
 \  GETCURRENTROWNUMBER name;-- restituisce il numero di righe per la posizione corrente del cursore di scorrimento denominato\n\
 \   -- (quando il cursore non \u00e8 posizionato su una riga viene restituito 0.) \n\
 \  CLOSE name;  -- chiude il cursore denominato\n\
-\  UNICODEESCAPE [ ON | OFF ]; -- imposta la modalit\u00e0 unicode escape per il flusso di input\n\
 \  LOCALIZEDDISPLAY [ ON | OFF ];\n\
 \   -- controlla la rappresentazione dei dati sensibile alle impostazioni internazionali\n\
 \ \n\
Index: java/tools/org/apache/derby/loc/toolsmessages.properties
===
--- java/tools/org/apache/derby/loc/toolsmessages.properties	(rev

Re: Info of what fixes go into 10.1 release ?

2005-05-10 Thread Satheesh Bandaram

Hi Bernd,

Sorry, I promised to help complete this patch, but haven't been
providing much of a help. The patch as attached is not complete. As
Jack pointed out, we do need to raise error when there is an ORDER BY
on a correlation name that is ambiguous. For example,

> select i as a, j as a from t
A   A
--- ---
  1   1
  2   2
  0   4
  3 record(s) selected.
> select i as a, j as a from t order by a    <== Needs to raise
error, as order by a could be refering to i or j

But
> select i, i, i from t order by i    <=== This
is OK, since all references to i point to same base column.

Do you have time and interest to adjust the patch? We still have time
to submit this change to 10.1 release. There is active discussion on
when that release might happen.

Satheesh

Bernd Ruehlicke wrote:

  Hi there,

I added a patch to http://issues.apache.org/jira/browse/DERBY-147  a
while ago.

I just want to know how I can figure out if this is making it into the
next release.
Do we have a site where we list what is going into the 10.1 release ?

Thanx
B-)

-
I use Derby because I'm worth it

Re: [jira] Created: (DERBY-251) DISTINCT query is returning duplicate rows





It seems the patch is not built on latest codebase, so I couldn't apply
this patch. Would it be possible to send updated patch based on latest
code?

I looked at the patch anyway and wonder if we are only fixing a narrow
case where we are applying DISTINCT elimination logic incorrectly. I
suspect there may be a few more related cases that the fix might be
missing, but this could be just my not understanding the patch yet.  :-)    I will look at this
again once updated patch is available.

Satheesh

Mamta Satoor wrote:

  Hi,

I have a patch for this optimizer bug. Basically, the issue turned out
to be the logic for DISTINCT elimination. During the optimization
phase, if a query has DISTINCT clause, then impl.sql.compile.FromList
class's returnsAtMostSingleRow() method gets called. This method
returns true if the method concludes that DISTINCT in the query is
redundant (based on a complex logic that decides that the query is
going to return distinct rows on its own without the DISTINCT clause.
The details of the current logic for DISTINCT elimination can be found
in the comments at the method level.)

For the query in question in this bug, the method returned true for
DISTINCT elimination which is wrong. The explanation is as follows.

First of all, I was able to simplify the query reported in the bug to
following query.
select  distinct  q1."NO1" from IDEPT q1, IDEPT q2
where  ( q2."DISCRIM_DEPT" = 'HardwareDept')
and  ( q1."DISCRIM_DEPT" = 'SoftwareDept')  and  ( q1."NO1" <> ALL
(select  q3."NO1" from IDEPT q3 where  (q3."REPORTTO_NO" =  q2."NO1")))

This query gets converted to following during optimization
select  distinct  q1."NO1" from IDEPT q1, IDEPT q2
where  ( q2."DISCRIM_DEPT" = 'HardwareDept')
and  ( q1."DISCRIM_DEPT" = 'SoftwareDept')  and  not exists (
(select  q3."NO1" from IDEPT q3 where
(  q3."REPORTTO_NO" =  q2."NO1"  and q3."NO1" = q1."NO1") ) )  ;

This optimized query has 4 predicates associated with it
q3.reportto_no = q2.no1
q2.discrim_dept = 'HardwareDept'
q1.descrim_dept = 'SoftwareDept'
q1.no1 = q3.no1

Next, on this optimized query(since it has DISTINCT clause in it), the
returnsAtMostSingleRow() method gets called. The method incorrectly
returns true indicating that DISTINCT can be eliminated. The reason
for this is that method is looking at predicates that belong to the
inside query with the exists clause (which is on table IDEPT q3) to
determine DISTINCT elimination for the outer level.

The fix is that the predicates from the exists query, (in this
particular case, q3."NO1" = q1."NO1" and q3.reportto_no = q2.no1)
should not be considered when deciding elimination of DISTINCT in the
outer query. That is what the attached patch does.

Hope this helps understand the problem and the proposed fix for it.
The files impacted by the change are as follows
svn stat
M java\engine\org\apache\derby\impl\sql\compile\FromList.java
M java\testing\org\apache\derbyTesting\functionTests\tests\lang\distinctElimination.sql
M java\testing\org\apache\derbyTesting\functionTests\master\distinctElimination.out

Please send in comments you may have. I have run the existing tests
and the patch didn't cause any failures.

thanks,
Mamta


On 4/29/05, Mamta A. Satoor (JIRA)  wrote:
  
  
DISTINCT query is returning duplicate rows
--

Key: DERBY-251
URL: http://issues.apache.org/jira/browse/DERBY-251
Project: Derby
   Type: Bug
 Components: SQL
   Versions: 10.1.0.0
   Reporter: Mamta A. Satoor
Assigned to: Mamta A. Satoor

Following query on a table with primary key returns duplicate rows
select  distinct  q1."NO1" from IDEPT q1, IDEPT q2
where  ( q2."DISCRIM_DEPT" = 'HardwareDept')
and  ( q1."DISCRIM_DEPT" = 'SoftwareDept')  and  ( q1."NO1"
<> ALL  ( select  q3."NO1" from IDEPT q3 where  (  q3."REPORTTO_NO" =  q2."NO1") ) )  ;

The sql script to create the table and load data into it is as follows
CREATE TABLE "APP"."IDEPT" ("DISCRIM_DEPT" VARCHAR(32), "NO1" INTEGER NOT NULL,
"NAME" VARCHAR(50), "AUDITOR_NO" INTEGER, "REPORTTO_NO" INTEGER, "HARDWAREASSET"
VARCHAR(15), "SOFTWAREASSET" VARCHAR(15));
-- primary/unique
ALTER TABLE "APP"."IDEPT" ADD CONSTRAINT "PK_IDEPT" PRIMARY KEY ("NO1");
insert into idept values ('Dept', 1, 'Department1', null, null, null, null);
insert into idept values ('HardwareDept', 2, 'Department2', 25, 1, 'hardwareaset2', null);
insert into idept values ('HardwareDept', 3, 'Department3', 25, 2, 'hardwareaset3', null);
insert into idept values ('SoftwareDept', 4, 'Department4', 25, 1, null, 'softwareasset4');
insert into idept values ('SoftwareDept', 5, 'Department5', 30, 4, null, 'softwareasset5');

The problem appears to be in org.apache.derby.impl.sql.compile.FromList.returnsAtMostSingleRow() method. This method along with other things tries to determine if the DISTINCT can be dropped without causing duplicate rows. For the query in question, this method decides that DISTINCT is not necessary which I think is in

Re: Derby 270 (need to be added to the JIRA derby devs group

You should know have the karma now to assign and close issues.

Satheesh

Jeff Levitt wrote:

>I created Derby-270, but then realized that the change
>I was goign to make for it is not needed.  However, I
>can't close my own JIRA issue.  I think I need to be
>in the derby dev group in Jira.  Can my id be added to
>that group?  My id is jlevitt.
>
>Thanks!
>
>
>
>  
>

Re: [PATCH] (DERBY-251) DISTINCT query is returning duplicate rows





Submitted this patch. Thanks for addressing the review comments quickly.

Satheesh

Sending   
java\engine\org\apache\derby\impl\sql\compile\FromList.java
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\distinctElimination.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\distinctElimination.sql
Transmitting file data ...
Committed revision 169735.

Mamta Satoor wrote:

  Hi Jack,

Appreciate you taking the time to do the review and catching the
predicate with _expression_. I have changed the code and also added a
test case for it. I have fired the derbyall suite on my codeline to
make sure everything else runs smoothly. Attached is the updated patch
anyways.

thanks,
Mamta

On 5/11/05, Jack Klebanoff <[EMAIL PROTECTED]> wrote:
  
  
The patch does not completely fix the problem. It does not handle the
case where the exists table column is embedded in an _expression_. Try the
following variation on the test select:

select  distinct  q1."NO1" from IDEPT q1, IDEPT q2
where  ( q2."DISCRIM_DEPT" = 'HardwareDept')
and  ( q1."DISCRIM_DEPT" = 'SoftwareDept')  and  ( q1."NO1" <> ALL
(select  q3."NO1" from IDEPT q3 where  ( ABS(q3."REPORTTO_NO") =  q2."NO1")))

Because q3."REPORTTO_NO" is inside a call to ABS the code added to
FromList.returnsAtMostSingleRow does not see it.

I would suggest using

   JBitSet referencedTables =
and.getLeftOperand().getTablesReferenced();
   if( referencedTables.get( existsTableNumber))
   {

predicatesTemp.removeElementAt(predicatesTempIndex);
   break;
   }

instead of
   BinaryRelationalOperatorNode beon =
(BinaryRelationalOperatorNode)
   and.getLeftOperand();
   ValueNode left = beon.getLeftOperand();
   ValueNode right = beon.getRightOperand();

   /* If left or right side of predicate refer to
exists base table,
   then remove it */
   if ((left instanceof ColumnReference) &&
   ((ColumnReference) left).getTableNumber() ==
existsTableNumber)
   {

predicatesTemp.removeElementAt(predicatesTempIndex);
   break;
   }
   else if ((right instanceof ColumnReference) &&
   ((ColumnReference) right).getTableNumber()
== existsTableNumber)
   {

predicatesTemp.removeElementAt(predicatesTempIndex);
   break;
   }

I have tried it out and it seems to work.

Jack Klebanoff

Mamta Satoor wrote:



  Hi,

I have a patch for this optimizer bug. Basically, the issue turned out
to be the logic for DISTINCT elimination. During the optimization
phase, if a query has DISTINCT clause, then impl.sql.compile.FromList
class's returnsAtMostSingleRow() method gets called. This method
returns true if the method concludes that DISTINCT in the query is
redundant (based on a complex logic that decides that the query is
going to return distinct rows on its own without the DISTINCT clause.
The details of the current logic for DISTINCT elimination can be found
in the comments at the method level.)

For the query in question in this bug, the method returned true for
DISTINCT elimination which is wrong. The explanation is as follows.

First of all, I was able to simplify the query reported in the bug to
following query.
select  distinct  q1."NO1" from IDEPT q1, IDEPT q2
where  ( q2."DISCRIM_DEPT" = 'HardwareDept')
and  ( q1."DISCRIM_DEPT" = 'SoftwareDept')  and  ( q1."NO1" <> ALL
(select  q3."NO1" from IDEPT q3 where  (q3."REPORTTO_NO" =  q2."NO1")))

This query gets converted to following during optimization
select  distinct  q1."NO1" from IDEPT q1, IDEPT q2
where  ( q2."DISCRIM_DEPT" = 'HardwareDept')
and  ( q1."DISCRIM_DEPT" = 'SoftwareDept')  and  not exists (
(select  q3."NO1" from IDEPT q3 where
(  q3."REPORTTO_NO" =  q2."NO1"  and q3."NO1" = q1."NO1") ) )  ;

This optimized query has 4 predicates associated with it
q3.reportto_no = q2.no1
q2.discrim_dept = 'HardwareDept'
q1.descrim_dept = 'SoftwareDept'
q1.no1 = q3.no1

Next, on this optimized query(since it has DISTINCT clause in it), the
returnsAtMostSingleRow() method gets called. The method incorrectly
returns true indicating that DISTINCT can be eliminated. The reason
for this is that method is looking at predicates that belong to the
inside query with the exists clause (which is on table IDEPT q3) to
determine DISTINCT elimination for the outer level.

The fix is that the predicates from the exists query, (in this
particular case, q3."NO1" = q1."NO1" and q3.reportto_no = q2.no1)
should not be considered when deciding elimination of DISTINCT in the
outer query. That is what the attached patch does.

Hope this helps understand the prob

Re: "-Dframework=DerbyNetClient"? (Re: BulkInsert ? (Re: DERBY-167 has done but ...))

; Well .. I'm not sure default command option "-Dframework=DerbyNet"

> generated by RunSuite 

>

> Best regards.

>

> /*

>

> Tomohito Nakayama

> [EMAIL PROTECTED]

> [EMAIL PROTECTED]

>

> Naka

> http://www5.ocn.ne.jp/~tomohito/TopPage.html

>

> */

> - Original Message -

> From: "TomohitoNakayama" <[EMAIL PROTECTED]>

> To: "Derby Development" 

> Sent: Tuesday, May 10, 2005 8:37 PM

> Subject: Re: BulkInsert ? (Re: DERBY-167 has done but ...)

>

>

>> Hello.

>>

>> I see.

>> I understood bulk insert.

>> Thank you.

>> Now, I have just tryed derbyall-test problem and there seems
to be

>> trouble in derbynet/DerbyNetAutoStart..

>>

>> I will report it in detail later.

>>

>> Best regards.

>> /*

>>

>> Tomohito Nakayama
    
>> [EMAIL PROTECTED]

>> [EMAIL PROTECTED]

>>

>> Naka

>> http://www5.ocn.ne.jp/~tomohito/TopPage.html

>>

>> */

>> - Original Message -

>> From: "Kathey Marsden" <[EMAIL PROTECTED]>

>> To: "Derby Development" 

>> Sent: Tuesday, May 10, 2005 5:02 AM

>> Subject: Re: BulkInsert ? (Re: DERBY-167 has done but ...)

>>

>>

>>> Satheesh Bandaram wrote:

>>>

>>>> BulkInsert is an internal mechanism, that gets used
when you import

>>>> data into a table, using Derby's import mechanism.

>>>> (SYSCS_UTIL.SYSCS_IMPORT_TABLE

>>>> )
This is not directly

>>>> exposed to applications using JDBC or SQL, so there is
no way to

>>>> directly invoke it. If you write some test cases for
your feature

>>>> using this procedure, you are testing bulkInsert code.
Are you

>>>> familiar with importing/exporting tables? Looking at
Derby manuals >>>> for

>>>> information would be very useful.

>>>

>>> I think you could add a test to tools/ieptests.sql

>>> which tests loading a table with an identity column.

>>>

>>> Kathey

>>>

>>>

>>>

>>>

>>>

>>> --

>>> No virus found in this incoming message.

>>> Checked by AVG Anti-Virus.

>>> Version: 7.0.308 / Virus Database: 266.11.6 - Release
Date: 2005/05/06

>>>

>>

>>

>> --

>> No virus found in this outgoing message.

>> Checked by AVG Anti-Virus.

>> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date:
2005/05/09

>>

>>

>>

>>

>> --

>> No virus found in this incoming message.

>> Checked by AVG Anti-Virus.

>> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date:
2005/05/09

>>

>>

>

>

>

> --

> No virus found in this outgoing message.

> Checked by AVG Anti-Virus.

> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date:
2005/05/09

>

>

>

>

> --

> No virus found in this incoming message.

> Checked by AVG Anti-Virus.

> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date:
2005/05/09

>


--

No virus found in this outgoing message.

Checked by AVG Anti-Virus.

Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 2005/05/09

Re: [PATCH] Derby-127





Commited this patch.

Sending   
java\engine\org\apache\derby\impl\sql\compile\OrderByColumn.java
Sending   
java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java
Sending   
java\engine\org\apache\derby\impl\sql\compile\TableName.java
Sending   
java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
Sending   
java\testing\org\apache\derbyTesting\functionTests\master\orderby.out
Sending   
java\testing\org\apache\derbyTesting\functionTests\tests\lang\orderby.sql
Transmitting file data ..
Committed revision 169744.

Jack Klebanoff wrote:
I have
attached a patch that fixes Jira bug Derby-127
(http://issues.apache.org/jira/browse/DERBY-127). The problem is with
select statements that use a correlation name in the select list, a
group by clause, and an order by clause that refers to a column by its
database name instead of its correlation name. e.g.
  
 select c1 as x from t where ... group by x order by c1
  
Derby throws an exception with SQLState 42x04 complaining that it
cannot resolve "c1".
  
  
The underlying problem is that the Derby parser transforms the select
into a query tree for the following statement:
  
 select * from (select c1 as x from t where ...) order by c1
  
The code in class OrderByColumn did not take this into account. I
changed methods pullUpOrderByColumn and bindOrderByColumn to handle
this case specially. pullUpOrderByColumn adds the sort key to the
ResultColumnList if it cannot find it there. It is called before
binding and before select list wildcards ("*") are expanded. I changed
it to pull the sort key into the ResultColumnList of the subselect
generated to handle GROUP BY. I also changed it to remember where it
was added. This simplifies the bindOrderByColumn, which is called after
pullUpOrderByColumn.
  
  
I also fixed the handling of table names in class OrderByColumn. It
treated them as strings, which does not work when the schema or table
name is a quoted string containing a period. I changed OrderByColumn to
use class TableName to represent a table name. The
ResultColumnList.getOrderByColumn methods where changed accordingly
  
  
Jack Klebanoff.
  
  

Index: java/engine/org/apache/derby/impl/sql/compile/TableName.java
===
--- java/engine/org/apache/derby/impl/sql/compile/TableName.java	(revision 168148)
+++ java/engine/org/apache/derby/impl/sql/compile/TableName.java	(working copy)
@@ -206,6 +206,9 @@
 	 */
 	public boolean equals(TableName otherTableName)
 	{
+if( otherTableName == null)
+return false;
+
 		String fullTableName = getFullTableName();
 		if (fullTableName == null)
 		{
Index: java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
===
--- java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj	(revision 168148)
+++ java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj	(working copy)
@@ -7305,6 +7305,12 @@
 			 *
 			 * RESOLVE - someday we should try to find matching aggregates
 			 * instead of just adding them.
+ *
+ * NOTE: This rewriting of the query tree makes the handling of an ORDER BY
+ * clause difficult. See OrderByColumn.pullUpOrderByColumn. It makes specific
+ * assumptions about the structure of the generated query tree. Do not make
+ * any changes to this transformation without carefully considering the
+ * OrderByColumn pullUpOrderByColumn and bindOrderByColumn methods.
 			 */
 			if (havingClause != null)
 			{
Index: java/engine/org/apache/derby/impl/sql/compile/OrderByColumn.java
===
--- java/engine/org/apache/derby/impl/sql/compile/OrderByColumn.java	(revision 168148)
+++ java/engine/org/apache/derby/impl/sql/compile/OrderByColumn.java	(working copy)
@@ -30,6 +30,8 @@
 import org.apache.derby.iapi.sql.compile.NodeFactory;
 import org.apache.derby.iapi.sql.compile.C_NodeTypes;
 
+import org.apache.derby.iapi.util.ReuseFactory;
+
 /**
  * An OrderByColumn is a column in the ORDER BY clause.  An OrderByColumn
  * can be ordered ascending or descending.
@@ -44,6 +46,12 @@
 	private ResultColumn	resultCol;
 	private boolean			ascending = true;
 	private ValueNode _expression_;
+/**
+ * If this sort key is added to the result column list then it is at result column position
+ * 1 + resultColumnList.size() - resultColumnList.getOrderBySelect() + addedColumnOffset
+ * If the sort key is already in the reault colum list then addedColumnOffset < 0.
+ */
+private int addedColumnOffset = -1;
 
 
 	/**
@@ -161,31 +169,23 @@
 			}
 
 		}else{
-			ResultColumnList targetCols = target.getResultColumns();
-			ResultColumn col = null;
-			int i = 1;
-			
-			for(i = 1;
-			i <= targetCols.size();
-			i  ++){
-
-col = targetCols.getOrderByColumn(i);
-if(c

Re: [PATCH] Derby-127

I have committed this patch. If you would like to submit test updates
later, that would be fine.

Satheesh

Jack Klebanoff wrote:

> Army wrote:
>
>> Jack Klebanoff wrote:
>>
>>> I have attached a patch that fixes Jira bug Derby-127
>>> (http://issues.apache.org/jira/browse/DERBY-127).
>>
>>
>>
>> I reviewed this patch, applied it to a clean codeline without
>> problem, and ran the orderby.sql test that was included.  From what I
>> can tell, everything looks good here.
>>
>> My only minor comment is that it might be nice to add a case to the
>> orderby.sql test to make sure things work if _multiple_ columns are
>> provided in an order by clause.  Ex.
>>
>> ij> select c1 as x, c2 as y from bug2769 group by bug2769.c1,
>> bug2769.c2 order by c1, c2;
>>
>> ij> select c1 as x, c2 as y from bug2769 group by bug2769.c1,
>> bug2769.c2 order by c1, y;
>>
>> I tried these and they both work fine--no problems there.  But it was
>> something I was wondering while I was reviewing, so it might be nice
>> to include it in the test...*shrug*
>>
>> In any event, the patch gets my +1,
>> Army
>>
>>
> I agree with Army's suggestion for an extra test. Should I wait for my
> original patch to be committed and submit the new test in a new patch,
> or should I revise and re-submit my patch? Since Army has shown that
> the patch does handle his test case I suggest committing my current
> patch first. This will get things moving. Adding a few cases to an
> existing test results in a small, easily reviewed patch. If I revise
> the submitted patch it will be more difficult to review the submission.
>
> Jack Klebanoff
>
>
>

Re: [PATCH] (DERBY-104) Get rid of the Max lenght of 18 for constraint names





Hi Bernt,

I tried to apply your patch. Most of the patch applied correctly,
except for sqlgrammar.jj. There have been other modifications to
sqlgrammar.jj since the patch was made. I could either try to fix them
up or ask you to submit another patch. It may be best if you submit a
new patch, based on Friday evening code. I will apply the patch and run
tests in my environment to catch any major failures. Then I will submit
it on Saturday morning, if the plan works for you.

You can decide if you would like to change the names of DB2 specific
constant names being discussed here. I am OK eitherway.

Satheesh

Bernt M. Johnsen wrote:

  See comments inline.

  
  

  

  

  

  

  

  Army wrote (2005-05-11 16:18:42):
  

  

  

  

  

  

Bernt M. Johnsen wrote:



  Hi all,

Could somebody review this patch (my first)? Now all identifiers
should have a max length of 128 (note: MAX_USERID_LENGTH is
unchanged).
  

I reviewed this patch and it looks good to me.  I noticed that in the JIRA 
entry for this bug, you had written that you wanted to do the following:

[  begin quote ]

2) Ensure that all DB2 related constants are prefixed by DB2_
   There are now 6 constants which do not have the prefix: 
MIN_COL_LENGTH_FOR_CURRENT_USER, MIN_COL_LENGTH_FOR_CURRENT_SCHEMA, 
MAX_USERID_LENGTH, MAX_DECIMAL_PRECISION_SCALE, DEFAULT_DECIMAL_PRECISION, 
DEFAULT_DECIMAL_SCALE
These should get the DB2_ prefix if they are DB2-related (are they?)

[ end quote ]

Did you decide to not do this part?  

  
  
I never got an answer, so I decided not to touch these constants.

  
  
For the record, the comments in the 
code suggest that the first three of these 
(MIN_COL_LENGTH_FOR_CURRENT_USER, MIN_COL_LENGTH_FOR_CURRENT_SCHEMA, and 
MAX_USERID_LENGTH) are definitely DB2-related, so adding the "DB2_" prefix 
to those would make sense.  

  
  
Should I add "DB2_"-prefix to these constants, then? (and leave the
latter-three unchanged?).

  
  
As for the latter three, one might assume that 
they are DB2-specific since they were declared in the "DB2Limits.java" 
file, but maybe that's not a valid assumption...anyone out there know??  On 
the one hand, I think these "DB2_" prefix changes could easily be checked 
in later with a different patch, if someone wants to do it.  On the other, 
it might be less inuitive to people browsing changes to see a solo patch 
that adds a "DB2_" prefix to some constants in "Limits.java"--at the very 
least, the patch to do so would have to be very well-commented, or else it 
could lead to confusion.



  NOTE: I couldn't get svn diff to reflect that I have renamed one file
(done with svn rename). If it is a problem, I can undo the rename and
submit a new patch.
  

I did have problems applying the patch to the my local codeline, and I'm 
pretty sure it was because of this.  In order to get the patch to apply, I 
manually copied "DB2Limit.java" to "Limits.java"--after doing that (and 
only that), I was then able to successfully apply the patch.  So whoever 
commits this might need to do the same, or else use some other trick to get 
the patch to apply correctly.

  
  
Seems to me that this is a weakness in the way we submit pathces
(probably a weakness in svn).

  
  
After applying the patch I ran a couple of the tests that were affected, 
and they passed as expected.

One last question: did you have a chance to run the "derbyall" suite on 
this to make sure you caught all of the relevant tests?  I'm guessing that 
you did based on the number of masters that you updated, but it'd be nice 
to confirm--typically when you submit a patch, it's good to indicate what 
tests you ran (and on what platforms/JVMs) just so that reviewers know you 
actually tested your patch before posting it (which you clearly
did!) ;)

  
  
Yes, I ran derbyall:

Java Version:1.4.2_02
Java Vendor: Sun Microsystems Inc.
OS name: Linux
OS architecture: i386
OS version:  2.4.20-31.9

  
  
All in all, looks good to me.

  
  
Thanks.

Re: Strange behaviour when combining column alias and group by

Well, fix for Derby-127 doesn't fix this. Looks like we need a new Jira
entry. Exposed name handling is getting better, but looks like still has
some kinks.

Satheesh

Bernt M. Johnsen wrote:

>I stumbeled across this strange behaviour when combining coumn alias
>and group by:
>
>ij> select * from tt;
>I  |J  
>---
>1  |2  
>2  |3  
>1  |2  
>2  |3  
>2  |3  
>
>5 rows selected
>ij> select i, count(*) as cnt from tt group by i;
>I  |CNT
>---
>1  |2  
>2  |3  
>
>2 rows selected
>ij> select i, count(*) as i from tt group by i;
>I  |I  
>---
>1  |1  
>2  |2  
>
>2 rows selected
>
>The last select is obviously wrong! This might be related to
>DERBY-127, but if it's not I'll file it asa separate issue.
>
>
>  
>

Re: Can someone assign me to DERBY-253?

You should be able to assign it to yourself now. You have been added to
'derby-developers' alias.

Satheesh

Olav Sandstaa wrote:

>Hi,
>
>I volunteer to look into the following JIRA issue:
>
>  DERBY-253: Client should throw not implemented exception for depricated 
> setUnicodeStream/getUnicodeStream
>
>I can't assign myself, so can someone please assign it to me?
>
>JIRA username: olav
>
>Thanks,
>Olav
>
>  
>

Re: Can someone assign me to DERBY-249?