[jira] Commented: (DERBY-1378) post Derby jars to Maven2 repository

[Andrew McIntyre (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1378?page=comments#action_12421801 ] 

Andrew McIntyre commented on DERBY-1378:


Hi John,

No, I haven't. This request originally referred to the 10.1.2.1 jars, and now I 
see that the 10.1.3.1 jars are now in the maven 2 repository at ibiblio!

I searched on people.apache.org and couldn't find the 10.1.3.1 jars in any 
expected location for mirroring for maven. It would be very nice to find out a) 
who is publishing these to ibiblio and b) get the Maven 2 poms for Derby 
contributed back to Derby so that we can take care of publishing the jars to 
the Maven 2 repository as part of our release process.

Unfortunately, I know next to nothing about Maven 2. I'm not even sure where to 
look on the Apache servers for the jars that get mirrored to ibiblio. Any 
assistance you can provide with discovering the origin of the jars on ibiblio 
or with instructions on including publishing the jars to a Maven 2 repository 
as a part of our release process will be greatly appreciated.

Thank you,
andrew

> post Derby jars to Maven2 repository
> 
>
> Key: DERBY-1378
> URL: http://issues.apache.org/jira/browse/DERBY-1378
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.0, 10.1.1.1, 
> 10.1.1.2, 10.1.2.1, 10.1.2.2, 10.1.2.3, 10.1.2.4
>Reporter: Sean Sullivan
>
> Please post the Derby jars to the Maven 2 repository
> http://www.ibiblio.org/maven2

-- 
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

[jira] Updated: (DERBY-1526) build should be able to locate the Java runtime libraries from properties not sourced from ${user.home}, but inside the current subversion checkout.

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1526:
---

Issue Type: Improvement  (was: Bug)

> build should be able to locate the Java runtime libraries from properties not 
> sourced from ${user.home}, but inside the current subversion checkout.
> 
>
> Key: DERBY-1526
> URL: http://issues.apache.org/jira/browse/DERBY-1526
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.2.0.0
>Reporter: Ray Kiddy
>Priority: Minor
>
> I think it is problemmatic that the Derby build process makes use of, for 
> example, ${user.home}/ant.properties.
> I would actually like to be able to build multiple versions of Derby. I also 
> cannot see what is gained by relying on the user's home directory in this 
> manner. All of this information could be put into a configuration that can be 
> kept in the project directory. That would work just fine.
> By the way, I am looking at the top-of-tree code. How do I refer to that in 
> the "Affects Version" box above? This version is 422938.
> thanx - ray

-- 
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

[jira] Updated: (DERBY-1526) build should be able to locate the Java runtime libraries from properties not sourced from ${user.home}, but inside the current subversion checkout.

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1526:
---

  Summary: build should be able to locate the Java runtime 
libraries from properties not sourced from ${user.home}, but inside the current 
subversion checkout.  (was: building does not need to use ${user.home} and it 
should not do so)
Affects Version/s: 10.2.0.0
  Description: 
I think it is problemmatic that the Derby build process makes use of, for 
example, ${user.home}/ant.properties.

I would actually like to be able to build multiple versions of Derby. I also 
cannot see what is gained by relying on the user's home directory in this 
manner. All of this information could be put into a configuration that can be 
kept in the project directory. That would work just fine.

By the way, I am looking at the top-of-tree code. How do I refer to that in the 
"Affects Version" box above? This version is 422938.

thanx - ray


  was:

I think it is problemmatic that the Derby build process makes use of, for 
example, ${user.home}/ant.properties.

I would actually like to be able to build multiple versions of Derby. I also 
cannot see what is gained by relying on the user's home directory in this 
manner. All of this information could be put into a configuration that can be 
kept in the project directory. That would work just fine.

By the way, I am looking at the top-of-tree code. How do I refer to that in the 
"Affects Version" box above? This version is 422938.

thanx - ray



Marking this as an improvement, since the current setup works in most 
situations. I've edited the summary to more accurately indicate the improvement 
that could be made.

> build should be able to locate the Java runtime libraries from properties not 
> sourced from ${user.home}, but inside the current subversion checkout.
> 
>
> Key: DERBY-1526
> URL: http://issues.apache.org/jira/browse/DERBY-1526
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Affects Versions: 10.2.0.0
>Reporter: Ray Kiddy
>Priority: Minor
>
> I think it is problemmatic that the Derby build process makes use of, for 
> example, ${user.home}/ant.properties.
> I would actually like to be able to build multiple versions of Derby. I also 
> cannot see what is gained by relying on the user's home directory in this 
> manner. All of this information could be put into a configuration that can be 
> kept in the project directory. That would work just fine.
> By the way, I am looking at the top-of-tree code. How do I refer to that in 
> the "Affects Version" box above? This version is 422938.
> thanx - ray

-- 
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

[jira] Updated: (DERBY-1525) Permissions-related syscat failures under DerbyNetClient on jdk1.3

[Mamta A. Satoor (JIRA)]

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

Mamta A. Satoor updated DERBY-1525:
---

Attachment: DERBY1525syscatmasterdiff.txt
DERBY1525syscatmasterstat.txt

I missed the jdk13 master for syscat and that's why the test failure. I have 
attached the fix for the master. svn diff is attached as 
DERBY1525syscatmasterdiff.txt and svn stat -q is attached as 
DERBY1525syscatmasterstat.txt. Can a commiter please commit the patch?

> Permissions-related syscat failures under DerbyNetClient on jdk1.3
> --
>
> Key: DERBY-1525
> URL: http://issues.apache.org/jira/browse/DERBY-1525
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.2.0.0
> Environment: linux jdk1.3
>Reporter: Rick Hillegas
> Assigned To: Mamta A. Satoor
> Fix For: 10.2.0.0
>
> Attachments: DERBY1525syscatmasterdiff.txt, 
> DERBY1525syscatmasterstat.txt
>
>
> I'm seeing the following diffs in syscat under DerbyNetClient on 1.3:
> MasterFileName = master/DerbyNetClient/syscat.out
> 83a84
> > SYSCOLPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> > derby.storage.minimumRecordSize=1, derby.storage.pageReservedSpace
> =0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }
> 100a102
> > SYSROUTINEPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> > derby.storage.minimumRecordSize=1, derby.storage.pageReservedS
> pace=0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }
> 106a109
> > SYSTABLEPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> > derby.storage.minimumRecordSize=1, derby.storage.pageReservedSpa
> ce=0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }
> 281a285
> > SYSCOLPERMS |1
> 308a313
> > SYSROUTINEPERMS |1
> 318a324
> > SYSTABLEPERMS |1
> 501a508
> > SYSCOLPERMS |1
> 528a536
> > SYSROUTINEPERMS |1
> 538a547
> > SYSTABLEPERMS |1
> Test Failed.
> *** End:   syscat jdk1.3.1_16 DerbyNetClient 2006-07-17 15:42:34 ***

-- 
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

[jira] Commented: (DERBY-1526) building does not need to use ${user.home} and it should not do so

[Andrew McIntyre (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1526?page=comments#action_12421792 ] 

Andrew McIntyre commented on DERBY-1526:


The only information expected to be in ${user.home}/ant.properties for the 
Derby build is the location of the runtime java libraries that are accessible 
to the current user. These runtime classes can (and should) be static across 
Derby versions. i.e. the versions of Java that you use to build any particular 
version of Derby should consistently build multiple versions of Derby. There 
shouldn't be any information in ${user.home}/ant.properties that is specific to 
a specific version of Derby.

With the current setup, I can specify the locations of the multiple versions of 
the runtime classes needed to build Derby once for each machine/user where I am 
building in the user's ant.properties. Then, I can build 10.0, 10.1, and 10.2 
without needing to change anything but the directory where I've checked out the 
source. The requirements on Mac OS X for the content in ant.properties is 
somewhat different, as noted in BUILDING.txt, but once set up, I can build 
Derby 10.0, 10.1, and the trunk without needing to set up a separate properties 
file for each individual checkout of the source. I find this very handy.

That said, I can understand the desire not to introduce a dependency on a 
user-space file. I think there is room for improvement here if we also sourced 
a file from ${basedir} in addition to the user.home, in case a user wants to 
have these base properties sourced from a file that is specific to a particular 
checkout of Derby.

As far as the affects version, there currently is not a way to track specific 
Subversion revisions in JIRA. Since it looks like you are working with the 
trunk, we are tracking the current trunk version as 10.2.0.0 in JIRA. For the 
other versions, the latest released 10.1 version is 10.1.3.1 and the latest 
released 10.0 version is 10.0.2.1.

> building does not need to use ${user.home} and it should not do so
> --
>
> Key: DERBY-1526
> URL: http://issues.apache.org/jira/browse/DERBY-1526
> Project: Derby
>  Issue Type: Bug
>  Components: Build tools
>Reporter: Ray Kiddy
>Priority: Minor
>
> I think it is problemmatic that the Derby build process makes use of, for 
> example, ${user.home}/ant.properties.
> I would actually like to be able to build multiple versions of Derby. I also 
> cannot see what is gained by relying on the user's home directory in this 
> manner. All of this information could be put into a configuration that can be 
> kept in the project directory. That would work just fine.
> By the way, I am looking at the top-of-tree code. How do I refer to that in 
> the "Affects Version" box above? This version is 422938.
> thanx - ray

-- 
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

Re: [jira] Commented: (DERBY-1395) Change the client SQLState to match that of embedded for the exception thrown on a closed statement whose connection is also closed

[Knut Anders Hatlen]

"Knut Anders Hatlen (JIRA)"  writes:

> [ 
> http://issues.apache.org/jira/browse/DERBY-1395?page=comments#action_12421766 
> ] 
> 
> Knut Anders Hatlen commented on DERBY-1395:
> ---
>
> Hi David,
> I think the patch looks good. +1 to commit.

That is, +1 to commit if derbyall passes. I guess there are a couple
of master files to update (I noticed that jdbcapi/checkDataSource.java
failed).

-- 
Knut Anders

[jira] Assigned: (DERBY-1525) Permissions-related syscat failures under DerbyNetClient on jdk1.3

[Mamta A. Satoor (JIRA)]

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

Mamta A. Satoor reassigned DERBY-1525:
--

Assignee: Mamta A. Satoor

> Permissions-related syscat failures under DerbyNetClient on jdk1.3
> --
>
> Key: DERBY-1525
> URL: http://issues.apache.org/jira/browse/DERBY-1525
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.2.0.0
> Environment: linux jdk1.3
>Reporter: Rick Hillegas
> Assigned To: Mamta A. Satoor
> Fix For: 10.2.0.0
>
>
> I'm seeing the following diffs in syscat under DerbyNetClient on 1.3:
> MasterFileName = master/DerbyNetClient/syscat.out
> 83a84
> > SYSCOLPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> > derby.storage.minimumRecordSize=1, derby.storage.pageReservedSpace
> =0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }
> 100a102
> > SYSROUTINEPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> > derby.storage.minimumRecordSize=1, derby.storage.pageReservedS
> pace=0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }
> 106a109
> > SYSTABLEPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> > derby.storage.minimumRecordSize=1, derby.storage.pageReservedSpa
> ce=0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }
> 281a285
> > SYSCOLPERMS |1
> 308a313
> > SYSROUTINEPERMS |1
> 318a324
> > SYSTABLEPERMS |1
> 501a508
> > SYSCOLPERMS |1
> 528a536
> > SYSROUTINEPERMS |1
> 538a547
> > SYSTABLEPERMS |1
> Test Failed.
> *** End:   syscat jdk1.3.1_16 DerbyNetClient 2006-07-17 15:42:34 ***

-- 
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

[jira] Commented: (DERBY-1378) post Derby jars to Maven2 repository

[John Sisson (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1378?page=comments#action_12421788 ] 

John Sisson commented on DERBY-1378:


Andrew, did you end up finding out who created the 10.1.3.1 poms ?

Thanks,
John

> post Derby jars to Maven2 repository
> 
>
> Key: DERBY-1378
> URL: http://issues.apache.org/jira/browse/DERBY-1378
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.0, 10.1.1.1, 
> 10.1.1.2, 10.1.2.1, 10.1.2.2, 10.1.2.3, 10.1.2.4
>Reporter: Sean Sullivan
>
> Please post the Derby jars to the Maven 2 repository
> http://www.ibiblio.org/maven2

-- 
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

[jira] Commented: (DERBY-1395) Change the client SQLState to match that of embedded for the exception thrown on a closed statement whose connection is also closed

[Knut Anders Hatlen (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1395?page=comments#action_12421766 ] 

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

Hi David,
I think the patch looks good. +1 to commit.

> Change the client SQLState to match that of embedded for the exception thrown 
> on a closed statement whose connection is also closed
> ---
>
> Key: DERBY-1395
> URL: http://issues.apache.org/jira/browse/DERBY-1395
> Project: Derby
>  Issue Type: Improvement
>  Components: Network Client
>Affects Versions: 10.2.0.0, 10.1.3.0
>Reporter: Deepa Remesh
> Assigned To: David Van Couvering
>Priority: Trivial
> Attachments: DERBY-1395.diff
>
>
> Scenario: Both connection and statement are closed and an operation is 
> performed on a closed statement. SQLStates are as follows:
> Embedded: SQLSTATE: XJ012, Message: Statement Closed
> Client before DERBY-843 fix: SQLSTATE = null, message = Statement closed
> Client after DERBY-843 fix: SQLSTATE: 08003, Message: connection closed
> This issue is related to the effort started in DERBY-254.

-- 
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

[jira] Created: (DERBY-1526) building does not need to use ${user.home} and it should not do so

[Ray Kiddy (JIRA)]

building does not need to use ${user.home} and it should not do so
--

 Key: DERBY-1526
 URL: http://issues.apache.org/jira/browse/DERBY-1526
 Project: Derby
  Issue Type: Bug
  Components: Build tools
Reporter: Ray Kiddy
Priority: Minor



I think it is problemmatic that the Derby build process makes use of, for 
example, ${user.home}/ant.properties.

I would actually like to be able to build multiple versions of Derby. I also 
cannot see what is gained by relying on the user's home directory in this 
manner. All of this information could be put into a configuration that can be 
kept in the project directory. That would work just fine.

By the way, I am looking at the top-of-tree code. How do I refer to that in the 
"Affects Version" box above? This version is 422938.

thanx - ray


-- 
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

Regression Test Failure! - TinderBox_Derby 422909 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 422909/2006-07-18 01:13:14 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.5*
1680679 2   145.46% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-422909.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/422909.html
 

Changes in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/422909.txt
 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

[jira] Updated: (DERBY-244) with linux, depending on env setting $LANG and console encoding, some i18n tests fail

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-244:
-

Derby Info:   (was: [Patch Available])

I'm removing the "patch available" flag since the patch does not seem to work 
with IBM's JVM. I think the console.encoding has to be set as well. 

> with linux, depending on env setting $LANG and console encoding, some i18n 
> tests fail
> -
>
> Key: DERBY-244
> URL: http://issues.apache.org/jira/browse/DERBY-244
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.1.1.0
> Environment: Linux, with console.encoding *not* UTF-8
>Reporter: Myrna van Lunteren
> Assigned To: Knut Anders Hatlen
>Priority: Minor
> Attachments: 244.diff, 244.stat
>
>
> The tests
>i18n/messageLocale.sql
>i18n/urlLocale.sql
>i18n/iepnegativetests_ES.sql
> will fail on Linux if $LANG and as a result, console.encoding is not set in 
> the same way as when the test master was created. The behavior is that some 
> characters are not seen as outside the ANSI range and are displayed as a ?.
> Result is as master when $LANG is en_US.UTF-8
> But then ieptest.sql will fail which will with ibm142 which pass if $LANG is 
> en_US.
> This needs some further analysis, so this description may need to be updated 
> later.
> Whatever the solution is, will need to work for all situations.

-- 
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

[jira] Commented: (DERBY-1395) Change the client SQLState to match that of embedded for the exception thrown on a closed statement whose connection is also closed

[David Van Couvering (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1395?page=comments#action_12421746 ] 

David Van Couvering commented on DERBY-1395:


Note: this passes the jdbc40 suite for both embedded and network clients.

> Change the client SQLState to match that of embedded for the exception thrown 
> on a closed statement whose connection is also closed
> ---
>
> Key: DERBY-1395
> URL: http://issues.apache.org/jira/browse/DERBY-1395
> Project: Derby
>  Issue Type: Improvement
>  Components: Network Client
>Affects Versions: 10.2.0.0, 10.1.3.0
>Reporter: Deepa Remesh
> Assigned To: David Van Couvering
>Priority: Trivial
> Attachments: DERBY-1395.diff
>
>
> Scenario: Both connection and statement are closed and an operation is 
> performed on a closed statement. SQLStates are as follows:
> Embedded: SQLSTATE: XJ012, Message: Statement Closed
> Client before DERBY-843 fix: SQLSTATE = null, message = Statement closed
> Client after DERBY-843 fix: SQLSTATE: 08003, Message: connection closed
> This issue is related to the effort started in DERBY-254.

-- 
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

[jira] Updated: (DERBY-1395) Change the client SQLState to match that of embedded for the exception thrown on a closed statement whose connection is also closed

[David Van Couvering (JIRA)]

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

David Van Couvering updated DERBY-1395:
---

Attachment: DERBY-1395.diff

Attached is the patch, running derbyall right now.  Reviews appreciated.

> Change the client SQLState to match that of embedded for the exception thrown 
> on a closed statement whose connection is also closed
> ---
>
> Key: DERBY-1395
> URL: http://issues.apache.org/jira/browse/DERBY-1395
> Project: Derby
>  Issue Type: Improvement
>  Components: Network Client
>Affects Versions: 10.2.0.0, 10.1.3.0
>Reporter: Deepa Remesh
> Assigned To: David Van Couvering
>Priority: Trivial
> Attachments: DERBY-1395.diff
>
>
> Scenario: Both connection and statement are closed and an operation is 
> performed on a closed statement. SQLStates are as follows:
> Embedded: SQLSTATE: XJ012, Message: Statement Closed
> Client before DERBY-843 fix: SQLSTATE = null, message = Statement closed
> Client after DERBY-843 fix: SQLSTATE: 08003, Message: connection closed
> This issue is related to the effort started in DERBY-254.

-- 
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

[jira] Commented: (DERBY-1029) Backout boolean work from the 10.2 branch immediately after the branch is created

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1029?page=comments#action_12421741 ] 

Rick Hillegas commented on DERBY-1029:
--

Contents of this patch are:

M  java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj
M  java\engine\org\apache\derby\iapi\reference\DRDAConstants.java
M  java\drda\org\apache\derby\impl\drda\FdocaConstants.java
M  java\drda\org\apache\derby\impl\drda\SQLTypes.java
M  java\drda\org\apache\derby\impl\drda\AppRequester.java
M  java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
M  
java\testing\org\apache\derbyTesting\functionTests\tests\lang\db2Compatibility.sql
M  java\testing\org\apache\derbyTesting\functionTests\tests\lang\logop.sql
M  java\testing\org\apache\derbyTesting\functionTests\tests\lang\schemas.sql
D  
java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\lang\BooleanTest.java
D  
java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\lang\default_app.properties
D  
java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\lang\LangSuite.java
D  
java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\lang\build.xml
M  
java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\compatibility\JDBCDriverTest.java
M  java\testing\org\apache\derbyTesting\functionTests\master\cast.out
M  
java\testing\org\apache\derbyTesting\functionTests\master\db2Compatibility.out
M  
java\testing\org\apache\derbyTesting\functionTests\master\valuesclause.out
M  
java\testing\org\apache\derbyTesting\functionTests\master\procedureInTrigger.out
M  java\testing\org\apache\derbyTesting\functionTests\master\subquery.out
M  
java\testing\org\apache\derbyTesting\functionTests\master\implicitConversions.out
M  
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk14\metadata.out
M  
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk14\syscat.out
M  java\testing\org\apache\derbyTesting\functionTests\master\logop.out
M  java\testing\org\apache\derbyTesting\functionTests\master\aggregate.out
M  
java\testing\org\apache\derbyTesting\functionTests\suites\derbylang.runall
M  java\testing\build.xml
M  java\client\org\apache\derby\client\net\Typdef.java
M  java\client\org\apache\derby\client\net\NetStatementRequest.java
M  java\client\org\apache\derby\client\am\CrossConverters.java
M  java\client\org\apache\derby\client\am\Cursor.java
M  java\client\org\apache\derby\client\am\Types.java
M  java\client\org\apache\derby\client\am\SignedBinary.java
M  java\client\org\apache\derby\client\am\DatabaseMetaData.java
M  java\client\org\apache\derby\client\am\ColumnMetaData.java

> Backout boolean work from the 10.2 branch immediately after the branch is 
> created
> -
>
> Key: DERBY-1029
> URL: http://issues.apache.org/jira/browse/DERBY-1029
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Kathey Marsden
> Assigned To: Rick Hillegas
>Priority: Blocker
> Fix For: 10.2.0.0
>
> Attachments: derby-1029_v03.diff
>
>
> There was discussion on the list regarding how  to handle this issue but keep 
> the BOOLEAN work for inclusion in future releases.  The approach discussed 
> was to back the DERBY-499 work out of the 10.2 branch as soon as it is 
> created, but leave it in the trunk
> I think this an acceptable solution but  only if we can get someone assigned 
> to this issue that is willing to commit now to doing that work as soon as we 
> branch.   The reverse merge may be messy at that point do to other changes 
> that have gone in.  
>  
> Is there someone who will volunteer to do this work and assign themselves to 
> this issue?

-- 
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

[jira] Updated: (DERBY-1029) Backout boolean work from the 10.2 branch immediately after the branch is created

[Rick Hillegas (JIRA)]

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

Rick Hillegas updated DERBY-1029:
-

Attachment: derby-1029_v03.diff

I am attaching a preliminary patch. This patch backs out the changes which had 
re-enabled the BOOLEAN datatype. I left in place the code-cleanup introduced by 
DERBY-499. I am running tests. Unless someone objects, I plan to commit this 
work when the tests run cleanly.

> Backout boolean work from the 10.2 branch immediately after the branch is 
> created
> -
>
> Key: DERBY-1029
> URL: http://issues.apache.org/jira/browse/DERBY-1029
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Kathey Marsden
> Assigned To: Rick Hillegas
>Priority: Blocker
> Fix For: 10.2.0.0
>
> Attachments: derby-1029_v03.diff
>
>
> There was discussion on the list regarding how  to handle this issue but keep 
> the BOOLEAN work for inclusion in future releases.  The approach discussed 
> was to back the DERBY-499 work out of the 10.2 branch as soon as it is 
> created, but leave it in the trunk
> I think this an acceptable solution but  only if we can get someone assigned 
> to this issue that is willing to commit now to doing that work as soon as we 
> branch.   The reverse merge may be messy at that point do to other changes 
> that have gone in.  
>  
> Is there someone who will volunteer to do this work and assign themselves to 
> this issue?

-- 
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

[jira] Commented: (DERBY-1029) Backout boolean work from the 10.2 branch immediately after the branch is created

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1029?page=comments#action_12421739 ] 

Rick Hillegas commented on DERBY-1029:
--

>From the email thread titled "Status of adding BOOLEAN-type":

I have given up on re-enabling the BOOLEAN datatype in the near term, for the 
following reasons:

1) I can't see when or whether the BOOLEAN datatype will make it into the DRDA 
spec. After 9 months, the spec's governing body has failed to revive. There 
seems to be very little industry interest in funding the continuation of DRDA 
spec work.

2) The existing (10.1) behavior of Derby BOOLEAN violates the ANSI casting 
rules. See DERBY-887. Fixing these casts will break Derby's ODBC metadata and 
for that reason we suspect that customer applications will break also. This 
appears to be the kind of compatibility issue which requires a major rather 
than a minor release of Derby. I see the following options:

a) Expose a BOOLEAN datatype which does not conform to the ANSI spec.
b) Break existing customer applications.
c) Wait until the next major release of Derby before re-enabling BOOLEAN.

My vote would be for (2c) but I don't sense enough enthusiasm for BOOLEAN to 
justify a major release in the near term.


> Backout boolean work from the 10.2 branch immediately after the branch is 
> created
> -
>
> Key: DERBY-1029
> URL: http://issues.apache.org/jira/browse/DERBY-1029
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Kathey Marsden
> Assigned To: Rick Hillegas
>Priority: Blocker
> Fix For: 10.2.0.0
>
>
> There was discussion on the list regarding how  to handle this issue but keep 
> the BOOLEAN work for inclusion in future releases.  The approach discussed 
> was to back the DERBY-499 work out of the 10.2 branch as soon as it is 
> created, but leave it in the trunk
> I think this an acceptable solution but  only if we can get someone assigned 
> to this issue that is willing to commit now to doing that work as soon as we 
> branch.   The reverse merge may be messy at that point do to other changes 
> that have gone in.  
>  
> Is there someone who will volunteer to do this work and assign themselves to 
> this issue?

-- 
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

[jira] Created: (DERBY-1525) Permissions-related syscat failures under DerbyNetClient on jdk1.3

[Rick Hillegas (JIRA)]

Permissions-related syscat failures under DerbyNetClient on jdk1.3
--

 Key: DERBY-1525
 URL: http://issues.apache.org/jira/browse/DERBY-1525
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.2.0.0
 Environment: linux jdk1.3
Reporter: Rick Hillegas
 Fix For: 10.2.0.0


I'm seeing the following diffs in syscat under DerbyNetClient on 1.3:

MasterFileName = master/DerbyNetClient/syscat.out
83a84
> SYSCOLPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> derby.storage.minimumRecordSize=1, derby.storage.pageReservedSpace
=0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }



100a102
> SYSROUTINEPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> derby.storage.minimumRecordSize=1, derby.storage.pageReservedS
pace=0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }



106a109
> SYSTABLEPERMS_INDEX2 |{ derby.storage.initialPages=1, 
> derby.storage.minimumRecordSize=1, derby.storage.pageReservedSpa
ce=0, derby.storage.pageSize=4096, derby.storage.reusableRecordId=true }



281a285
> SYSCOLPERMS |1
308a313
> SYSROUTINEPERMS |1
318a324
> SYSTABLEPERMS |1
501a508
> SYSCOLPERMS |1
528a536
> SYSROUTINEPERMS |1
538a547
> SYSTABLEPERMS |1
Test Failed.
*** End:   syscat jdk1.3.1_16 DerbyNetClient 2006-07-17 15:42:34 ***

-- 
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

[jira] Commented: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()

[Kathey Marsden (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-815?page=comments#action_12421738 ] 

Kathey Marsden commented on DERBY-815:
--

I would like to look at committing  this patch.  Dyre I was wondering if you 
could sync it up. It seems to have become out of date since you posted it in 
February.  Sorry for the long delay in  looking at it.

 

> Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
> -
>
> Key: DERBY-815
> URL: http://issues.apache.org/jira/browse/DERBY-815
> Project: Derby
>  Issue Type: Sub-task
>  Components: Network Server, Performance
>Affects Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 
> 10.1.3.0, 10.1.2.2, 10.0.2.2
>Reporter: Knut Anders Hatlen
> Assigned To: Dyre Tjeldvoll
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: d815_regress.diff, d815_regress.java, derby-815.diff, 
> derby-815.html, derby-815.v3.diff, derby-815.v3.html, derby-815.v3.stat, 
> derby-815_2.diff, derbyall_report_with_jdk1.4.v3.txt
>
>
> Reported by Kathey Marsden in DERBY-212:
> In reviewing the Network Server Code and profiling there were several
> areas that showed potential for providing performance
> improvement. Functions that need optimizing to prevent unneeded object
> creation and excessive decoding: parseSQLDTA_work()

-- 
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

[jira] Updated: (DERBY-1130) Client should not allow databaseName to be set with setConnectionAttributes

[Deepa Remesh (JIRA)]

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

Deepa Remesh updated DERBY-1130:


Derby Info: [Patch Available]

> Client should not allow databaseName to be set with setConnectionAttributes
> ---
>
> Key: DERBY-1130
> URL: http://issues.apache.org/jira/browse/DERBY-1130
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 
> 10.1.2.2, 10.1.2.3, 10.2.0.0, 10.1.3.0, 10.1.2.4
>Reporter: Kathey Marsden
> Assigned To: Deepa Remesh
> Attachments: derby-1130-v1.diff, derby-1130-v1.status
>
>
> Per this thread,  setConnectionAttributes should not set databaseName. 
> http://www.nabble.com/double-check-on-checkDataSource-t1187602.html#a3128621
> Currently this is allowed for client but should be disabled.  I think it is 
> OK to change because we have documented that client will be changed to match 
> embedded for implementation defined behaviour.   Hopefully its use is rare as 
> most folks would use the standard setDatabaseName.  Still there should be a 
> release not when the change is made and it would be better to change it 
> sooner than later:
> Below is the repro. 
> Here is the output with Client
> D>java DatabaseNameWithSetConnAttr
> ds.setConnectionAttributes(databaseName=wombat;create=true)
> ds.getDatabaseName() = null (should be null)
> FAIL: Should not have been able to set databaseName with connection attributes
> Also look for tests  disabled with this bug number in the test 
> checkDataSource30.java
> import java.sql.*;
> import java.lang.reflect.Method;
> public class DatabaseNameWithSetConnAttr{
>   public static void main(String[] args) {
>   try {
>   
>   String attributes = "databaseName=wombat;create=true";
>   org.apache.derby.jdbc.ClientDataSource ds = new
>   org.apache.derby.jdbc.ClientDataSource();
>   //org.apache.derby.jdbc.EmbeddedDataSource ds = new
>   //org.apache.derby.jdbc.EmbeddedDataSource();
>   System.out.println("ds.setConnectionAttributes(" + 
> attributes + ")");
>   ds.setConnectionAttributes(attributes);
>   System.out.println("ds.getDatabaseName() = " +
>  ds.getDatabaseName() 
> + " (should be null)" );
>   Connection conn  = ds.getConnection();
>   } catch (SQLException e) {
>   String sqlState = e.getSQLState();
>   if (sqlState != null && 
> sqlState.equals("XJ041"))
>   {
>   System.out.println("PASS: An exception was 
> thrown trying to get a connetion from a datasource after setting databaseName 
> with setConnectionAttributes");
>   System.out.println("EXPECTED EXCEPTION: " + 
> e.getSQLState() 
>  + " 
> - " + e.getMessage());
>   return;
>   }
>   while (e != null)
>   {
>   System.out.println("FAIL - UNEXPECTED 
> EXCEPTION: " + e.getSQLState());
>   e.printStackTrace();
>   e = e.getNextException();
>   }
>   return;
>   }
>   System.out.println("FAIL: Should not have been able to set 
> databaseName with connection attributes");
>   }
> }

-- 
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

[jira] Updated: (DERBY-1130) Client should not allow databaseName to be set with setConnectionAttributes

[Deepa Remesh (JIRA)]

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

Deepa Remesh updated DERBY-1130:


Attachment: derby-1130-v1.diff
derby-1130-v1.status

Attaching a patch 'derby-1130-v1.diff' which ensures that database name set 
using setConnectionAttributes does not get used by client driver. Changes are:

* Appends the attributes in setConnectionAttributes method to database name 
only if database name has been already set on the data source. Database name is 
a required property and if it is not set, DataSource.getConnection method will 
throw the following exception:
08001 - Required property databaseName not set. 

Without the patch, if database name was not set, the code was using "null" as 
database name and creating a database named null if  "create=true" is specified 
or throwing an exception that it cannot connect to database named null.

* Adds test to jdbcapi/checkDataSource.java. Adds a new method 
"testClientDSConnectionAttributes". As we are testing the methods specific to 
Derby data sources, we cannot re-use the method used to test embedded data 
sources.

Ran derbynetclientmats with this patch using Sun jdk 1.4.2 on Windows XP. No 
failures. Also ran the modified tests jdbcapi/checkDataSource.java and 
jdbcapi/checkDataSource30.java in embedded mode. Please review/commit this 
patch. Thanks.

> Client should not allow databaseName to be set with setConnectionAttributes
> ---
>
> Key: DERBY-1130
> URL: http://issues.apache.org/jira/browse/DERBY-1130
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 
> 10.1.2.2, 10.1.2.3, 10.2.0.0, 10.1.3.0, 10.1.2.4
>Reporter: Kathey Marsden
> Assigned To: Deepa Remesh
> Attachments: derby-1130-v1.diff, derby-1130-v1.status
>
>
> Per this thread,  setConnectionAttributes should not set databaseName. 
> http://www.nabble.com/double-check-on-checkDataSource-t1187602.html#a3128621
> Currently this is allowed for client but should be disabled.  I think it is 
> OK to change because we have documented that client will be changed to match 
> embedded for implementation defined behaviour.   Hopefully its use is rare as 
> most folks would use the standard setDatabaseName.  Still there should be a 
> release not when the change is made and it would be better to change it 
> sooner than later:
> Below is the repro. 
> Here is the output with Client
> D>java DatabaseNameWithSetConnAttr
> ds.setConnectionAttributes(databaseName=wombat;create=true)
> ds.getDatabaseName() = null (should be null)
> FAIL: Should not have been able to set databaseName with connection attributes
> Also look for tests  disabled with this bug number in the test 
> checkDataSource30.java
> import java.sql.*;
> import java.lang.reflect.Method;
> public class DatabaseNameWithSetConnAttr{
>   public static void main(String[] args) {
>   try {
>   
>   String attributes = "databaseName=wombat;create=true";
>   org.apache.derby.jdbc.ClientDataSource ds = new
>   org.apache.derby.jdbc.ClientDataSource();
>   //org.apache.derby.jdbc.EmbeddedDataSource ds = new
>   //org.apache.derby.jdbc.EmbeddedDataSource();
>   System.out.println("ds.setConnectionAttributes(" + 
> attributes + ")");
>   ds.setConnectionAttributes(attributes);
>   System.out.println("ds.getDatabaseName() = " +
>  ds.getDatabaseName() 
> + " (should be null)" );
>   Connection conn  = ds.getConnection();
>   } catch (SQLException e) {
>   String sqlState = e.getSQLState();
>   if (sqlState != null && 
> sqlState.equals("XJ041"))
>   {
>   System.out.println("PASS: An exception was 
> thrown trying to get a connetion from a datasource after setting databaseName 
> with setConnectionAttributes");
>   System.out.println("EXPECTED EXCEPTION: " + 
> e.getSQLState() 
>  + " 
> - " + e.getMessage());
>   return;
>   }
>   while (e != null)
>   {
>   System.out.println("FAIL - UNEXPECTED 
> EXCEPTION: " + e.getSQLState());
>   e.printStackTrace();
>   e = e.getNextException();
>   }
> 

Re: [PATCH] To add comments to DRDAProtocolExceptionInfo ( was Re: Question about DRDAProtocolExceptionInfo fields.)

[Knut Anders Hatlen]

Sunitha Kambhampati <[EMAIL PROTECTED]> writes:

> Thanks Knut Anders. I agree with them.  I am attaching a patch to add
> these comments to the code.

Thank you, Sunitha! I have committed the patch with revision 422882.

-- 
Knut Anders

[jira] Updated: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1516:
---

Component/s: JDBC

> Inconsistent behavior for getBytes and getSubString for embedded versus 
> network
> ---
>
> Key: DERBY-1516
> URL: http://issues.apache.org/jira/browse/DERBY-1516
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Reporter: Craig Russell
>Priority: Minor
> Attachments: DERBY-1516.patch
>
>
> org.apache.derby.client.am.Clob.getSubString(pos, length) and 
> org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for 
> less than zero. 
> if ((pos <= 0) || (length < 0)) {
> throw new SqlException(agent_.logWriter_, "Invalid position " 
> + pos + " or length " + length);
> But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and 
> org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less 
> than or equal to zero.
>if (length <= 0)
> throw Util.generateCsSQLException(
> SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
> The specification does not disallow length of zero, so zero length should be 
> allowed. I believe that the implementation in org.apache.derby.client.am is 
> correct, and the implementation in org.apache.derby.impl.jdbc is incorrect. 

-- 
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

[jira] Resolved: (DERBY-982) sysinfo api does not provide genus name for client

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre resolved DERBY-982.
---

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

Committed patch -v5 to trunk with revision 422876.

> sysinfo api does not provide genus name for client
> --
>
> Key: DERBY-982
> URL: http://issues.apache.org/jira/browse/DERBY-982
> Project: Derby
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 10.1.2.1
>Reporter: Kathey Marsden
> Assigned To: Andrew McIntyre
> Fix For: 10.2.0.0
>
> Attachments: derby-982-v4.diff, derby-982-v5.diff, derby-982.diff, 
> derby-982_v2.diff, derby-982_v3.diff
>
>
> The sysinfo api does not provide access to the genus name for client to allow 
> applications to retrieve information from sysinfo about the client 
> information.
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/tools/sysinfo.html
> Note: Currently ProductGenusNames has a genus name for network server but 
> network server is closely tied to  the engine so should always have the same 
> version.

-- 
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

[jira] Resolved: (DERBY-1466) Network Server should flush the PrintWriter after console output

[David Van Couvering (JIRA)]

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

David Van Couvering resolved DERBY-1466.


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

Submitted revision 42286

> Network Server should flush the PrintWriter after console output
> 
>
> Key: DERBY-1466
> URL: http://issues.apache.org/jira/browse/DERBY-1466
> Project: Derby
>  Issue Type: Improvement
>  Components: Network Server
>Affects Versions: 10.1.2.1
>Reporter: Kathey Marsden
> Attachments: derby1466.diff.txt, derby1466.stat.txt
>
>
> If Network Server is started with a PrintWriter specified for console output 
> it will not automatically flush output such as  starting the server.  This 
> can be confusing as the console output shows no activity.
> Users currently need to specify the PrintWriter to autoflush  e.g.
>  starterWriter = new PrintWriter(new FileOutputStream(new 
> File(SERVER_START_LOG)),true); 
> derbyServer = new NetworkServerControl();
>  derbyServer.start(starterWriter); 
> For repro see:
> http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html
> And change the following line in the program to not autoflush as follows:
> starterWriter = new PrintWriter(new FileOutputStream(new 
> File(SERVER_START_LOG)),false); 

-- 
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

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

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

Kristian Waagan updated DERBY-1417:
---

Attachment: derby-1417-3b-embimpl-and-tests.diff
derby-1417-3b-embimpl-and-tests.stat

Thanks for the review Knut Anders!
My replies follow the order of the questions in your comment.

 - I forgot to duplicate the methods from PreparedStatement40 in
   EmbedCallableStatement40 (no inheritance here). I have added them in the
   new patch. I followed the "policy" of keeping unimplemented methods in the
   JDBC40 specific classes. I still get 21 failures in VerifySignatures, but
   all are in the Brokered* classes.

 - Brokered* methods will be added in a follow-up patch (I feel this patch is
   already too big). Since no JDBC4 tests are picking up these missing methods
   except for the dynamic ones (VerifySignatures, UnsupportedVetter,
   ClosedObjects), I think maybe we should run more of our tests with
   XA/pooled connections. Does anyone else feel the same?

 - I have fixed the JavaDoc errors.

EmbedResultSet.java:
 - Removed "@throws SQLFeatureNotSupported" in JavaDoc.
 
 - Shortened long line.

 - Yes, the switch can be factored out. I decided to put this on hold, as I'm
   not sure what is the best approach. It makes sense to factor out the
   occurences where only the type is checked, and no other action is taken
   based on the type. This is typical for the ResultSet.updateX methods, but
   not for ResultSet.getXStream methods. Not sure if
   DataTypeDescriptor.isJDBCTypeEquivalent() can be used as it is, for
   instance it does not know anything about Types.BLOB.
   The common mechanism should/could also be used across different classes,
   for instance in both EmbedResultSet and EmbedPreparedStatement. So, where
   should it be placed?
   Feel free to add a Jira to track this.

EmbedPreparedStatement.java:
 - Ok. Names changed.

 - Removed "@throws SQLFeatureNotSupported" in JavaDoc.

 - Shortened long line.

 - I removed the comments about DB2 compliance (these were already present
   before my patch).

ReaderToUTF8Stream.java:
 - Was not sure how to handle this. I guess only getting this with debug/sane
   builds is good enough. I replaced the exception with a
   SanityManager.DEBUG block.

Tests:
 - I added DERBY-1524 for the assertEquals-overloads (a sub-task of 1122).

 - This will be added as part of DERBY-1473. Might have to do something on the
   client side also.

In addition to the comments from the review, I changed the following (not
related to my patch):
 - Modified EmbedResultSet.updateAsciiStream(int,InputStream,long) to use
   updateCharacterStreamInternal instead of updateCharacterStream to avoid
   duplicate checks.

 - Removed blank line at the end of EmbedResultSet.java.

 - Corrected spelling error in PreparedStatementTest: Inerted -> Inserted


I reran suite jdbc4. Only saw 3 expected failures: ClosedObjectTest,
UnsupportedVetter and VerifySignatures.
'derby-1417-3b-embimpl-and-tests.diff' is ready for more review and/or commit.

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String p

Re: enabling tracing info while running tests

[Myrna van Lunteren]

On 7/17/06, Mayuresh Nirhali <[EMAIL PROTECTED]> wrote:

>>Hello,
>>
>>I am trying to get tracing info for a test run in standalone
>>manner. The test runs fine, but I do not see the traceFile being
>>created.
I tried following but didn't get the trace file.

java -cp $CLASSPATH -Djvmflags=derby.drda.traceFile=trace.out
org.apache.derby.drda.NetworkServerControl start



Oops! just my 2 cents on that one...(note that I'm not really
following the discussion, too wrapped up at the moment with other
tasks, sorry).

-Djvmflags will do anything for NetworkServerControl, it only works
with the test harness
(org.apache.derbyTesting.functionTests.harness.RunTest or RunSuite).

Apologies if I confused the issue. With NetworkServerControl you want
to just use -Dderby.drda.traceFile=, I think, if that property is
valid at all. Same for derby.drda.traceDirectory, to pass it to
NetworkServerControl, don't use the test harness' jvmFlags...

When you run a test with RunTest, you can use -Dverbose=true
-Dkeepfiles=true to see the actual command it is using, then look at
the *_app.properties and *_derby.properties file within the test
subdirectory to see the actual properties it has picked up...Then work
your modifications from there.

hth
Myrna

[jira] Commented: (DERBY-694) Statement exceptions cause all the connection's result sets to be closed with the client driver

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-694?page=comments#action_12421705 ] 

Rick Hillegas commented on DERBY-694:
-

Hi, Narayanan. Thanks for tackling this bug and for the explanatory html page. 
I am far from being an expert on this corner of the code. However, the 
following issues jump occur to me:

1) I don't see a regression test case for this problem. Please add a test case 
to derbyall.

2) Shouldn't Connection.completeSpecificRollback( UnitOfWorkListener uwl ) call 
uwl.completeLocalRollback() just as Connection.completeLocalRollback() does? It 
may be that the UnitOfWorkListener.completeLocalRollback() in question is a NOP 
right now, but that could change in the future.

3) I am wondering whether this fixes the whole bug. Should similar logic be 
added to network ResultSets as well as Statements? What happens if we get a 
STATEMENT_SEVERITY exception while calling a ResultSet method?


> Statement exceptions cause all the connection's result sets to be closed with 
> the client driver
> ---
>
> Key: DERBY-694
> URL: http://issues.apache.org/jira/browse/DERBY-694
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.1.1.1
>Reporter: Oyvind Bakksjo
> Assigned To: V.Narayanan
>Priority: Minor
> Attachments: DERBY-694.html, DERBY-694_upload_v1.diff, 
> DERBY-694_upload_v1.stat, StatementRollbackTest.java
>
>
> Scenario:
> Autocommit off. Have two prepared statements, calling executeQuery() on both, 
> giving me two result sets. Can fetch data from both with next(). If one 
> statement gets an exception (say, caused by a division by zero), not only 
> this statement's result set is closed, but also the other open resultset. 
> This happens with the client driver, whereas in embedded mode, the other 
> result set is unaffected by the exception in the first result set (as it 
> should be).

-- 
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

[jira] Commented: (DERBY-1483) Java Function defined with a BIGINT parameter invokes the method with a signature of method(long) rather than method(Long)

[Stan Bradbury (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1483?page=comments#action_12421701 ] 

Stan Bradbury commented on DERBY-1483:
--

Regarding the table in the Reference manual that Kathey lists in her comment: 

The section title and text do not tell me that this has anything to do with 
Derby Java Functions.  The page title is:  "CallableStatements and INOUT 
Parameters".

It states that the method needs to accept an array, is this true? The method 
tied to my function takes a long, not an array of longs  and appears to work 
fine.

Because Kathey listed this I suspect this page contains the informaiton needed 
but it is not obvious to my untrained eye that this information applies to Java 
functions and procedures nor (I assume) that the column labeled 'Value and 
Return Type' lists the parameter type to be used instead of the column labeled: 
'Array Type for Method Parameter'.  An explanation / additional clarification 
will be required before we link this table to the manual sections on Java 
Procedures and Functions.

> Java Function defined with a BIGINT parameter invokes the method with a 
> signature of method(long) rather than method(Long)
> --
>
> Key: DERBY-1483
> URL: http://issues.apache.org/jira/browse/DERBY-1483
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 10.1.2.1
>Reporter: Stan Bradbury
>Priority: Minor
>
> Calling a function passing BIGINT to a method accepting Long fails with the 
> message:
> ERROR 42X50: No method was found that matched the method call 
> derbyJavaUtils.bigintToHexString(long), tried all combinations of object and 
> primitive types and any possible type conversion for any  parameters the 
> method call may have. The method might exist but it is not public and/or 
> static, or the parameter types are not method invocation convertible.
> The method needs to accept the primative type: long to work.  BIGINT as 
> docuemented as having a compile time type of java.lang.Long - this is why I 
> expected the example method to work: see the Reference manual: 
> http://db.apache.org/derby/docs/10.1/ref/rrefsqlj30435.html.
>   
> Example: define the function bigintToHexString to accept a BIGINT parameter 
> (see below) and reference the corresponding  java method bigintToHexString 
> (shown below) that accepts a Long.  Add the jarfile with the class to the DB, 
> setup the database classpath and invoke with the query shown.
>   >>> Java Class:
> import java.sql.*;
> public class derbyJavaUtils
> {
> // bigintToHexString
> public static String bigintToHexString(Long myBigint)
> {
>   return myBigint.toHexString(myBigint.longValue());
> }
> // bigintToHexString2 - this will work if used for the function
> public static String bigintToHexString2(long myBigint)
> {
>   Long myLong = null;
>   return myLong.toHexString(myBigint);
> }
> }
>  >> COMPILE IT AND JAR IT :  jar -cvf derbyJavaUtils.jar DerbyJavaUtils.class
> >> Setup the function as follows in a database:
>   .. CALL sqlj.install_jar( 'derbyJavaUtils.jar','APP.derbyJavaUtils',0);
>   .. CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath', 
> 'APP.derbyJavaUtils');
>   .. CREATE FUNCTION app.bigintToHexString(hexString bigint)
> RETURNS VARCHAR(16)
> PARAMETER STYLE JAVA NO SQL
> LANGUAGE JAVA 
> EXTERNAL NAME 'derbyJavaUtils.bigintToHexString'
>   === One possible test query:
> select  'C' ||  bigintToHexString2(CONGLOMERATENUMBER) ||  '.dat', TABLENAME, 
> ISINDEX
> from SYS.SYSCONGLOMERATES a, SYS.SYSTABLES b
>   where a.TABLEID = b.TABLEID
>   As mention in the code comments the method: bigintToHexString2 - will work 
> if used for the function

-- 
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

DERBY-528 - IRC discussion summary between KatheyM and FrancoisO

[Francois Orsini]

This is a summary of the IRC discussion Kathey M. and I had today.
Posting it on derby-dev to record it - Thanks again for your time and
help Kathey.

        francois: Did you
want to talk about DERBY-528? We can talk here on #derby and then
summarize to the list.
        I'm going to post some details as you've asked
        The big question
for me is that I want to make sure this doesn't cause any new upgrade
order restrictions
        It should not with the current changes
        10.1 /10.2
servers/clients need to continue to work together without change. Even
if it is that the DERBY-528 fix exposes an existing but, it needs to be
resolved before DERBY-528 goes in.
        Does that make sense?
        Absolutely
        Oh sorry, then I am confused about your original question
        ok - let me explain
        not question, statement about the incompatibility.
        The current
changes as they have been posted do not cause 10.1 /10.2
servers/clients connection(s) to fail - all compatibility tests are
passing
        ok. You made a code change then to do that from your original patch?
        Yes I did
        I have
backed out the default upgraded secmec to use as SECMEC_USRSSBPWD
(password substitute)
        Because we
can't process on the client the list of SecMec's returned from a server
which does not support this new SecMec (SECMEC_USRSSBPWD)
        For instance, 10.2 <--> 10.1
        I see I really missed that from your patch update description.
        If I could
parse that list on the client side, then SECMEC_USRSSBPWD could be used
as a default upgraded secmec after SECMEC_EUSRIDPWD for instance
        Yes, sorry my description was not clear
        Hence why I entered http://issues.apache.org/jira/browse/DERBY-1517
        Then after the fix for DERBY-1517 you will be able to reenable?
        Yep
        and It was working great until I ran the full compatibility tests
        I had run
lots of tests w/ SECMEC_USRSSBPWD so I know it had been working fine,
except when going 10.2 --> 10.1
        I understand. I
was wondering if you could post a summary of the changes that the
DERBY-528 patch makes in some detail to make it a little easier to
review.
        Yes am writing it now
        But Derby-1517 is tricky
        Excellent. I will wait for that and then review.
        The server version is not returned from a ACCSECRD :(
        Right. I was worried about that. It is too early right?
        I have to
recheck again but I did not see it - Yes it is too early as you
mentioned in the notes
        But then am
trying to see if I could still parse the list returned today, instead
of the array (as the specs mentioned)
        good. It would be good to upgrade the default.
        Absolutely - This was my original intention and changes
        This security mechanism implementation has ben a challenging one
        Thanks for taking
it on. On the coding format. The only place I saw the indentation not
matching the surrounding code was BasicAuthenticationServiceImpl with a
visual diff.
        Due to the
fact, well, there is no way to decrypt a substituted (hashed) password
:)
        Ok - I'm going to look at these and address them
        It is awful that we don't have a coding standard
        Yeah and
then it is hard to copy code that does not look standard when you need
to put new changes - am always tempted to fix code around but then it
is confusing the review
        Need to ask you something about db2jcc
        what is 2.6 and 2.8 under master\DerbyNet
        Someone will
eventually get sick of it and pick up DERBY-1363. every new developer
gets bitten by that bug.
        Yes. They are JCC versions. What JCC version are you using?
        Am using 2.4
        OK. When you post
your summary comment. Just add that JCC 2.6, 2.8 also need to be
updated and ask if someone with access can update the masters.
        I can probably do it as part of my review.
        ok I will ask
        Thanks for your time Kathey
        Thank you Francois.

Cheers,

--francois

[jira] Updated: (DERBY-982) sysinfo api does not provide genus name for client

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-982:
--

Attachment: derby-982-v5.diff

Updated patch that changes the constructor for sysinfo_api.java to take a 
String.

I will commit this shortly.

> sysinfo api does not provide genus name for client
> --
>
> Key: DERBY-982
> URL: http://issues.apache.org/jira/browse/DERBY-982
> Project: Derby
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 10.1.2.1
>Reporter: Kathey Marsden
> Assigned To: Andrew McIntyre
> Fix For: 10.2.0.0
>
> Attachments: derby-982-v4.diff, derby-982-v5.diff, derby-982.diff, 
> derby-982_v2.diff, derby-982_v3.diff
>
>
> The sysinfo api does not provide access to the genus name for client to allow 
> applications to retrieve information from sysinfo about the client 
> information.
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/tools/sysinfo.html
> Note: Currently ProductGenusNames has a genus name for network server but 
> network server is closely tied to  the engine so should always have the same 
> version.

-- 
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

[jira] Updated: (DERBY-1524) Add assertEquals overloads for InputStream and Reader

[Kristian Waagan (JIRA)]

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

Kristian Waagan updated DERBY-1524:
---

  Component/s: Test
  Description: 
Add assertEquals overloads for java.io.InputStream and java.io.Reader to 
BaseTestCase.

Implementations of these can be found in test jdbc4/ResultSetTest.java and can 
be moved or used as reference.
Affects Version/s: 10.2.0.0
 Priority: Minor  (was: Major)

> Add assertEquals overloads for InputStream and Reader
> -
>
> Key: DERBY-1524
> URL: http://issues.apache.org/jira/browse/DERBY-1524
> Project: Derby
>  Issue Type: Sub-task
>  Components: Test
>Affects Versions: 10.2.0.0
>Reporter: Kristian Waagan
>Priority: Minor
>
> Add assertEquals overloads for java.io.InputStream and java.io.Reader to 
> BaseTestCase.
> Implementations of these can be found in test jdbc4/ResultSetTest.java and 
> can be moved or used as reference.

-- 
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

[jira] Created: (DERBY-1524) Add assertEquals overloads for InputStream and Reader

[Kristian Waagan (JIRA)]

Add assertEquals overloads for InputStream and Reader
-

 Key: DERBY-1524
 URL: http://issues.apache.org/jira/browse/DERBY-1524
 Project: Derby
  Issue Type: Sub-task
Reporter: Kristian Waagan




-- 
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

[jira] Closed: (DERBY-1514) Failures in derbyall in trunk seen after revision 421960

[Deepa Remesh (JIRA)]

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

Deepa Remesh closed DERBY-1514.
---


> Failures in derbyall in trunk seen after revision 421960
> 
>
> Key: DERBY-1514
> URL: http://issues.apache.org/jira/browse/DERBY-1514
> Project: Derby
>  Issue Type: Test
>  Components: Regression Test Failure
>Affects Versions: 10.2.0.0
>Reporter: Deepa Remesh
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.0.0
>
>
> List of failures seen in 
> http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/421960-derbyall_diff.txt:
> derbyall/storeall/storeall.fail:store/testsqldecimal.sql
> derbyall/storeall/storeall.fail:store/backupRestore.sql
> derbyall/storeall/storeall.fail:store/onlineBackupTest4.sql
> /derbyall.fail:nist/dml076.sql
> /derbyall.fail:nist/dml034.sql
> /derbyall.fail:nist/dml026.sql
> /derbyall.fail:nist/dml099.sql
> /derbyall.fail:nist/dml148.sql
> In the above failures, store/onlineBackupTest4.sql seems to be intermittent 
> and not seen in the next test run.

-- 
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

[PATCH] To add comments to DRDAProtocolExceptionInfo ( was Re: Question about DRDAProtocolExceptionInfo fields.)

[Sunitha Kambhampati]

Thanks Knut Anders. I agree with them.  I am attaching a patch to add 
these comments to the code.


svn stat
M  java\drda\org\apache\derby\impl\drda\DRDAProtocolExceptionInfo.java

Can someone please commit this patch if it looks ok. This patch has only 
comments added, so I did ant clobber and ant all and the build went 
fine.  I have not run any tests.


Thanks,
Sunitha.

Knut Anders Hatlen wrote:


Sunitha Kambhampati <[EMAIL PROTECTED]> writes:

 


DRDAProtocolExceptionInfo has 4 fields.   The comments are unclear to
me. Does anyone know what is the difference between the errorCodePoint
and the errCdCodePoint ?
   



I'm just guessing here, but it seems to me that errorCodePoint
specifies the code point of the error reply message, whereas
errCdCodePoint specifies the code point of an extra required field in
that reply message. Most error reply messages have one or two required
fields that are quite common, like SVRCOD (severity code) or RDBNAM
(database name). Some error reply messages additionally have required
fields that are specific to them. errCdCodePoint is used to specify
these. For instance, SYNTAXRM has a required field called SYNERRCD,
and PRCCNVRM has a required field called PRCCNVCD.
 



Index: java/drda/org/apache/derby/impl/drda/DRDAProtocolExceptionInfo.java
===
--- java/drda/org/apache/derby/impl/drda/DRDAProtocolExceptionInfo.java 
(revision 412194)
+++ java/drda/org/apache/derby/impl/drda/DRDAProtocolExceptionInfo.java 
(working copy)
@@ -26,13 +26,27 @@
   Holds static information about the protocol error
   to put in the Hash Table
 */
-// The Codepoint of the error (e.g CodePoint.SYTNAXRM)
+
+/**
+ * errorCodePoint specifies the code point of the error reply message, 
(e.g.
+ * CodePoint.SYNTAXRM) whereas errCdCodePoint specifies the code point of 
an
+ * extra required field in that reply message. Most error reply messages
+ * have one or two required fields that are quite common, like SVRCOD
+ * (severity code) or RDBNAM (database name). Some error reply messages
+ * additionally have required fields that are specific to them.
+ * errCdCodePoint is used to specify these. For instance, SYNTAXRM has a
+ * required field called SYNERRCD, and PRCCNVRM has a required field called
+ * PRCCNVCD.
+ */
 protected int errorCodePoint; 
 
 // Severity Code
 protected int svrcod;
 
-// The CodePoint describing the errCD (e.g. CodePint.SYNERRCD)
+/**
+ * The CodePoint describing the error condition for the errorCodePoint.
+ * (e.g. CodePoint.SYNERRCD, when errorCodePoint is CodePoint.SYNTAXRM)
+ */
 protected int errCdCodePoint ;
 
 // Sends an originating Codepoint

Re: Derby-dev mail digest gets "by" wrong in header

[Jean T. Anderson]

This looks like http://issues.apache.org/jira/browse/INFRA-370

 -jean

Craig L Russell wrote:
> Hi,
> 
> The Derby dev message digest, with subject derby-dev Digest 17 Jul  2006
> 08:29:31 - Issue 1094
> 
> is broken. The header contains:
> 
> [jira] Created: (DERBY-1516) Inconsistent behavior for getBytes and 
> getSubString for embedded versus network
> 24147 by: Bryan Pendleton (JIRA)
> 
> [jira] Updated: (DERBY-1516) Inconsistent behavior for getBytes and 
> getSubString for embedded versus network
> 24148 by: Bryan Pendleton (JIRA)
> 24154 by: Kathey Marsden
> 
> But the DERBY-1516 was actually created by Craig Russell as you can  see
> from later in the digest message:
> 
> From: "Craig Russell (JIRA)" 
> Date: July 16, 2006 1:10:13 PM PDT
> To: derby-dev@db.apache.org
> Subject: [jira] Created: (DERBY-1516) Inconsistent behavior for 
> getBytes and getSubString for embedded versus network
> 
> 
> Inconsistent behavior for getBytes and getSubString for embedded  versus
> network
> 
> ---
> 
>  Key: DERBY-1516
>  URL: http://issues.apache.org/jira/browse/DERBY-1516
>  Project: Derby
>   Issue Type: Bug
> Reporter: Craig Russell
> Priority: Minor
> 
> Any idea what might be going wrong here?
> 
> I blind copied derby-dev in case anyone there has any insight, but I 
> suspect this is just a mail infrastructure issue.
> 
> Craig
> 
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:[EMAIL PROTECTED]
> P.S. A good JDO? O, Gasp!
> 
> 

[jira] Created: (DERBY-1523) Statements in cache need to depend on privileges and the appropriate statements in cache should get invalidated if those privileges change.

[Mamta A. Satoor (JIRA)]

Statements in cache need to depend on privileges and the appropriate statements 
in cache should get invalidated if those privileges change.
---

 Key: DERBY-1523
 URL: http://issues.apache.org/jira/browse/DERBY-1523
 Project: Derby
  Issue Type: Bug
  Components: Miscellaneous
Affects Versions: 10.2.0.0
Reporter: Mamta A. Satoor
 Fix For: 10.2.0.0


In Derby SQL Standard Authorization model, statements need to keep track of 
what privileges they depend on so that their plans can be later invalidated if 
those privileges are revoked. This may happen once the revoke privilege (this 
includes explicit revoke privilege or indirect revoke privilege action by 
dependency manager when the object on the privilege is granted is dropped) work 
is all finished but I wanted to open a separate JIRA entry so we don't loose 
track of statement caching.

Currently, the last sql statement in following set of sql statements will raise 
a null pointer exception

connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta1' as 
mamta1;
create table t11ConstraintTest (c111 int not null, c112 int not null, primary 
key (c111, c112));
grant references on t11ConstraintTest to mamta3;
connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta3' as 
mamta3;
drop table t31ConstraintTest;
-- the following statement should remember that it depends on REFERENCES 
privilege on mamta1.t11ConstraintTest 
create table t31ConstraintTest (c311 int, c312 int, foreign key(c311, c312) 
references mamta1.t11ConstraintTest);
drop table t31ConstraintTest;
set connection mamta1;
-- following should revoke all the privileges granted on it
drop table t11ConstraintTest;
create table t11ConstraintTest (c111 int not null, c112 int not null, primary 
key (c111, c112));
grant references(c111) on t11ConstraintTest to mamta3;
grant references(c112) on t11ConstraintTest to PUBLIC;
--connect 'jdbc:derby:c:/dellater/dbmaintest2;create=true' user 'mamta3' as 
mamta3;
set connection mamta3;
drop table t31ConstraintTest;
-- following sql should recompie itself because the earlier plan depended on a 
privilege which doesn't
-- exist anymore. Instead, new privileges have been granted and the plan for 
following statement should depend
-- on those new privileges
create table t31ConstraintTest (c311 int, c312 int, foreign key(c311, c312) 
references mamta1.t11ConstraintTest);

All this work is in the langauge layer but I don't seem Language as one of the 
components in JIRA hence I have put it in Miscellaneous category for now.


-- 
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

[jira] Commented: (DERBY-1517) Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers

[Kathey Marsden (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1517?page=comments#action_12421669 ] 

Kathey Marsden commented on DERBY-1517:
---

I want to understand the user  impact of this issue  with and without the patch 
for DERBY-528. Do I understand the description correctly that if DERBY-528 
patch is applied,  10.2 clients do not work with 10.1 servers but without the 
DERBY-528 patch there is no impact on users?  

Thanks

Kathey

> Derby Network Client to handle list of SECMEC(s) returned by 
> existing/released DRDA Derby Network Servers
> -
>
> Key: DERBY-1517
> URL: http://issues.apache.org/jira/browse/DERBY-1517
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
> Environment: The Derby network client should be made capable of 
> handling a list of SECMEC(s) returned by previously released DRDA Derby 
> network servers
>Reporter: Francois Orsini
> Fix For: 10.2.0.0
>
>
> Currently, the Derby DRDA network server does not *properly* return the list 
> of SECMEC(s) it can support if a client is requesting to authenticate with a 
> non-supported SECMEC (see JIRA-926 - 
> http://issues.apache.org/jira/browse/DERBY-926)
> The motivation for this JIRA is to add the logic for the Derby client to be 
> capable of parsing the list of supported SECMEC(s) returned by previous 
> released Derby network servers (pre-JIRA-926 Fix) - This is necessary for 
> backwards compatibility with older servers - This issue has been even more 
> visible as Derby-528 introduces support for a new DRDA security mechanism 
> (Strong Password Substitute), which causes a DRDA protocol exception when 
> trying to authenticate with the new supported mechanism against older Derby 
> DRDA servers (JIRA-926 issue)
> JIRA-926 has to be fixed nonetheless on the server side to properly return 
> the list of supported SECMEC(s) in conformance with the DRDA (DDM) specs - 
> This JIRA focuses on the client side to do its best and be capable of parsing 
> a list of SECMEC(s) returned pre-926 fix.
> Ultimately, the derby network client can be made capable of parsing a list of 
> SECMEC(s) from pre-926 fixed (older) and post-926 fixed servers...

-- 
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

Re: [jira] Updated: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme

[Francois Orsini]

On 7/14/06, Sunitha Kambhampati <[EMAIL PROTECTED]> wrote:

Francois Orsini (JIRA) wrote:

>So for now, USRSSBPWD  is no longer the default after EUSRIDPWD in the client 
until DERBY-926 is fixed or a temporary handling of the protocol exception 
reported as in DERBY-926 is duoable in Derby's client driver.
>
>
I thought DERBY-926 was a server issue. Is that not the case ?


Hi Sunitha,

Yes it is - I meant to say that the DRDA protocol exception is
documented in DERBY-926 and that eventhough this bug has to be fixed
on the server side, it would be good to try and parse in the network
client,  the list of SECMEC(s)  returned by older servers which won't
have the fix to DERBY-926, even when this last one is fixed. I have
entered DERBY-1517 for that and was hoping to be able to parse the
current and incorrectly formatted list of SECMEC(s) returned, instead
of getting a DRDA protocol exception raised when a securityMechanism
is sent to a server which does not support it...

Cheers,

--francois



Thanks,
Sunitha.

[jira] Created: (DERBY-1522) Switch(if supported) from Derby Authorization to Derby SQL Standard Authorization needs to be tested

[Mamta A. Satoor (JIRA)]

Switch(if supported) from Derby Authorization to Derby SQL Standard 
Authorization needs to be tested


 Key: DERBY-1522
 URL: http://issues.apache.org/jira/browse/DERBY-1522
 Project: Derby
  Issue Type: Task
  Components: JDBC
Affects Versions: 10.2.0.0
Reporter: Mamta A. Satoor
 Fix For: 10.2.0.0


There has been discussions on the Derby-dev list about switch from Derby 
Authorization to Derby SQL Standard Authorization for existing databases. If we 
do decide to support a switch like that, testing needs to be done/added to make 
sure everything works fine after the switch.

ps I have added this JIRA entry to JDBC component but I am not 100% sure if 
that is the right component.


-- 
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

[jira] Created: (DERBY-1521) Upgrade test needs to be enhanced to test grant revoke

[Mamta A. Satoor (JIRA)]

Upgrade test needs to be enhanced to test grant revoke
--

 Key: DERBY-1521
 URL: http://issues.apache.org/jira/browse/DERBY-1521
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.2.0.0
Reporter: Mamta A. Satoor
 Fix For: 10.2.0.0


Grant Revoke is one of the features targeted for 10.2 Release. The upgrade test 
should be modified to test this feature with various upgrade scenarios to make 
sure everything works fine.

-- 
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

Re: enabling tracing info while running tests

[Mayuresh Nirhali]

Knut Anders Hatlen wrote:


Mayuresh Nirhali <[EMAIL PROTECTED]> writes:

 


Hello,

I am trying to get tracing info for a test run in standalone
manner. The test runs fine, but I do not see the traceFile being
created.

The command I use is as below,


java -cp $CLASSPATH -Dframework=DerbyNetClient
-DtestSpecialProps=derby.infolog.append=true^derby.drda.traceFile=./trace.out^derby.drda.traceLevel=org.apache.derby.jdbc.ClientDataSource.TRACE_PROTOCOL_FLOWS
org.apache.derbyTesting.functionTests.harness.RunTest
jdbcapi/parameterMapping.java

Is there anything that I am missing ??

What is the best way to generate tracing data for tests ??
   



Hi Mayuresh,

derby.drda.traceFile should be passed to the network server process,
but I'm not sure whether testSpecialProps does that. By the way, I
don't think there is a derby.drda.traceFile property, but there is a
derby.drda.traceDirectory.

What I usually do when I need server-side tracing of a test, is
starting the network server with the required parameters before
running the test. Since a server is already running, the test harness
won't start a new one.
 


I tried following but didn't get the trace file.

java -cp $CLASSPATH -Djvmflags=derby.drda.traceFile=trace.out 
org.apache.derby.drda.NetworkServerControl start


i also tried derby.drda.traceDirectory instead in the above command, but 
no luck.

Could you please post your command for my reference ??

any docs/twiki for more info on debugging ??


To enable client-side tracing, you need to modify the connection
URL. For parameterMapping.java, I think you can do that by adding
"ij.database=jdbc:derby:wombat;create=true;traceFile=trace.out" to
parameterMapping_app.properties.

 

I created a new file in tests/jdbcapi directory, 
parameterMapping_derby.properties and added following 2 lines,

derby.drda.traceFile=trace.out
derby.drda.traceAll=true

and ran the test in DerbyNetClient mode (w/o starting server 
separately), the test has been running for almost 20 mins now, could it 
be this slow ??


Mayuresh

[jira] Created: (DERBY-1520) Document new SYSCS_DIAG tables

[Stan Bradbury (JIRA)]

Document new SYSCS_DIAG tables 
---

 Key: DERBY-1520
 URL: http://issues.apache.org/jira/browse/DERBY-1520
 Project: Derby
  Issue Type: Sub-task
  Components: Documentation
Affects Versions: 10.2.0.0
Reporter: Stan Bradbury


See comments for DERBY-571 for initial documentation discussion.  The new 
tables (mapped to the old Diagnostic VTIs) are:

The old style syntax will remain in place for 10.2, but become deprecated.

The tables to be implemented in this change are:

SYSCS_DIAG.LOCK_TABLE replaces org.apache.derby.diag.LockTable
SYSCS_DIAG.STATEMENT_CACHE replaces org.apache.derby.diag.StatementCache
SYSCS_DIAG.TRANSACTION_TABLE replaces org.apache.derby.diag.TransactionTable
SYSCS_DIAG.ERROR_MESSAGES replaces org.apache.derby.diag.ErrorMessages 

The information about the tables can be found in the javadoc for the class 
listed above.
That can be found at:

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

click on the org.apache.derby.diag link in the Packages table, then select each 
class, e.g. LockTable to see the info.

-- 
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

[jira] Updated: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality

[Mamta A. Satoor (JIRA)]

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

Mamta A. Satoor updated DERBY-1330:
---

Attachment: Derby1330MinorCleanupV7diff.txt
Derby1330MinorCleanupV7stat.txt

I have an extremely minor patch attached to this JIRA entry (svn diff attached 
as Derby1330MinorCleanupV7diff.txt and svn stat -q attached as 
Derby1330MinorCleanupV7stat.txt). There is a typo in 
SYSROUTINEPERMSRowFactory.java for one of the variables and this patch fixes 
just that. I have run the 2 grant revoke tests and they ran fine. I don't see a 
need to run derbyall but let me know if someone thinks it should be run.

> Provide runtime privilege checking for grant/revoke functionality
> -
>
> Key: DERBY-1330
> URL: http://issues.apache.org/jira/browse/DERBY-1330
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Mamta A. Satoor
> Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, 
> AuthorizationModelForDerbySQLStandardAuthorizationV2.html, 
> Derby1330MinorCleanupV7diff.txt, Derby1330MinorCleanupV7stat.txt, 
> Derby1330PrivilegeCollectionV2diff.txt, 
> Derby1330PrivilegeCollectionV2stat.txt, 
> Derby1330PrivilegeCollectionV3diff.txt, 
> Derby1330PrivilegeCollectionV3stat.txt, 
> Derby1330uuidIndexForPermsSystemTablesV4diff.txt, 
> Derby1330uuidIndexForPermsSystemTablesV4stat.txt, 
> Derby1330uuidIndexForPermsSystemTablesV5diff.txt, 
> Derby1330uuidIndexForPermsSystemTablesV5stat.txt, 
> Derby1330uuidIndexForPermsSystemTablesV6diff.txt, 
> Derby1330uuidIndexForPermsSystemTablesV6stat.txt, 
> Derby1330ViewPrivilegeCollectionV1diff.txt, 
> Derby1330ViewPrivilegeCollectionV1stat.txt
>
>
> Additional work needs to be done for grant/revoke to make sure that only 
> users with required privileges can access various database objects. In order 
> to do that, first we need to collect the privilege requirements for various 
> database objects and store them in SYS.SYSREQUIREDPERM. Once we have this 
> information then when a user tries to access an object, the required 
> SYS.SYSREQUIREDPERM privileges for the object will be checked against the 
> user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and 
> SYS.SYSROUTINEPERMS. The database object access will succeed only if the user 
> has the necessary privileges.
> SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already 
> populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't 
> have any information in it at this point and hence no runtime privilege 
> checking is getting done at this point.

-- 
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

Derby-dev mail digest gets "by" wrong in header

[Craig L Russell]

Hi,The Derby dev message digest, with subject derby-dev Digest 17 Jul 2006 08:29:31 - Issue 1094  is broken. The header contains:[jira] Created: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network	24147 by: Bryan Pendleton (JIRA)[jira] Updated: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network	24148 by: Bryan Pendleton (JIRA)	24154 by: Kathey MarsdenBut the DERBY-1516 was actually created by Craig Russell as you can see from later in the digest message:From: "Craig Russell (JIRA)" Date: July 16, 2006 1:10:13 PM PDTTo: derby-dev@db.apache.orgSubject: [jira] Created: (DERBY-1516) Inconsistent behavior for getBytes and getSubString for embedded versus networkInconsistent behavior for getBytes and getSubString for embedded versus network---                 Key: DERBY-1516                 URL: http://issues.apache.org/jira/browse/DERBY-1516             Project: Derby          Issue Type: Bug            Reporter: Craig Russell            Priority: MinorAny idea what might be going wrong here?I blind copied derby-dev in case anyone there has any insight, but I suspect this is just a mail infrastructure issue.CraigCraig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!  

smime.p7s
Description: S/MIME cryptographic signature

[jira] Commented: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme

[Francois Orsini (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-528?page=comments#action_12421654 ] 

Francois Orsini commented on DERBY-528:
---

@Rick - I have to update the canons for testSecMec when it is run under the 
DerbyNet framework - Thanks.

@Kathey:
- The current changes are *not* causing a regression with the compatibility 
tests - I have entered DERBY-1517 in order to try and fix the existing issue of 
not being able to parse a list of SECMEC(s) returned by the server during 
ACCSECRD when a securityMechanism is not supported by this last one .

- No client security mechanism have been moved to 
BasicAuthenticationServiceImpl - I've added some logic during BUILTIN 
authentication to treat a password substitute - There is no way to decrypt a 
password substitute, hence during authentication, I go through the means of 
authenticating a password substitute by taking the BUILTIN stored one and 
regenerating a SECMEC_USRSSBPWD to compare with the passed-in (substitute) 
one...

- Coding standards - Am going to look into this - I usually am very careful 
with coding guidelines. 

Many thanks for the comments.

> Support for DRDA Strong User ID and Password Substitute Authentication 
> (USRSSBPWD) scheme
> -
>
> Key: DERBY-528
> URL: http://issues.apache.org/jira/browse/DERBY-528
> Project: Derby
>  Issue Type: New Feature
>  Components: Security
>Affects Versions: 10.1.1.0
>Reporter: Francois Orsini
> Assigned To: Francois Orsini
> Fix For: 10.2.0.0
>
> Attachments: 528_diff_v1.txt, 528_diff_v2.txt, 
> 528_SecMec_Testing_Table.txt, 528_stat_v1.txt, 528_stat_v2.txt
>
>
> This JIRA will add support for (DRDA) Strong User ID and Password Substitute 
> Authentication (USRSSBPWD) scheme in the network client/server driver layers.
> Current Derby DRDA network client  driver supports encrypted userid/password 
> (EUSRIDPWD) via the use of DH key-agreement protocol - however current Open 
> Group DRDA specifications imposes small prime and base generator values (256 
> bits) that prevents other JCE's  to be used as java cryptography providers - 
> typical minimum security requirements is usually of 1024 bits (512-bit 
> absolute minimum) when using DH key-agreement protocol to generate a session 
> key.
> Strong User ID and Password Substitute Authentication (USRSSBPWD) is part of 
> DRDA specifications as another alternative to provide ciphered passwords 
> across the wire.
> Support of USRSSBPWD authentication scheme will enable additional JCE's to  
> be used when encrypted passwords are required across the wire.
> USRSSBPWD authentication scheme will be specified by a Derby network client 
> user via the securityMechanism property on the connection UR - A new property 
> value such as ENCRYPTED_PASSWORD_SECURITY will be defined in order to support 
> this new (DRDA) authentication scheme.

-- 
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

Re: [jira] Commented: (DERBY-1357) Short-circuit logic in optimizer appears to be incorrect...

[Army]

Bryan Pendleton wrote:


I agree that this is a hard case, and I can see both sides. But I do think
that we can craft an umbrella release note which will be valuable to users
as they move to the new release, covering the multiple changes to the
optimizer as a single logical unit. It seems to me that the release note
should observe that:




This sounds like a great idea.  I will try to write something up and post it to 
DERBY-1357 and/or DERBY-781 shortly.


Thanks for excellent suggestion,
Army

[jira] Commented: (DERBY-781) Materialize union subqueries in select list where possible to avoid creating invariant resultsets many times.

[A B (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-781?page=comments#action_12421652 ] 

A B commented on DERBY-781:
---

Thank you so much for volunteering to do this review, Bryan--and for taking the 
time to read the write-up in its rather wordy entirety.  I really appreciate 
your time and effort here.

I'll work on putting together a release note as you described on derby-dev:

http://article.gmane.org/gmane.comp.apache.db.derby.devel/23875

and will post that to this issue and/or to DERBY-1357.

Thanks again for all of your time, Bryan!

> Materialize union subqueries in select list where possible to avoid creating 
> invariant resultsets many times.
> -
>
> Key: DERBY-781
> URL: http://issues.apache.org/jira/browse/DERBY-781
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.1.1.0, 10.2.0.0
> Environment: generic
>Reporter: Satheesh Bandaram
> Assigned To: A B
> Attachments: d781_v1.patch, d781_v1.stat, d781_v2.patch, 
> DERBY-781_v1.html
>
>
> Derby's handling of union subqueries in from list can be improved by 
> materializing invariant resultsets once, rather than creating them many times.
> For example:
> create view V1 as select i, j from T1 union select i,j from T2;
> create view V2 as select a,b from T3 union select a,b from T4;
> insert into T1 values (1,1), (2,2), (3,3), (4,4), (5,5);
> For a query like select * from V1, V2 where V1.j = V2.b and V1.i in 
> (1,2,3,4,5), it is possible the resultset for V2 is created 5 times. 
> (assuming V2 is choosen as the the inner table) This can be very costly if 
> the underlying selects can take long time and also may perform union many 
> times.
> Enhance materialization logic in setOperatorNode.java. It currently returns 
> FALSE always.
> public boolean performMaterialization(JBitSet outerTables)
>   throws StandardException
> {
>   // RESOLVE - just say no to materialization right now - should be a 
> cost based decision
>   return false;
>   /* Actual materialization, if appropriate, will be placed by our parent 
> PRN.
>* This is because PRN might have a join condition to apply.  
> (Materialization
>* can only occur before that.
>*/
>   //return true;
> } 

-- 
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

[jira] Commented: (DERBY-1377) Update copyright headers to comply with new ASF policy

[Jean T. Anderson (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1377?page=comments#action_12421647 ] 

Jean T. Anderson commented on DERBY-1377:
-

The policy is now posted at http://www.apache.org/legal/src-headers.html 

> Update copyright headers to comply with new ASF policy
> --
>
> Key: DERBY-1377
> URL: http://issues.apache.org/jira/browse/DERBY-1377
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Jean T. Anderson
>Priority: Blocker
> Fix For: 10.2.0.0
>
>
> A new copyright header policy will take effect for distributions released 
> starting on Sep 1, 2006. Committers will receive notification, but a heads up 
> with details is in the legal-discuss thread starting with 
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
> PROTECTED]
> Date was 1-Aug-2006, is now 1-Sep-2006:
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200607.mbox/[EMAIL 
> PROTECTED]

-- 
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

Re: [jira] Created: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger

[Deepa Remesh]

On 7/17/06, Rob Scheepens <[EMAIL PROTECTED]> wrote:

Goodmorning all,

I am also experiencing the conglomerate not found issue.
I use Quartz to trigger a task that will perform some actions (See below
for the stack trace).

The thread that I have read is especially interested in reproducing these
issues.
But I also want to know if you all have a solution for this problem that I
can try?

Will derby.language.statementCacheSize=0 be sufficient?



On looking at the stack trace, this does not look like the scenario
described in DERBY-1435 which is a specific case where this error
(conglomerate does not exist) can occur. To see if it is a similar
case, can you please provide the details of the task you are trying to
execute using Quartz? It would be helpful to see the database schema,
sql/jdbc program being executed.

Thanks,
Deepa

[jira] Created: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger

[Rob Scheepens]

Goodmorning all,

I am also experiencing the conglomerate not found issue.
I use Quartz to trigger a task that will perform some actions (See below  
for the stack trace).


The thread that I have read is especially interested in reproducing these  
issues.
But I also want to know if you all have a solution for this problem that I  
can try?


Will derby.language.statementCacheSize=0 be sufficient?

Thanks in advance.

Kind regards,

Rob Scheepens



***
zo, 16 jul 01:48:34.319 ERROR - MisfireHandler: Error handling misfires:  
The conglomerate (45,872) requested does not exist.
org.quartz.JobPersistenceException: The conglomerate (45,872) requested  
does not exist. [See nested exception: SQL Exception: The conglomerate  
(45,872) requested does not exist.]
	at  
org.quartz.impl.jdbcjobstore.JobStoreTX.doRecoverMisfires(JobStoreTX.java:1310)
	at  
org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:2322)
	at  
org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:2340)

* Nested Exception (Underlying Cause) ---
ERROR XSAI2: The conglomerate (45,872) requested does not exist.
	at org.apache.derby.iapi.error.StandardException.newException(Unknown  
Source)
	at  
org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(Unknown  
Source)
	at  
org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown  
Source)
	at  
org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown  
Source)
	at  
org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(Unknown  
Source)
	at org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown  
Source)
	at  
org.apache.derby.impl.sql.execute.BulkTableScanResultSet.openCore(Unknown  
Source)
	at  
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown  
Source)
	at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown  
Source)
	at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown  
Source)
	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown  
Source)
	at  
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown  
Source)
	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown  
Source)
	at  
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:92)
	at  
org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectTriggersInState(StdJDBCDelegate.java:253)
	at  
org.quartz.impl.jdbcjobstore.JobStoreSupport.recoverMisfiredJobs(JobStoreSupport.java:722)
	at  
org.quartz.impl.jdbcjobstore.JobStoreTX.doRecoverMisfires(JobStoreTX.java:1308)
	at  
org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:2322)
	at  
org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.run(JobStoreSupport.java:2340)



--

Rob Scheepens
Océ-Technologies
Dept.: CC-SI, R&D
Location: 3B-70
St. Urbanusweg 43
5914 CA Venlo
The Netherlands
P.O. Box 101
5900 MA Venlo
The Netherlands

E-mail: [EMAIL PROTECTED]
Phone: 0031-(0)77-3594428

Regression Test Failure! - TinderBox_Derby 422690 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 422690/2006-07-17 13:32:25 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.5*
7679672 2   145.24% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-422690.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/422690.html
 

Changes in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/422690.txt
 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

[jira] Updated: (DERBY-802) OutofMemory Error when reading large blob when statement type is ResultSet.TYPE_SCROLL_INSENSITIVE

[Andreas Korneliussen (JIRA)]

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

Andreas Korneliussen updated DERBY-802:
---

Attachment: derby-802v3.diff
derby-802v3.stat

Attached is a patch (derby-802v3.diff and derby-802v3.stat) which uses 
projectmappings calculated from ProjectRestrictResultSet, and 4 new testcases 
with projections has been added to BLOBTest.junit

> OutofMemory Error when reading large blob when statement type is 
> ResultSet.TYPE_SCROLL_INSENSITIVE
> --
>
> Key: DERBY-802
> URL: http://issues.apache.org/jira/browse/DERBY-802
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 
> 10.1.2.0, 10.1.2.1, 10.2.0.0, 10.1.3.0, 10.1.2.2, 10.0.2.2
> Environment: all
>Reporter: Sunitha Kambhampati
> Assigned To: Andreas Korneliussen
>Priority: Minor
> Attachments: derby-802.diff, derby-802.stat, derby-802v2.diff, 
> derby-802v3.diff, derby-802v3.stat
>
>
> Grégoire Dubois on the list reported this problem.  From his mail: the 
> reproduction is attached below. 
> When statement type is set to ResultSet.TYPE_SCROLL_INSENSITIVE, outofmemory 
> exception is thrown when reading large blobs. 
> import java.sql.*;
> import java.io.*;
> /**
> *
> * @author greg
> */
> public class derby_filewrite_fileread {
>
> private static File file = new 
> File("/mnt/BigDisk/Clips/BabyMamaDrama-JShin.wmv");
> private static File destinationFile = new 
> File("/home/greg/DerbyDatabase/"+file.getName());
>
> /** Creates a new instance of derby_filewrite_fileread */
> public derby_filewrite_fileread() {   
>
> }
>
> public static void main(String args[]) {
> try {
> 
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
> Connection connection = DriverManager.getConnection 
> ("jdbc:derby:/home/greg/DerbyDatabase/BigFileTestDB;create=true", "APP", "");
> connection.setAutoCommit(false);
>
> Statement statement = 
> connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, 
> ResultSet.CONCUR_READ_ONLY);
> ResultSet result = statement.executeQuery("SELECT TABLENAME FROM 
> SYS.SYSTABLES");
>
> // Create table if it doesn't already exists.
> boolean exist=false;
> while ( result.next() ) {
> if ("db_file".equalsIgnoreCase(result.getString(1)))
> exist=true;
> }
> if ( !exist ) {
> System.out.println("Create table db_file.");
> statement.execute("CREATE TABLE db_file ("+
>" name  VARCHAR(40),"+
>" file  BLOB(2G) NOT 
> NULL)");
> connection.commit();
> }
>
> // Read file from disk, write on DB.
> System.out.println("1 - Read file from disk, write on DB.");
> PreparedStatement 
> preparedStatement=connection.prepareStatement("INSERT INTO db_file(name,file) 
> VALUES (?,?)");
> FileInputStream fileInputStream = new FileInputStream(file);
> preparedStatement.setString(1, file.getName());
> preparedStatement.setBinaryStream(2, fileInputStream, 
> (int)file.length());   
> preparedStatement.execute();
> connection.commit();
> System.out.println("2 - END OF Read file from disk, write on 
> DB.");
>
>
> // Read file from DB, and write on disk.
> System.out.println("3 - Read file from DB, and write on disk.");
> result = statement.executeQuery("SELECT file FROM db_file WHERE 
> name='"+file.getName()+"'");
> byte[] buffer = new byte [1024];
> result.next();
> BufferedInputStream inputStream=new 
> BufferedInputStream(result.getBinaryStream(1),1024);
> FileOutputStream outputStream = new 
> FileOutputStream(destinationFile);
> int readBytes = 0;
> while (readBytes!=-1) {
> readBytes=inputStream.read(buffer,0,buffer.length);
> if ( readBytes != -1 )
> outputStream.write(buffer, 0, readBytes);
> } 
> inputStream.close();
> outputStream.close();
> System.out.println("4 - END OF Read file from DB, and write on 
> disk.");
> }
> catch (Exception e) {
> e.printStackTrace(System.err);
> }
> }
> }
> It returns
> 1 - Read file from disk, write on DB.
> 2 - END OF Read file from disk, write on DB.
>

[jira] Commented: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Knut Anders Hatlen (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12421610 ] 

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

Hi Kristian,

I have reviewed your patch. The code changes look good and derbyall
runs cleanly on Sun JVM 1.5.0. I ran the jdbc40 tests, and they
complain because some of the methods are missing from
EmbedCallableStatement40 (they should only throw not supported). Also,
they report that many methods are missing from the Brokered* classes,
but I guess you will add them in a later patch?

When I run 'ant javadoc', I see these warnings:

EmbedResultSet.java:2957: warning - @param argument "parameterIndex" is not a 
parameter name.
EmbedResultSet.java:4778: warning - @param argument "columnLabel" is not a 
parameter name.
EmbedResultSet.java:4830: warning - @param argument "x" is not a parameter name.
EmbedResultSet.java:4888: warning - @param argument "inputStream" is not a 
parameter name.
EmbedResultSet.java:4944: warning - @param argument "inputStream" is not a 
parameter name.
EmbedResultSet.java:5004: warning - @param argument "reader" is not a parameter 
name.
EmbedResultSet.java:5062: warning - @param argument "reader" is not a parameter 
name.

Some more comments/questions:

EmbedResultSet.java:

  - javadocs for for updateAsciiStream(), updateBinaryStream(),
updateCharacterStream(), updateBlob() and updateClob() say
"@throws SQLFeatureNotSupportedException if the JDBC driver does
not support this method". Since Derby does support these methods,
that sentence could be removed.

  - line exceeding 80 characters in updateCharacterStreamInternal()

  - the update* methods start with a switch on colType. Could the
switch be replaced with a call to
DataTypeDescriptor.isJDBCTypeEquivalent() or factored out somehow?

EmbedPreparedStatement.java:

  - I feel that the names of the new assert*Conditions methods are a
little confusing. When I read "assert", I first thought they were
used for asserting certain conditions in debug/sane builds. What
about renaming them to check*Conditions?

  - javadocs contain "@throws SQLFeatureNotSupportedException" for
methods that are implemented

  - line exceeding 80 characters in setBlob(int,Blob)

  - assertBlobConditions() and assertClobConditions() have a comment
about DB2 compliance. Since the behaviour it refers to (only allow
setBlob() on BLOB columns and setClob() on CLOB columns) seems to
be exactly as specified by the JDBC spec, I think referring to DB2
confuses more than it clarifies.

ReaderToUTF8Stream.java:

  - The constructor can throw an IllegalArgumentException, but it is
not caught anywhere, so it will propagate up to the application as
an IllegalArgumentException, not as an SQLException. Since this
exceptional situation only happens if there is a bug in Derby,
perhaps SanityManager.ASSERT could be used instead?

Tests:

  - the new assertEquals() methods could be useful to have in
BaseTestCase

  - I think it would be good to test that removal of trailing blanks
in clobs is handled correctly

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.

[jira] Commented: (DERBY-528) Support for DRDA Strong User ID and Password Substitute Authentication (USRSSBPWD) scheme

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-528?page=comments#action_12421609 ] 

Rick Hillegas commented on DERBY-528:
-

Hi Francois,

Derbyall had one error when I applied this patch: testSecMec under DerbyNet.

> Support for DRDA Strong User ID and Password Substitute Authentication 
> (USRSSBPWD) scheme
> -
>
> Key: DERBY-528
> URL: http://issues.apache.org/jira/browse/DERBY-528
> Project: Derby
>  Issue Type: New Feature
>  Components: Security
>Affects Versions: 10.1.1.0
>Reporter: Francois Orsini
> Assigned To: Francois Orsini
> Fix For: 10.2.0.0
>
> Attachments: 528_diff_v1.txt, 528_diff_v2.txt, 
> 528_SecMec_Testing_Table.txt, 528_stat_v1.txt, 528_stat_v2.txt
>
>
> This JIRA will add support for (DRDA) Strong User ID and Password Substitute 
> Authentication (USRSSBPWD) scheme in the network client/server driver layers.
> Current Derby DRDA network client  driver supports encrypted userid/password 
> (EUSRIDPWD) via the use of DH key-agreement protocol - however current Open 
> Group DRDA specifications imposes small prime and base generator values (256 
> bits) that prevents other JCE's  to be used as java cryptography providers - 
> typical minimum security requirements is usually of 1024 bits (512-bit 
> absolute minimum) when using DH key-agreement protocol to generate a session 
> key.
> Strong User ID and Password Substitute Authentication (USRSSBPWD) is part of 
> DRDA specifications as another alternative to provide ciphered passwords 
> across the wire.
> Support of USRSSBPWD authentication scheme will enable additional JCE's to  
> be used when encrypted passwords are required across the wire.
> USRSSBPWD authentication scheme will be specified by a Derby network client 
> user via the securityMechanism property on the connection UR - A new property 
> value such as ENCRYPTED_PASSWORD_SECURITY will be defined in order to support 
> this new (DRDA) authentication scheme.

-- 
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

[jira] Resolved: (DERBY-1514) Failures in derbyall in trunk seen after revision 421960

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen resolved DERBY-1514.
---

Fix Version/s: 10.2.0.0
   Resolution: Fixed
 Assignee: Mayuresh Nirhali

Mayuresh attached a patch for this issue to DERBY-836. Fixed in revision 422706.

> Failures in derbyall in trunk seen after revision 421960
> 
>
> Key: DERBY-1514
> URL: http://issues.apache.org/jira/browse/DERBY-1514
> Project: Derby
>  Issue Type: Test
>  Components: Regression Test Failure
>Affects Versions: 10.2.0.0
>Reporter: Deepa Remesh
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.0.0
>
>
> List of failures seen in 
> http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/421960-derbyall_diff.txt:
> derbyall/storeall/storeall.fail:store/testsqldecimal.sql
> derbyall/storeall/storeall.fail:store/backupRestore.sql
> derbyall/storeall/storeall.fail:store/onlineBackupTest4.sql
> /derbyall.fail:nist/dml076.sql
> /derbyall.fail:nist/dml034.sql
> /derbyall.fail:nist/dml026.sql
> /derbyall.fail:nist/dml099.sql
> /derbyall.fail:nist/dml148.sql
> In the above failures, store/onlineBackupTest4.sql seems to be intermittent 
> and not seen in the next test run.

-- 
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

[jira] Resolved: (DERBY-836) ResultSetMetaData.getColumnDisplaySize sometimes returns wrong values for DECIMAL columns

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen resolved DERBY-836.
--

Resolution: Fixed

Thank you, Mayuresh! I have committed the v7_2 patch into trunk with revision 
422706. Derbyall runs cleanly now.

> ResultSetMetaData.getColumnDisplaySize sometimes returns wrong values for 
> DECIMAL columns
> -
>
> Key: DERBY-836
> URL: http://issues.apache.org/jira/browse/DERBY-836
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Newcomer
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Mayuresh Nirhali
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby836-v2.diff, derby836-v3.diff, derby836-v4.diff, 
> derby836-v6.diff, derby836-v7.diff, derby836-v7_2.diff, derby836.diff, 
> derby836_v5.diff
>
>
> DECIMAL(10,0)
> max display width value:   -1234567890  length 11
> embedded : 11 correct
> client: 12 WRONG
> DECIMAL(10,10)
> max display width value:   -0.1234567890  length 13
> embedded : 13 correct
> client: 12 WRONG
> DECIMAL(10,2)
> max display width value:   -12345678.90  length 12
> embedded : 13 WRONG
> client: 12 correct
> I've added output early on in jdbcapi/metadata_test.java (and hence the tests 
> metadata.jar and odbc_metadata.java) to show this issue:
> E.g. for embedded
> DECIMAL(10,0) -- precision: 10 scale: 0 display size: 12 type name: DECIMAL
> DECIMAL(10,10) -- precision: 10 scale: 10 display size: 12 type name: DECIMAL
> DECIMAL(10,2) -- precision: 10 scale: 2 display size: 12 type name: DECIMAL
> I will add this test output once DERBY-829 is fixed so as not to cause 
> conflicts.

-- 
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

[jira] Created: (DERBY-1519) 'setAsciiStream' uses different encodings for embedded and client

[Kristian Waagan (JIRA)]

'setAsciiStream' uses different encodings for embedded and client
-

 Key: DERBY-1519
 URL: http://issues.apache.org/jira/browse/DERBY-1519
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.1.3.1, 10.2.0.0
Reporter: Kristian Waagan


The JDBC method 'setAsciiStream' uses different encodings for embedded and 
client. In the embedded driver, "ISO-8859-1" is used, in the client driver 
"US-ASCII" is used. The former is 8-bit, the latter is 7-bit. According to 
JDBC, the 8-bit encoding should be used for ASCII (see 
http://db.apache.org/derby/papers/JDBCImplementation.html#GetAsciiStream%28%29 
).

The method 'getAsciiStream' should also be made to match in the two drivers.

-- 
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

[jira] Assigned: (DERBY-1296) Setting property derby.system.bootAll causes an Exception

[Fernanda Pizzorno (JIRA)]

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

Fernanda Pizzorno reassigned DERBY-1296:


Assignee: Fernanda Pizzorno

> Setting property derby.system.bootAll causes an Exception
> -
>
> Key: DERBY-1296
> URL: http://issues.apache.org/jira/browse/DERBY-1296
> Project: Derby
>  Issue Type: Bug
>  Components: Services
>Affects Versions: 10.1.3.1
> Environment: Windows XP
>Reporter: David Heath
> Assigned To: Fernanda Pizzorno
>Priority: Critical
> Fix For: 10.2.0.0
>
>
> After creating 3 databases under c:\databases\sample - I wanted to get a list 
> of available databases, I followed the example in the "DriverPropertyInfo 
> array example" in the developer guide and used the following routine:
> ...
>   private static void test2() {
> String driverName ="org.apache.derby.jdbc.EmbeddedDriver";
> String url = "jdbc:derby:";
> Properties p = System.getProperties();
> p.put("derby.system.home", "C:\\databases\\sample");
> p.put("derby.system.bootAll", "true");
> try {
>   Class.forName(driverName);
>   Driver driver = DriverManager.getDriver(url);
>   Properties info = new Properties();
>   DriverPropertyInfo[] attributes = driver.getPropertyInfo(url, info);
>   for (DriverPropertyInfo attribute : attributes) {
> System.out.print(attribute.name);
> System.out.print(" : ");
> if (attribute.choices != null) {
>   System.out.print(Arrays.toString(attribute.choices));
> }
> System.out.print(" : ");
> System.out.println(attribute.value);
>   }
> }
> catch(Exception exp) {
>   exp.printStackTrace();
> }
> try {
>   DriverManager.getConnection("jdbc:derby:;shutdown=true");
> }
> catch(Exception exp) {
> }
>   }
> When run the following exception occured:
> Exception in thread "main" java.lang.ExceptionInInitializerError
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Unknown Source)
> at Test.test2(Test.java:20)
> at Test.main(Test.java:8)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.bootProviderServic
> es(Unknown Source)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.bootPersistentServ
> ices(Unknown Source)
> at 
> org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unkno
> wn Source)
> at org.apache.derby.impl.services.monitor.FileMonitor.(Unknown 
> Sou
> rce)
> at 
> org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown S
> ource)
> at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
> at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
> at org.apache.derby.jdbc.EmbeddedDriver.(Unknown Source)
> ... 4 more
> If i comment out:
> // p.put("derby.system.bootAll", "true");
> The program runs, but no databases are listed.
> The output from java org.apache.derby.tools.sysinfo:
> -- Java Information --
> Java Version:1.5.0_05
> Java Vendor: Sun Microsystems Inc.
> Java home:   C:\Program Files\Java\jre1.5.0_05
> Java classpath:  
> C:\tools\derby\db-derby-10.1.2.1-bin\lib\derby.jar;C:\tools\der
> by\db-derby-10.1.2.1-bin\lib\derbytools.jar;;C:\tools\Java\jdk1.5.0_05\lib\tools
> .jar;C:\tools\log4j\logging-log4j-1.2.12\dist\lib\log4j-1.2.12.jar;C:\dev_deploy
> \plugins\com.x4m.util_1.0.0.jar;C:\dev_deploy\plugins\com.x4m.uomcrs_1.0.0.jar;C
> :\dev_deploy\plugins\com.x4m.database_1.0.0.jar;C:\dev_deploy\plugins\com.x4m.fe
> ature_1.0.0.jar;C:\dev_deploy\plugins\org.eclipse.core.runtime_3.1.0.jar;C:\dev_
> deploy\plugins\org.eclipse.osgi_3.1.0.jar;C:\dev_deploy\plugins\com.x4m.database
> _1.0.0.jar;C:\david\novice\syncservices\build\class
> OS name: Windows XP
> OS architecture: x86
> OS version:  5.1
> Java user name:  David
> Java user home:  C:\Documents and Settings\David
> Java user dir:   C:\david\novice\derby
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.5
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [C:\tools\derby\db-derby-10.1.2.1-bin\lib\derby.jar] 10.1.2.1 - (330608)
> [C:\tools\derby\db-derby-10.1.2.1-bin\lib\derbytools.jar] 10.1.2.1 - (330608)
> --
> - Locale Information -
> --
> I have read most of the documentation and can find no other way to get a list 
> of available catalogs - thus I do not know of a workaround for this problem.
> David Heath
> Transform Software and Services

-- 
This message is automatically generated by JIRA.
-
I

[jira] Closed: (DERBY-596) jdbcapi/resultsetStream.java fails in DerbyNetClient Framework

[Kristian Waagan (JIRA)]

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

Kristian Waagan closed DERBY-596.
-


Verified that the failure no longer occurs when running 
jdbcapi/resultsetStream.java under DerbyNetClient with Sun JDK 1.3, 1.4, 1.5 
and Mustang.

>  jdbcapi/resultsetStream.java fails in DerbyNetClient Framework
> ---
>
> Key: DERBY-596
> URL: http://issues.apache.org/jira/browse/DERBY-596
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client, Network Server, Test
>Affects Versions: 10.2.0.0
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.2.0.0
>
>
> Working in DERBY-525, I found that  jdbcapi/resultsetStream.java , which was 
> originally excluded from DerbyNetClient Framework, fails, if added to.
> Next is resultsetStream.diff :
> -- Java Information --
> Java Version:1.4.2_08
> Java Vendor: Sun Microsystems Inc.
> Java home:   /usr/local/j2sdk1.4.2_08/jre
> Java classpath:  /home/naka/ProgramDev/derby/trunk/jars/sane/derby.jar
> :/home/naka/ProgramDev/derby/trunk/jars/sane/derbyclient.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbytools.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbynet.jar:
> /usr/local/share/java/db2jcc/lib/db2jcc.jar:
> /usr/local/share/java/db2jcc/lib/db2jcc_license_c.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyTesting.jar:
> /home/naka/ProgramDev/derby/trunk/tools/java/jakarta-oro-2.0.8.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_de_DE.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_es.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_fr.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_it.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_ja_JP.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_ko_KR.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_pt_BR.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_zh_CN.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_zh_TW.jar
> OS name: Linux
> OS architecture: i386
> OS version:  2.4.27-2-386
> Java user name:  naka
> Java user home:  /home/naka
> Java user dir:   /home/naka/ProgramDev/testDerby/20051001
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.4
> - Derby Information 
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [/home/naka/ProgramDev/derby/trunk/jars/sane/derby.jar] 10.2.0.0 alpha - 
> (292740M)
> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbyclient.jar] 10.2.0.0 alpha 
> - (292740M)
> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbytools.jar] 10.2.0.0 alpha - 
> (292740M)
> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbynet.jar] 10.2.0.0 alpha - 
> (292740M)
> --
> - Locale Information -
> Current Locale :  [English/United States [en_US]]
> Found support for locale: [de_DE]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [es]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [fr]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [it]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [ja_JP]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [ko_KR]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [pt_BR]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [zh_CN]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [zh_TW]
>version: 10.2.0.0 alpha - (292740M)
> --
> Framework: DerbyNetClient
> *** Start: resultsetStream jdk1.4.2_08 DerbyNetClient 2005-10-02 13:56:27 ***
> 8a9
> > FAIL - stream was not closed after a get*() call. class 
> > java.io.ByteArrayInputStream
> 12 del
> < EXPECTED SQLSTATE(XSDA4): An unexpected exception was thrown
> 13 del
> < EXPECTED SQLSTATE(XJ001): Java exception: 'Input stream held less data than 
> requested length.: java.io.IOException'.
> 14 del
> < EXPECTED SQLSTATE(XSDA4): An unexpected exception was thrown
> 15 del
> < EXPECTED SQLSTATE(XJ001): Java exception: 'Input stream held less data than 
> requested length.: java.io.IOException'.
> 15a13,14
> > EXPECTED SQLSTATE(null): End of Stream prematurely reached while reading 
> > InputStream, parameter #2.  Remaining data has been padded with 0x0.
> > EXPECTED SQLSTATE(null): The specified size of the InputStream, parameter 
> > #2, is less than the actual InputStream length
> Test Failed.
> *** End:   resultsetStream jdk1.4.2_08 DerbyNetClient 2005-10-02 13:56:49 ***

-- 
This message is automatically generated by JIRA.
-
If you

[jira] Closed: (DERBY-609) Returning ByteArrayInputStream from ResultSet is not appropriate

[Kristian Waagan (JIRA)]

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

Kristian Waagan closed DERBY-609.
-

Fix Version/s: 10.2.0.0
   (was: 10.1.2.1)
   Resolution: Fixed

> Returning ByteArrayInputStream from ResultSet is not appropriate
> 
>
> Key: DERBY-609
> URL: http://issues.apache.org/jira/browse/DERBY-609
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.2.0.0
>
> Attachments: DERBY-609.patch
>
>
> Point where it is not appropriate :
> 1: Compatibility
> The InputStream returned from result set is closed when other get method 
> was called .
> http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html
> However closing ByteArrayInputStream have no effect at all .
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/ByteArrayInputStream.html#close()
> It seems intended that closable InputStream was returned from result set .
> If ByteArrayInputStream was returned from result set , the stream cannot be 
> closed, 
> and compatibility would be lost .
> 2: Performance of program 
> Information inputted from ByteArrayInputStream needs to be expanded to memory 
> as byte[] object .
> If large byte[] object was created for each ByteArrayInputStream object , 
> program will run in bad performance .
> // I think problem is when information typed as LOB was retrieved from 
> ResultSet .
> // Because such informations typed as LOB tend to be large amount .

-- 
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

[jira] Reopened: (DERBY-609) Returning ByteArrayInputStream from ResultSet is not appropriate

[Kristian Waagan (JIRA)]

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

Kristian Waagan reopened DERBY-609:
---

 
Reopened issue to correct fix version.

> Returning ByteArrayInputStream from ResultSet is not appropriate
> 
>
> Key: DERBY-609
> URL: http://issues.apache.org/jira/browse/DERBY-609
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.2.0.0
>
> Attachments: DERBY-609.patch
>
>
> Point where it is not appropriate :
> 1: Compatibility
> The InputStream returned from result set is closed when other get method 
> was called .
> http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html
> However closing ByteArrayInputStream have no effect at all .
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/ByteArrayInputStream.html#close()
> It seems intended that closable InputStream was returned from result set .
> If ByteArrayInputStream was returned from result set , the stream cannot be 
> closed, 
> and compatibility would be lost .
> 2: Performance of program 
> Information inputted from ByteArrayInputStream needs to be expanded to memory 
> as byte[] object .
> If large byte[] object was created for each ByteArrayInputStream object , 
> program will run in bad performance .
> // I think problem is when information typed as LOB was retrieved from 
> ResultSet .
> // Because such informations typed as LOB tend to be large amount .

-- 
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

[jira] Closed: (DERBY-609) Returning ByteArrayInputStream from ResultSet is not appropriate

[Kristian Waagan (JIRA)]

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

Kristian Waagan closed DERBY-609.
-

Fix Version/s: 10.1.2.1
   Resolution: Fixed

Closing this, seems completed. No activity since October 2005.

> Returning ByteArrayInputStream from ResultSet is not appropriate
> 
>
> Key: DERBY-609
> URL: http://issues.apache.org/jira/browse/DERBY-609
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.1.2.1
>
> Attachments: DERBY-609.patch
>
>
> Point where it is not appropriate :
> 1: Compatibility
> The InputStream returned from result set is closed when other get method 
> was called .
> http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html
> However closing ByteArrayInputStream have no effect at all .
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/ByteArrayInputStream.html#close()
> It seems intended that closable InputStream was returned from result set .
> If ByteArrayInputStream was returned from result set , the stream cannot be 
> closed, 
> and compatibility would be lost .
> 2: Performance of program 
> Information inputted from ByteArrayInputStream needs to be expanded to memory 
> as byte[] object .
> If large byte[] object was created for each ByteArrayInputStream object , 
> program will run in bad performance .
> // I think problem is when information typed as LOB was retrieved from 
> ResultSet .
> // Because such informations typed as LOB tend to be large amount .

-- 
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

[jira] Closed: (DERBY-1493) EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String)

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen closed DERBY-1493.
-

Fix Version/s: 10.2.0.0
   Resolution: Fixed

Thanks for fixing this issue, Narayanan! Committed revision 422689.

> EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String)
> -
>
> Key: DERBY-1493
> URL: http://issues.apache.org/jira/browse/DERBY-1493
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Knut Anders Hatlen
> Assigned To: V.Narayanan
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1493_v1.diff, DERBY-1493_v1.stat, 
> DERBY-1493_v2.diff, DERBY-1493_v2.stat
>
>
> The embedded driver throws Util.notImplemented() when 
> PreparedStatement.setNull(int, int, String) is called. The javadoc says that 
> "[if] the parameter does not have a user-defined or REF type, the given 
> typeName is ignored." The client driver correctly ignores typeName and 
> forwards the call to setNull(int, int). Embedded should be changed to match 
> the client.

-- 
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

[jira] Updated: (DERBY-244) with linux, depending on env setting $LANG and console encoding, some i18n tests fail

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-244:
-

Derby Info: [Patch Available]

> with linux, depending on env setting $LANG and console encoding, some i18n 
> tests fail
> -
>
> Key: DERBY-244
> URL: http://issues.apache.org/jira/browse/DERBY-244
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.1.1.0
> Environment: Linux, with console.encoding *not* UTF-8
>Reporter: Myrna van Lunteren
> Assigned To: Knut Anders Hatlen
>Priority: Minor
> Attachments: 244.diff, 244.stat
>
>
> The tests
>i18n/messageLocale.sql
>i18n/urlLocale.sql
>i18n/iepnegativetests_ES.sql
> will fail on Linux if $LANG and as a result, console.encoding is not set in 
> the same way as when the test master was created. The behavior is that some 
> characters are not seen as outside the ANSI range and are displayed as a ?.
> Result is as master when $LANG is en_US.UTF-8
> But then ieptest.sql will fail which will with ibm142 which pass if $LANG is 
> en_US.
> This needs some further analysis, so this description may need to be updated 
> later.
> Whatever the solution is, will need to work for all situations.

-- 
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

Regression Test Failure! - TinderBox_Derby 422635 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 422635/2006-07-17 08:32:24 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.5*
7679672 2   145.53% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-422635.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/422635.html
 

Changes in  
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/422635.txt
 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

Re: Problems in SQLBinary when passing in streams with unknown length (SQL, store)

[Kristian Waagan]

Daniel John Debrunner wrote:

Kristian Waagan wrote:

Hello,

I just discovered that we are having problems with the length less
overloads in the embedded driver. Before I add any Jiras, I would like
some feedback from the community. There are for sure problems in
SQLBinary.readFromStream(). I would also appreciate if someone with
knowledge of the storage layer can tell me if we are facing trouble
there as well.

SQL layer
=
SQLBinary.readFromStream()
  1) The method does not support streaming.
 It will either grow the buffer array to twice its size, or possibly
 more if the available() method of the input stream returns a
 non-zero value, until all data is read. This approach causes an
 OutOfMemoryError if the stream data cannot fit into memory.


I think this is because the maximum size for this data type is 255
bytes, so memory usage was not a concern.
SQLBinary corresponds to CHAR FOR BIT DATA, the sub-classes correspond
to the larger data types.

One question that has been nagging me is that the standard response to
why the existing JDBC methods had to declare the length was that the
length was required up-front by most (some?) database engines. Did this
requirement suddenly disappear? I assume it was discussed in the JDBC
4.0 expert group.

I haven't looked at your implementation for this, but the root cause may
be that derby does need to verify that the supplied value does not
exceed the declared length for the data type. Prior to any change for
lengthless overloads the incoming length was checked before the data was
inserted into the store. I wonder if with your change it is still
checking the length prior to storing it, but reading the entire value
into a byte array in order to determine its length.



Hi Dan,

That's true, and this is the approach I'm going for on the client until
we can do something better. On the embedded side, this approach is not
good enough.
I plan to handle the length check by wrapping the application stream in
a LimitReader, as is done for other streams. The length is also checked 
elsewhere when the data is inserted.





  2) Might enter endless loop.
 If the available() method of the input stream returns 0, and the
 data in the stream is larger than the initial buffer array, an
 endless loop will be entered. The problem is that the length
 argument of read(byte[],int,int) is set to 0. We don't read any
 more data and the stream is never exhausted.


That seems like a bug, available() is basically a useless method.


Added DERBY-1510 for this. The data going through here should be limited 
to 32700 bytes. Still need to avoid the possibility of a hang though, 
and I plan to remove the use of 'InputStream.available()'.





To me, relying on available() to determine if the stream is exhausted
seems wrong. Also, subclasses of InputStream will return 0 if they don't
override the method.
I wrote a simple workaround for 2), but then the OutOfMemoryError
comes into play for large data.


Store layer
===
I haven't had time to study the store layer, and know very little about
it. I hope somebody can give me some quick answers here.
  3) Is it possible to stream directly to the store layer if you don't
 know the length of the data?
 Can meta information (page headers, record headers etc.) be updated
 "as we go", or must the size be specified when the insert is
 started?


Yes the store can handle this.


Good to hear. I might play around a little with this. If people have
thoughts about how to solve this, or know of problems we will run into,
please share :)



BTW: I did a little hacking... By changing one int variable, I was able
to use the length less overloads (with Runtime.maxMemory = 63 MB, 
applied patch DERBY-1417). I was also able to

read back the Blobs and the contents were the same as I inserted.
Need to check this out some more, and figure out how to fit the change
into the API. Basically, a negative length argument is passed down to
the store layer, and the length check at the higher level is disabled.

When using an ineffective stream (generated 1 byte at a time, a 
looping-alphabet stream), I got these times (single run):


Size | Length specified | Length less |
 10M |   14,8 s |  14,0 s |
100M |   49,3 s |  49,2 s |
  2G |  874,1 s | 979,1 s |

The blobs were inserted, then read back and compared with a new instance 
of the stream used for the blob (ie for the 2G blob, a total of 6G was 
generated/read). The database directory clocked in at 4,2G (du -h)




--
Kristian



Dan.

[jira] Updated: (DERBY-244) with linux, depending on env setting $LANG and console encoding, some i18n tests fail

[Knut Anders Hatlen (JIRA)]

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

Knut Anders Hatlen updated DERBY-244:
-

Attachment: 244.diff
244.stat

Attaching a patch which makes
  - the i18n tests run with -Dfile.encoding=UTF-8
  - the streams in ProcessStreamResult use UTF-8 encoding for the i18n tests
  - Sed.java read result files from i18n tests using UTF-8 encoding

Derbyall runs cleanly with the patch (en_US locale). The i18nTest suite runs 
cleanly with non-UTF locales. The patch is ready for review. Thanks!

> with linux, depending on env setting $LANG and console encoding, some i18n 
> tests fail
> -
>
> Key: DERBY-244
> URL: http://issues.apache.org/jira/browse/DERBY-244
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.1.1.0
> Environment: Linux, with console.encoding *not* UTF-8
>Reporter: Myrna van Lunteren
> Assigned To: Knut Anders Hatlen
>Priority: Minor
> Attachments: 244.diff, 244.stat
>
>
> The tests
>i18n/messageLocale.sql
>i18n/urlLocale.sql
>i18n/iepnegativetests_ES.sql
> will fail on Linux if $LANG and as a result, console.encoding is not set in 
> the same way as when the test master was created. The behavior is that some 
> characters are not seen as outside the ANSI range and are displayed as a ?.
> Result is as master when $LANG is en_US.UTF-8
> But then ieptest.sql will fail which will with ibm142 which pass if $LANG is 
> en_US.
> This needs some further analysis, so this description may need to be updated 
> later.
> Whatever the solution is, will need to work for all situations.

-- 
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

[jira] Commented: (DERBY-982) sysinfo api does not provide genus name for client

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-982?page=comments#action_12421542 ] 

Kristian Waagan commented on DERBY-982:
---

Hi Andrew,

I reviewed the version 4 patch. Looks good to me, but I have one minor comment 
on the JUnit test.
Although not too important for this test, it would be nice to have the 
constructor that takes a String argument. This makes it possible to select/run 
specific test methods from the/a suite method.

Also, according to the JUnit documentation, the noarg constructor is there only 
to support serialization (which we don't require).


Thanks,

> sysinfo api does not provide genus name for client
> --
>
> Key: DERBY-982
> URL: http://issues.apache.org/jira/browse/DERBY-982
> Project: Derby
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 10.1.2.1
>Reporter: Kathey Marsden
> Assigned To: Andrew McIntyre
> Fix For: 10.2.0.0
>
> Attachments: derby-982-v4.diff, derby-982.diff, derby-982_v2.diff, 
> derby-982_v3.diff
>
>
> The sysinfo api does not provide access to the genus name for client to allow 
> applications to retrieve information from sysinfo about the client 
> information.
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/tools/sysinfo.html
> Note: Currently ProductGenusNames has a genus name for network server but 
> network server is closely tied to  the engine so should always have the same 
> version.

-- 
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

[jira] Updated: (DERBY-836) ResultSetMetaData.getColumnDisplaySize sometimes returns wrong values for DECIMAL columns

[Mayuresh Nirhali (JIRA)]

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

Mayuresh Nirhali updated DERBY-836:
---

Attachment: derby836-v7_2.diff

regenerated the patch as per andrew's comment.

> ResultSetMetaData.getColumnDisplaySize sometimes returns wrong values for 
> DECIMAL columns
> -
>
> Key: DERBY-836
> URL: http://issues.apache.org/jira/browse/DERBY-836
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Newcomer
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Mayuresh Nirhali
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby836-v2.diff, derby836-v3.diff, derby836-v4.diff, 
> derby836-v6.diff, derby836-v7.diff, derby836-v7_2.diff, derby836.diff, 
> derby836_v5.diff
>
>
> DECIMAL(10,0)
> max display width value:   -1234567890  length 11
> embedded : 11 correct
> client: 12 WRONG
> DECIMAL(10,10)
> max display width value:   -0.1234567890  length 13
> embedded : 13 correct
> client: 12 WRONG
> DECIMAL(10,2)
> max display width value:   -12345678.90  length 12
> embedded : 13 WRONG
> client: 12 correct
> I've added output early on in jdbcapi/metadata_test.java (and hence the tests 
> metadata.jar and odbc_metadata.java) to show this issue:
> E.g. for embedded
> DECIMAL(10,0) -- precision: 10 scale: 0 display size: 12 type name: DECIMAL
> DECIMAL(10,10) -- precision: 10 scale: 10 display size: 12 type name: DECIMAL
> DECIMAL(10,2) -- precision: 10 scale: 2 display size: 12 type name: DECIMAL
> I will add this test output once DERBY-829 is fixed so as not to cause 
> conflicts.

-- 
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