Re: full stack trace with TestConnectionMethods.java

[Narayanan]

Hi,

SUMMARY: UNABLE TO REPRODUCE PROBLEM :-(

DETAILS:

I applied patch for DERBY-1424 (i.e.) derby-1424-v1.diff.

svn status shows this

M  java/client/org/apache/derby/client/am/RowId.java
M  build.xml
?  tools/jar/dnc.properties
M  tools/jar/tools.properties
X  tools/testing/derby

I did a

ant clobber && ant all && ant buildjarsclean

and ran jdbc4/TestConnectionMethods.java using the following command

java -Dframework=DerbyNetClient 
org.apache.derbyTesting.functionTests.harness.RunTest 
jdbc4/TestConnectionMethods.java


and

java org.apache.derbyTesting.functionTests.harness.RunTest 
jdbc4/TestConnectionMethods.java


I also ran jdbc40 TestSuite in both the Embedded and the client 
frameworks. The test always seemed to pass. Seems like I am doing 
something wrong in my environment :-( .


Can you please tell me if I need do something more while building or 
running the tests?


I ran the tests in both solaris and linux platforms.

thanx
Narayanan



Andrew McIntyre wrote:

On 8/2/06, Narayanan <[EMAIL PROTECTED]> wrote:

Hi,
The subject of the email said JUnit. The TestConnectionMethods.java is
not a JUnit test.


My mistake, sorry. I incorrectly assumed that all of the jdbc4 tests
were junit tests. Anyway, I suppose I'll look at instrumenting this
test to return full stack traces. Any insight anyone can provide as to
why this would fail with the patch attached to DERBY-1424 that only
removes unnecessary classes from derbyclient.jar is still greatly
appreciated.

Thanks,
andrew

Regression Test Failure! - TinderBox_Derby 428252 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 428252/2006-08-03 08:02:53 CEST
*derbyall*

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

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

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

[jira] Updated: (DERBY-1614) Test harness overrides heap size settings when starting Network Server

[John H. Embretsen (JIRA)]

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

John H. Embretsen updated DERBY-1614:
-

Attachment: DERBY-1614_v2.diff

(NEED ADVICE ON HOW TO PROCEED WITH RELATED HARNESS "DEFECT", SEE BELOW)

Thanks for reviewing!

Attaching 'DERBY-1614_v2.diff', which replaces 'DERBY-1614_v1.diff'.

The only change from the previous patch is that the check for 
!jvmName.equals("jview") has been removed.

PLEASE NOTE: Harness decision about setting heap size flags should change even 
more, see below!

I found a number of other references to jview in the harness code, but I have 
not removed them (this is outside the scope of this Jira description):

./harness/RunList.java:726: else if (javaCmd.equals("jview"))
./harness/RunList.java:727: jvmName = "jview";
./harness/RunList.java:743: if ( (jvmName == null) || 
(jvmName.equals("jview")) )
./harness/RunTest.java:973: if ( (jvmName == null) || 
(jvmName.length()==0) || (jvmName.equals("jview")))
./harness/RunTest.java:995: if ( (jvmName == null) || 
(!jvmName.equals("jview")) )
./harness/NetServer.java:158:   if (jvmName.equals("jview"))
./harness/NetServer.java:159:   jvm.setJavaCmd("jview");
./harness/jvm.java:39:  that is the reference point for all others.  Note some 
VMs (like jview)


Anyway, I would actually like to change the jvmflags behavior a little more. 
The reason is that the test harness is (and always has been, I guess) setting 
heap size flags for the server JVM only if the jvmflags property is not null or 
the empty string:

boolean setJvmFlags = false;
if ( (jvmflags != null) && (jvmflags.length()>0) ) {
jvm.setFlags(jvmflags);
setJvmFlags = true;
}

This means that if some JVM option other than -ms, -Xms, -mx or -Xmx is 
specified with the jvmflags property, "harness-defaults" will be used for min 
(16 MB) and max size (32 MB).  If jvmflags is not used, or empty, the harness 
will not set any heap size values. I do not see the logic behind this, unless 
the jvmflags property is never used for any jvm flags other than the heap flags 
mentioned above.

This behavior makes it impossible to accurately compare two test runs (in 
DerbyNet or DerbyNetClient frameworks) with different jvm flags, as long as no 
heap size flags are set. Consider the following example:


The lang/forupdate.sql test is chosen because there are no jvmflags associated 
with it by default, and it can be run in embedded, DerbyNet and DerbyNetClient 
frameworks.

a) Default behavior:

Run the following command:

java -Dverbose=true -Dframework=DerbyNetClient 
org.apache.derbyTesting.functionTests.harness.RunTest lang/forupdate.sql

Let's say the default JVM for this machine is the Java HotSpot Client VM.
With the latest patch for this issue, the harness starts the network server by 
doing:

java -Duser.language=en -Duser.country=US 
-Dderby.system.home=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/test/forupdate/DerbyNetClient/forupdate
 -Djava.security.manager 
-Djava.security.policy=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/test/forupdate/derby_tests.policy
 
-DderbyTesting.codejar=file:/home/je159969/apache/Derby/sandBoxes/DERBY-1614/trunk/jars/sane/
 
-DderbyTesting.codedir=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/trunk/jars/sane
 -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost 
-DderbyTesting.codeclasses=file://unused/ 
org.apache.derby.drda.NetworkServerControl start


b) Run the test with some JVM option [1], for example -server (meaning: "Select 
the Java HotSpot Server VM"):

java -Djvmflags=-server -Dverbose=true -Dframework=DerbyNetClient 
org.apache.derbyTesting.functionTests.harness.RunTest lang/forupdate.sql

With the latest patch for this issue, the harness starts the network server by 
doing:

java -Duser.language=en -Duser.country=US -server -ms16777216 -mx33554432 
-Dderby.system.home=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/test/forupdate/DerbyNetClient/forupdate
 -Djava.security.manager 
-Djava.security.policy=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/test/forupdate/derby_tests.policy
 
-DderbyTesting.codejar=file:/home/je159969/apache/Derby/sandBoxes/DERBY-1614/trunk/jars/sane/
 
-DderbyTesting.codedir=/home/je159969/apache/Derby/sandBoxes/DERBY-1614/trunk/jars/sane
 -DderbyTesting.serverhost=localhost -DderbyTesting.clienthost=localhost 
-DderbyTesting.codeclasses=file://unused/ 
org.apache.derby.drda.NetworkServerControl start

The -server option is passed to the server JVM, but the harness also adds 
"-ms16777216 -mx33554432". This means that tests may fail in b) that did not 
fail in a), or vice versa, but not because of differences between the flags set 
in jvmflags, but because of the harness changing heap size settings 
automatically. Note that this has always been the behavior of the test harness; 
it is not caused by the above mentio

Re: Question around type in DRDA(Re: [jira] Commented: (DERBY-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network

[TomohitoNakayama]

Thanx.

I found it.

Best regards.

Dag H. Wanvik wrote:


Hi,

TomohitoNakayama <[EMAIL PROTECTED]> writes:

 


Concerning DERBY-1610, I'm surveying type definition part in current
DRDA relating code.

I found there exists two word "DRDA_TYPE" and "FDOCA_TYPE".
Former was found in org.apache.derby.iapi.reference.DRDAConstants and
latter was found in org.apache.derby.client.net.FdocaConstants.

The latter seems to be FTYPE defined in FD:OCA Specifications.
However I'm not sure what former is

Does any one know what is DRDA_TYPE is ?
   



The DRDA_TYPE values in DRDAConstants correspond to the meta data
reference values, cf. section 5.7 "FD:OCA Meta Data Summary", table
5-11 "MDD References Used in Early Environmental Descriptors" in
"DRDA, Version 3, Volume 1".

Dag


 



--
/*

   Tomohito Nakayama
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]

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

*/ 

[jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Rick Hillegas (JIRA)]

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

Rick Hillegas updated DERBY-700:


Fix Version/s: 10.3.0.0
   (was: 10.2.0.0)

It appears that fixing this bug will require us to agree on some mechanism for 
caching VM-global Derby state. This seems to be an architectural decision which 
requires careful thought and experiment. I think we should defer this to a 
future release. I am moving this to 10.3 because thatt's the next release 
available in the dropdown. I agree with Kathey that this is a good candidate 
for a bug fix release in the 10.2 lineage.

> Derby does not prevent dual boot of database from different classloaders on 
> Linux
> -
>
> Key: DERBY-700
> URL: http://issues.apache.org/jira/browse/DERBY-700
> Project: Derby
>  Issue Type: Bug
>  Components: Store
>Affects Versions: 10.1.2.1
> Environment: ava -version
> java version "1.4.2_08"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
>Reporter: Kathey Marsden
> Assigned To: V.Narayanan
>Priority: Critical
> Fix For: 10.3.0.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, 
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, 
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java, 
> DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2
>
>
> Derby does not prevent dual boot from two different classloaders on Linux.
> To reproduce run the  program DualBootRepro with no derby jars in your 
> classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can 
> change the location by changing the DERBY_LIB_DIR variable.
> On Linux the output is:
> $java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader [EMAIL PROTECTED]
> FAIL: Booted database in 2nd loader [EMAIL PROTECTED]
> On Windows I get the expected output.
> $ java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader [EMAIL PROTECTED]
> PASS: Expected exception for dualboot:Another instance of Derby may have 
> already booted the database D:\marsden\repro\dualboot\mydb.

-- 
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: Using StorageFactory to create temporary files

[Anurag shekhar]

Let me explain why I need a temporary file. I need a storage where 
blob/clob can be stored before writing into the table. As the size of 
lob can go upto 2gb its not possible to keep it in memory. I am using 
the temporary file to keep the byte/string in case the the size grows 
more than 4k.


So the temporary file will be created and accessed from the jdbc driver. 
I decided to use StorageFactory because it already have the nessasary 
permission for disk i/o. In case derby is running on a special storage, 
the StorageFactory will be aware of it and will be able to create 
temporary file for that device.

thanks
anurag
Mike Matrigali wrote:

This is an unexpected usage, this was never designed for that purpose.
It was originally designed as a module only to be used underneath the
store module.  The purpose was to allow alternate implementations of
the underlying filesystem.

I wonder why straight java i/o stream interfaces were not used?  Is
there anything being provided by the StorageFactory that a direct
use of java io does not easily provide?

I think it would be especially a bad idea to use the storage factory
on the client side of network server as it is going to draw in a lot
of other stuff not currently needed by the client jar.

Rick Hillegas wrote:
The patch attached to DERBY-1341 uses the StorageFactory to create a 
temporary file on behalf of the embedded JDBC layer. Is this usage 
OK? Does this violate some assumptions about what server layers are 
allowed to use the StorageFactory?


Would appreciate guidance here. I am out of my depth.

Thanks,
-Rick

Re: using Monitor.findService

[Anurag shekhar]

I thought of sending the mistake I was making so that it becomes part of 
archive and some one facing similar problem will able to find it in archive.


the correct way of obtaining the DataFactory is

Object o = Monitor.findService(Property.DATABASE_MODULE, dbName);
DataFactory df =  (DataFactory) Monitor.findServiceModule(o, 
DataFactory.MODULE);


anurag

Anurag shekhar wrote:

Hi
I am trying to locate DataFactory from the moniter when i call

Monitor.getMonitor().findService (DataFactory.MODULE, "databasename")

It returns me an instance of org.apache.derby.impl.db.BasicDatabase

Am I doing something wrong here ? Or its expected behavior ? In that 
case how to i get the reference of DataFactory from BasicDatabase ?


thanks
anurag

[jira] Assigned: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates

[James F. Adams (JIRA)]

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

James F. Adams reassigned DERBY-1292:
-

Assignee: James F. Adams

> ClassCastException in ClientDriver when using CLOB columns and batch updates
> 
>
> Key: DERBY-1292
> URL: http://issues.apache.org/jira/browse/DERBY-1292
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.1.2.1
>Reporter: Gerald Khin
> Assigned To: James F. Adams
>
> java.lang.ClassCastException: java.lang.String
>   at 
> org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown
>  Source)
>   at 
> org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown
>  Source)
>   at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown 
> Source)
>   at 
> org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source)
>   at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown 
> Source)
>   at 
> org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown 
> Source)
>   at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown 
> Source)
>   at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown 
> Source)
>   at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71)
>   at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27)

-- 
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-1610) Engine take it as type compatibility error to update column typed as CHAR to value passed via setBinaryStream(null), though Network Client and Network Server does not take

[Tomohito Nakayama (JIRA)]

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

Tomohito Nakayama updated DERBY-1610:
-

Attachment: DERBY-1610.diff
parameterMapping.diff

I tried to guess type of java.sql.Type when value was null ,
from drdaType as the patch.

As the result, the NetClientTest of  jdbcapi/parameterMapping.java was failed 
and got amount of difference.

I think this difference is too large to accept.
Originally, DERBY-1610 was issue around setBinaryStream(null).

Remembering the original problem, 
it was more problematic point of this issue that setBinaryStream(null) to 
character colum was failed though setBinaryStream(notNull) to character column 
was successed, than difference between Engine and NetworkServer/NetworkEngine.



> Engine take it as type compatibility error to update column typed as CHAR to 
> value passed via setBinaryStream(null), though Network Client and Network 
> Server does not take it as error.
> 
>
> Key: DERBY-1610
> URL: http://issues.apache.org/jira/browse/DERBY-1610
> Project: Derby
>  Issue Type: Bug
>  Components: Network Server, Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Attachments: DERBY-1610.diff, parameterMapping.diff, TestNullChar.java
>
>
> There exists difference between Engine and Network Client/Engine around type 
> compatibility judgement in character typed column when null value was passed 
> as InputStream.

-- 
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-353) It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user specified value or system generated value for BY DEFAULT identity columns.

[Kathey Marsden (JIRA)]

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

Kathey Marsden commented on DERBY-353:
--

I received a request from a user to  put this issue in 10.1.   I think though 
that this issue is an improvement and not a straight bug  fix so wanted to 
mention that in case anyone has concerns.  I   would like to do the following:

1)  Change this issue to improvement.
2) File a doc issue to change the IDENTIY_VAL_LOCAL  doc to reflect the change.
http://db.apache.org/derby/docs/10.1/ref/rrefidentityvallocal.html 
I think we just need to remove " The assigned value is an identity value 
generated by Derby. " since it now can be the value inserted by the user.
3) Wait until DERBY-1554 is fixed.
4) Port both DERBY-353 and DERBY-1554 to 10.1.

Please let me know if anyone has any concerns.
I tried and tried to think of a user scenario that might be reliant on the old 
behavior and couldn't come up with one.

Kathey


> It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user 
> specified value or system generated value for BY DEFAULT identity columns.
> 
>
> Key: DERBY-353
> URL: http://issues.apache.org/jira/browse/DERBY-353
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.1.0
> Environment: Generic
>Reporter: Satheesh Bandaram
> Assigned To: V.Narayanan
> Fix For: 10.2.0.0
>
> Attachments: patch353.diff
>
>
> Derby was recently enhanced to support BY DEFAULT identity column. While the 
> behavior of this feature is not documented yet, I think, it is desirable for 
> IDENTITY_VAL_LOCAL() function, that is used to retrieve last single statement 
> insert value for identity column, to return user specified value for the 
> default column.
> For GENERATED ALWAYS identity columns, this issue doesn't apply, since users 
> can't provide a value. But for GENERATED BY DEFAULT identity columns, users 
> can optionally specify a value. IDENTITY_VAL_LOCAL() function should return 
> this value. Derby currently doesn't support this behavior.
> ij> create table tauto ( i int generated by default as identity, j int, k 
> int);
> 0 rows inserted/updated/deleted
> ij> insert into tauto (j,k) values (1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 1
> 1 row selected
> ij> insert into tauto (j,k) values (1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 2
> 1 row selected
> ij> insert into tauto values (5,1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 2 
> <<= This needs be '5'
> 1 row selected
> ij> select * from tauto;
> I  |J  |K
> ---
> 1  |1  |1
> 2  |1  |1
> 5  |1  |1
> 3 rows selected

-- 
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-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinaryStre

[Tomohito Nakayama (JIRA)]

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

Tomohito Nakayama updated DERBY-1610:
-

Summary: Updating column typed as CHAR to value passed via 
setBinaryStream(notNull) is failed because of imcompatiblity of types though it 
was not taken as error when setBinaryStream(null)  (was: Engine take it as type 
compatibility error to update column typed as CHAR to value passed via 
setBinaryStream(null), though Network Client and Network Server does not take 
it as error.)
Description: There exists difference between updating character typed 
column to value passed via setBinaryStream(notNullValue) and updating the 
column to value passed via setBinaryStream(null).  (was: There exists 
difference between Engine and Network Client/Engine around type compatibility 
judgement in character typed column when null value was passed as InputStream.)

> Updating column typed as CHAR to value passed via setBinaryStream(notNull) is 
> failed because of imcompatiblity of types though it was not taken as error 
> when setBinaryStream(null)
> ---
>
> Key: DERBY-1610
> URL: http://issues.apache.org/jira/browse/DERBY-1610
> Project: Derby
>  Issue Type: Bug
>  Components: Network Server, Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Attachments: DERBY-1610.diff, parameterMapping.diff, TestNullChar.java
>
>
> There exists difference between updating character typed column to value 
> passed via setBinaryStream(notNullValue) and updating the column to value 
> passed via setBinaryStream(null).

-- 
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: Using StorageFactory to create temporary files

[Daniel John Debrunner]

Anurag shekhar wrote:
> Let me explain why I need a temporary file. I need a storage where
> blob/clob can be stored before writing into the table. As the size of
> lob can go upto 2gb its not possible to keep it in memory. I am using
> the temporary file to keep the byte/string in case the the size grows
> more than 4k.
> 
> So the temporary file will be created and accessed from the jdbc driver.
> I decided to use StorageFactory because it already have the nessasary
> permission for disk i/o. In case derby is running on a special storage,
> the StorageFactory will be aware of it and will be able to create
> temporary file for that device.

But there is no mechansim on the client to define one is running on "a
special storage", are you going to define one?

In this case it seems using the simple java.io.File.createTempFile()
will solve all of your issues. What benefit do you get from using
StorageFactory and its *current* set of implementations?

Dan.

[jira] Commented: (DERBY-1637) OutBufferedStream.java fails on ibm131/jdk131 jvms.

[Tomohito Nakayama (JIRA)]

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

Tomohito Nakayama commented on DERBY-1637:
--

Hello Sunitha.

This error seems to have something to do with my patch in DERBY-326...

I wanted to make this phenomena reappair in my develop environment.
However, I couldn't execute jdk131 at my linux environment ...

Can you upload stacktrace of Exception and so on ?

> OutBufferedStream.java fails on ibm131/jdk131 jvms.
> ---
>
> Key: DERBY-1637
> URL: http://issues.apache.org/jira/browse/DERBY-1637
> Project: Derby
>  Issue Type: Bug
>  Components: Regression Test Failure
>Affects Versions: 10.2.0.0
> Environment: ibm131, sun jdk131 ,windows. derby jars are 10.2.0.5 
> alpha - (426734)
>Reporter: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: outbuffstream_derbyall_report.txt
>
>
> OutBufferedStream test fails with ibm131 and jdk131. I'll attach the report 
> file 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-790) SQLException used by the networked interface to Derby is not serializable

[Kathey Marsden (JIRA)]

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

Kathey Marsden commented on DERBY-790:
--

I think this would be a good 10.2 fix candidate but did not change it to 10.2 
because it is already assigned.  Francois,  I was wondering if you were 
actively working on this issue? If not it might be good to unassign yourself so 
that someone else can pick it up.

I think it is a JDBC compliance issue  and while it does have only one vote, we 
have had users asking about it on the list.
 

> SQLException used by the networked interface to Derby is not serializable
> -
>
> Key: DERBY-790
> URL: http://issues.apache.org/jira/browse/DERBY-790
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Server, Network Client
> Environment: Windows XP; WebLogic Server 9.0
>Reporter: David Cabelus
> Assigned To: Francois Orsini
>
> When running RMI client tests with Derby,  many tests failed with the 
> following message:
> Caused by: java.rmi.UnmarshalException: Failed to marshal error response: 
> 'org.apache.derby.client.am.SqlException: 'DROP TABLE' cannot be performed on 
> 'SDF014B7' because it does not exist.' because exception ; nested exception 
> is:
> java.io.NotSerializableException: 
> org.apache.derby.client.net.NetSqlca
> at weblogic.rjvm.ResponseImpl.unmarshalReturn(ResponseImpl.java:191)
> at 
> weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:176)
> This issue is a blocking issue for us.

-- 
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: Using StorageFactory to create temporary files

[Daniel John Debrunner]

Daniel John Debrunner wrote:

> Anurag shekhar wrote:
> 
>>Let me explain why I need a temporary file. I need a storage where
>>blob/clob can be stored before writing into the table. As the size of
>>lob can go upto 2gb its not possible to keep it in memory. I am using
>>the temporary file to keep the byte/string in case the the size grows
>>more than 4k.
>>
>>So the temporary file will be created and accessed from the jdbc driver.
>>I decided to use StorageFactory because it already have the nessasary
>>permission for disk i/o. In case derby is running on a special storage,
>>the StorageFactory will be aware of it and will be able to create
>>temporary file for that device.
> 
> 
> But there is no mechansim on the client to define one is running on "a
> special storage", are you going to define one?
> 
> In this case it seems using the simple java.io.File.createTempFile()
> will solve all of your issues. What benefit do you get from using
> StorageFactory and its *current* set of implementations?

I think this is also true for embedded, using the
java.io.File.createTempFile() is the cleanest solution.

The StorageFactory is there to allow the database store to handle
different file types (jar, classpath, java i/o) and there is a
demonstrated need for this. Thus the database store consistently uses
the StorageFactory interfaces to access files and directories.  The
database store also needs temporary files and it needs them to be
handled using the same api's as the perisisent files. Thus
StorageFactory has a getTempDir() method, it's purpose in life is to
bring temp files into the world of the database store, not a general
purpose mechanism.

Dan.

(10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Kathey Marsden]

Rick Hillegas (JIRA) wrote:


It appears that fixing this bug will require us to agree on some mechanism for 
caching VM-global Derby state. This seems to be an architectural decision which 
requires careful thought and experiment. I think we should defer this to a 
future release. I am moving this to 10.3 because thatt's the next release 
available in the dropdown. I agree with Kathey that this is a good candidate 
for a bug fix release in the 10.2 lineage.

 

Sounds like a reasonable move since there is no immediate solution 
apparent.  I was wondering though, could  we could add a  new version 
that we can use as some of the 10.2 candidates start getting moved out?  
I want to say 10.2.2.0 but am not sure that is right.


Kathey

[jira] Commented: (DERBY-1579) Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality

[Rick Hillegas (JIRA)]

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

Rick Hillegas commented on DERBY-1579:
--

I'm having difficulty applying this patch (dery1579trunkdiff02.txt). Are there 
special instructions for applying this patch? I'm stumbing early on:

rick_sun mainline (1.4) > svn_patch ~/junk/derby1579trunkdiff02.txt
(Stripping trailing CRs from patch.)
patching file 
java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java
Reversed (or previously applied) patch detected!  Assume -R? [n]

> Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke 
> functionality
> -
>
> Key: DERBY-1579
> URL: http://issues.apache.org/jira/browse/DERBY-1579
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Yip Ng
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1579trunkdiff01.txt, derby1579trunkdiff02.txt, 
> derby1579trunkstat01.txt, derby1579trunkstat02.txt
>
>
> With the Grant Revoke functionality. Derby engine needs to keep track of 
> view/constraint/trigger's dependencies on various privileges. 
> SYS.SYSREQUIREDPERM table was added for this purpose. But these depdencies 
> can be mantained using the existing Dependency Manager. I have done quite a 
> bit of work using Dependency Manager for Grant Revoke and do not see a need 
> for SYS.SYSREQUIREDPERM. Before 10.2 release, we should drop 
> SYS.SYSREQUIREDPERM from the Derby code and update the Grant/Revoke 
> functional spec accordingly.

-- 
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-1579) Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality

[Daniel John Debrunner (JIRA)]

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

Daniel John Debrunner updated DERBY-1579:
-

Derby Info:   (was: [Patch Available])

Patch committed #428115 - Thanks Yip
(sorry Rick, I forgot to add this comment, one can always check the Subversion 
Commits tab to see if there has been any activity on the issue)

> Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke 
> functionality
> -
>
> Key: DERBY-1579
> URL: http://issues.apache.org/jira/browse/DERBY-1579
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Yip Ng
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1579trunkdiff01.txt, derby1579trunkdiff02.txt, 
> derby1579trunkstat01.txt, derby1579trunkstat02.txt
>
>
> With the Grant Revoke functionality. Derby engine needs to keep track of 
> view/constraint/trigger's dependencies on various privileges. 
> SYS.SYSREQUIREDPERM table was added for this purpose. But these depdencies 
> can be mantained using the existing Dependency Manager. I have done quite a 
> bit of work using Dependency Manager for Grant Revoke and do not see a need 
> for SYS.SYSREQUIREDPERM. Before 10.2 release, we should drop 
> SYS.SYSREQUIREDPERM from the Derby code and update the Grant/Revoke 
> functional spec accordingly.

-- 
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: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Rick Hillegas]

Yes, please! If I knew the JIRA magic to do this, I would mumble it. 
Could someone teach me the magic, and if necessary, give me karma to mumble?


Thanks,
-Rick

Kathey Marsden wrote:


Rick Hillegas (JIRA) wrote:

It appears that fixing this bug will require us to agree on some 
mechanism for caching VM-global Derby state. This seems to be an 
architectural decision which requires careful thought and experiment. 
I think we should defer this to a future release. I am moving this to 
10.3 because thatt's the next release available in the dropdown. I 
agree with Kathey that this is a good candidate for a bug fix release 
in the 10.2 lineage.


 

Sounds like a reasonable move since there is no immediate solution 
apparent.  I was wondering though, could  we could add a  new version 
that we can use as some of the 10.2 candidates start getting moved 
out?  I want to say 10.2.2.0 but am not sure that is right.


Kathey

Re: Using StorageFactory to create temporary files

[Mike Matrigali]

Anurag shekhar wrote:
Let me explain why I need a temporary file. I need a storage where 
blob/clob can be stored before writing into the table. As the size of 
lob can go upto 2gb its not possible to keep it in memory. I am using 
the temporary file to keep the byte/string in case the the size grows 
more than 4k.
will this code ever be used on the client side of a network 
client/server configuration?

Re: Using StorageFactory to create temporary files

[Anurag Shekhar]

Daniel John Debrunner wrote:

Anurag shekhar wrote:
  

Let me explain why I need a temporary file. I need a storage where
blob/clob can be stored before writing into the table. As the size of
lob can go upto 2gb its not possible to keep it in memory. I am using
the temporary file to keep the byte/string in case the the size grows
more than 4k.

So the temporary file will be created and accessed from the jdbc driver.
I decided to use StorageFactory because it already have the nessasary
permission for disk i/o. In case derby is running on a special storage,
the StorageFactory will be aware of it and will be able to create
temporary file for that device.



But there is no mechansim on the client to define one is running on "a
special storage", are you going to define one?
  
I am not using storage factory in client driver. I am using it in set 
methods of lob classes in EmbeddedDriver's Blob/Clob classes.

In this case it seems using the simple java.io.File.createTempFile()
will solve all of your issues. What benefit do you get from using
StorageFactory and its *current* set of implementations?

  
Yes java.io.File.createTempFile() will work. But is it ok to grant file 
i/o access to a jdbc driver class ?



thanks
anurag

Re: Using StorageFactory to create temporary files

[Anurag Shekhar]

Mike Matrigali wrote:



Anurag shekhar wrote:
Let me explain why I need a temporary file. I need a storage where 
blob/clob can be stored before writing into the table. As the size of 
lob can go upto 2gb its not possible to keep it in memory. I am using 
the temporary file to keep the byte/string in case the the size grows 
more than 4k.
will this code ever be used on the client side of a network 
client/server configuration?



No its part Blob/Clob classes on EmbeddedDriver.
anurag

Re: Using StorageFactory to create temporary files

[Daniel John Debrunner]

Anurag Shekhar wrote:


> Yes java.io.File.createTempFile() will work. But is it ok to grant file
> i/o access to a jdbc driver class ?

Permissions afre granted to derby.jar, not individual classes.

Dan.

JUnit unit tests - parallel test three?

[Kristian Waagan]

Hello,

I want to write a unit test for 
'services/io/RawToBinaryFormatStream.java", using JUnit.

I know how to write the test itself, but where should I put it?
The directories/categories under functionTests do not seem quite right 
to me. My first thought was to put the test under unitTests instead, but 
that seems to contain files for the special unit test harness that we have.


Also, say this class is made package private. Testing it indirectly 
through other public classes/methods might be a big hassle.
Should we consider adding a parallel source three to be used for unit 
tests written in JUnit?


For now I will just write my RawToBinaryFormatStream-tests as part of a 
functional test for LOBs. In my opinion, this is not the best solution, 
and I would like to hear what the community thinks about these issues.

Have I overlooked better, existing ways to do this?



Thanks,
--
Kristian

[jira] Updated: (DERBY-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.

[V.Narayanan (JIRA)]

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

V.Narayanan updated DERBY-1554:
---

Attachment: DERBY-1554.diff
DERBY-1554.stat

Hi,

If we could avoid calling the setIdentity() function in the 
GenericLanguageContext class when we have an multi-row insert the above bug 
would be fixed. I tried the same in the above patch with a single line fix and 
it seemed to work. 

I was going throught the earlier patch I submitted for 353 when I thought this 
small fix might resolve this issue. Pls do tell me if you see any problems with 
the above fix or if u see any case I might have missed.

Attaching relevant diff and stat files. I tested this patch only using the test 
case with this issue. I also tested test cases for 353 and 439. 

PLEASE NOTE THAT I HAVE NOT RUN DERBYALL on this patch.

thanx
Narayanan

> IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row 
> INSERT statement.
> 
>
> Key: DERBY-1554
> URL: http://issues.apache.org/jira/browse/DERBY-1554
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Yip Ng
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1554.diff, DERBY-1554.stat
>
>
> Changes made in DERBY-353 break the documented behaviour of 
> IDENTITY_VAL_LOCAL(). Now the returned value is modified when a multi-row 
> insert is performed.
> IDENTITY_VAL_LOCAL() should not be updated when this occurs.
> For this script the last value returned should be 2 (as in 10.1) but in 10.2 
> is 4
> create table ta (a int, b int generated always as identity);
> insert into ta(a) values 100;
> values IDENTITY_VAL_LOCAL();
> insert into ta(a) values 200;
> values IDENTITY_VAL_LOCAL();
> insert into ta(a) values 300,400;
> values IDENTITY_VAL_LOCAL();

-- 
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-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Mike Matrigali]

Rick Hillegas (JIRA) wrote:

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

Rick Hillegas updated DERBY-700:


Fix Version/s: 10.3.0.0
   (was: 10.2.0.0)

It appears that fixing this bug will require us to agree on some mechanism for 
caching VM-global Derby state. This seems to be an architectural decision which 
requires careful thought and experiment. I think we should defer this to a 
future release. I am moving this to 10.3 because thatt's the next release 
available in the dropdown. I agree with Kathey that this is a good candidate 
for a bug fix release in the 10.2 lineage.

If anyone has ideas on this one, please post them.  I have been stumped 
by this one so far.  As I posted earlier I think one approach simply

needs a way to uniquely identify the current JVM, and also some way
to coordinate a sync block across 2 class loaders.  So far I have
been convinced by dan and david that using System properties is the
wrong approach.

As kathy has said the consequences of this is that
user may corrupt the db so it is bad.  We should document either in
release notes or the main documentation that Derby does not currently
support accessing the same db, in the same JVM, from 2 separate class 
loaders.  System properties in general are a problems for this 
configuration, and I believe we do no testing of the configuration

either.  Any opinions on where this info should show up.

As this is an unsupported configuration, I believe that it should not
hold up the 10.2 release, but  I also agree that whenever we get an 
agreed upon fix it should go into the next release of all current

releases.

Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Daniel John Debrunner]

Mike Matrigali wrote:


> If anyone has ideas on this one, please post them.  I have been stumped
> by this one so far.  As I posted earlier I think one approach simply
> needs a way to uniquely identify the current JVM, and also some way
> to coordinate a sync block across 2 class loaders. 

A Java synchronized block across class loaders is easy, either
of these will work. But I'm not sure if that's what you really meant,
but I'd thought I'd throw it out there.

synchronized ("derby")
{
}

synchronized ("")
{
}

Dan.

Copyrights

[Rick Hillegas]

I hope that David can commit the work for DERBY-1377 before we cut the 
10.2 branch next week. Unfortunately, I think David is stuck because 
it's unclear what's required. Here's where I think this issue stands:


UNRESOLVED ISSUES:

1) Do we need to add license headers to our build scripts, property 
files, README files, and other human-readable files which currently 
don't have copyright notices? Or are these files excluded under the 
rubric of "file without any degree of creativity"? Does some other 
escape-clause exlude these files?


2) Should the IBM copyrights migrate from the COPYRIGHT to the NOTICE 
file? If so, who is authorized to move these copyrights?


3) Are there other unclear issues?

I would like the community's guidance soon.

Thanks,
-Rick

Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Mike Matrigali]

great, sounds like the sync part is a non-issue.  I was stuck trying
to come up with something specific to the db shared across both 
classloaders that we could sync on.  Using this will single thread

opens of different dbs, but I think that is ok.

Daniel John Debrunner wrote:

Mike Matrigali wrote:




If anyone has ideas on this one, please post them.  I have been stumped
by this one so far.  As I posted earlier I think one approach simply
needs a way to uniquely identify the current JVM, and also some way
to coordinate a sync block across 2 class loaders. 



A Java synchronized block across class loaders is easy, either
of these will work. But I'm not sure if that's what you really meant,
but I'd thought I'd throw it out there.

synchronized ("derby")
{
}

synchronized ("")
{
}

Dan.

Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Daniel John Debrunner]

Mike Matrigali wrote:

> great, sounds like the sync part is a non-issue.  I was stuck trying
> to come up with something specific to the db shared across both
> classloaders that we could sync on.  Using this will single thread
> opens of different dbs, but I think that is ok.

Then I think you would want something like:

String syncDB = file.getCanonicalPath().intern();

synchronized (syncDB)
{
}

Dan.

DOCS - Alpha version (PDF) of Admin Guide does not appear on Apache Derby page

[Laura Stewart]

On the Derby Manuals page
(http://db.apache.org/derby/manuals/index.html)

when I click on the link for the Alpha PDF version of the Derby Server
and Administration Guide
(http://db.apache.org/derby/docs/dev/adminguide/derbyadmin.pdf)

nothing appears.  When I try the same for the Reference Manual, the
PDF version of the doc appears.

--
Laura Stewart

Re: Startup time for Derby

[David Van Couvering]

Oooh, I like this idea.  It would also be good to show people how to set 
up their own "model" databases with the tables they want, so they don't 
have to re-create all their own tables for each individual test.


The other people want for unit testing, of course, is a database that 
runs solely in memory.  It's a reason so many people love testing with HSQL.


David

Andrew McIntyre wrote:

On 7/27/06, David Van Couvering <[EMAIL PROTECTED]> wrote:

I am here at OSCON and a user of Derby was complaining rather
energetically to me at the cost of startup time for Derby.  He said this
is a real problem for running unit tests, as this is compounded by
running multiple tests, each one starting up a new database.


This is something that has come up in the past and I just had a random
thought regarding this.

The structure of a new, properly shutdown database has to be static
for a specific version of Derby, right? (ok, almost, see locale note
below)  So, what if we packaged a new database in a jar file,
derbynewdb.jar, along with its exact version info, and when a
connection URL with the create attribute is passed, the engine checks
that newdb.jar is available and that the version of the newdb jar file
in the classpath is identical. If so, the engine expands the new,
empty database from the jar into the local filesystem instead of
creating all of the system tables from scratch. If the version
mismatches or the newdb.jar isn't there (or is incomplete?), we create
a new db from scratch the regular way. A new db compressed into a jar
file is only 54K for 10.2, not so bad for (re)deployment.

Someone has to have thought of this before, so I'm wondering what the
issues are here. One problem that I can think of off-hand would be
that a database is created with the JVM's current locale as the
database locale. So it would be necessary to have a way to update the
database locale after the expansion of the new db from the jar file,
maybe a system procedure that needs to be called after the expansion
of the new database from the jar. Another is what if there is a
failure while uncompressing the db, what do you do on an attempt to
reconnect? There would need to be a way to verify that you're working
with a full deck of cards, as it were, but such a verification still
seems like it would be less heavy-weight than creating a new db from
scratch.

Anyway, the idea passed through my head, so I thought I'd throw it out 
there...


andrew

Re: Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Andrew McIntyre]

On 8/3/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:

Yes, please! If I knew the JIRA magic to do this, I would mumble it.
Could someone teach me the magic, and if necessary, give me karma to mumble?


granted. the admin pages are your friends.


Kathey Marsden wrote:

> Sounds like a reasonable move since there is no immediate solution
> apparent.  I was wondering though, could  we could add a  new version
> that we can use as some of the 10.2 candidates start getting moved
> out?  I want to say 10.2.2.0 but am not sure that is right.


Yep, that's right. I've added this version to JIRA. We need this also
to track the inevitable removal of our "early-access" language around
the JDBC 4 bits. Which reminds me...

Re: unused / unnecessary files in derbyclient.jar (DERBY-1424)

[David Van Couvering]

+1 to the classes that shouldn't be in there.  We don't currently use 
the classlister utility to determine what classes to include in 
derbyclient.jar.  Maybe we should?


David

Andrew McIntyre wrote:

While working on DERBY-1424, building derbyclient.jar with
classlister, I noticed the following classes which are either unused
or shouldn't be included in derbyclient.jar. The ones which are unused
appear to be have been used in the past, but are not used now, and
should probably be removed completely. The other set, the ones that
shouldn't be included in derbyclient.jar are either reference classes
(interfaces containing only Strings) or sanity manager classes.

The unused classes:
42d41
< org/apache/derby/client/am/ErrorKey.class
46,49d44
< org/apache/derby/client/am/GetFileInputStreamAction.class
< org/apache/derby/client/am/GetResourceBundleAction.class
< org/apache/derby/client/am/GetResourceInputStreamAction.class
< org/apache/derby/client/am/GetSystemPropertiesAction.class
65d59
< org/apache/derby/client/am/RowId.class
71d64
< org/apache/derby/client/am/SetAccessibleAction.class

Classes which shouldn't be in derbyclient.jar:
75d67
< org/apache/derby/client/am/SqlState.class
94d85
< org/apache/derby/client/net/DssConstants.class
140d130
< org/apache/derby/iapi/services/info/ProductGenusNames.class
142,143d131
< org/apache/derby/iapi/services/info/PropertyNames.class
< org/apache/derby/iapi/services/sanity/SanityManager.class
162d149
< org/apache/derby/loc/clientmessages_qq_PP_testOnly.properties
165d151
< org/apache/derby/shared/common/error/ExceptionSeverity.class
168,170d153
< org/apache/derby/shared/common/sanity/AssertFailure.class
< org/apache/derby/shared/common/sanity/SanityManager.class
< org/apache/derby/shared/common/sanity/SanityState.class

I'd like to get these unused classes cleaned up (hopefully, removed)
from the client source. I'm guessing one of the unnecessary classes in
the second list is causing my problem with
jdbc4/TestConnectionMethods.java.

So, if anyone has any comments regarding the use of the classes
mentioned above, please let me know. The above diff was taken from the
class list of a current derbyclient.jar versus a derbyclient.jar built
with the derby-1424-v1.diff patch currently attached to DERBY-1424.

andrew

Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Satheesh Bandaram]

Hi Rick,

Currently both Andrew and myself have JIRA-admin access, though Andrew
has been doing all the work lately.

I have been thinking of giving up my JIRA-admin access... May be the
right time now to switch it over to you, since you are the release
manager for 10.2.

Satheesh

Rick Hillegas wrote:

> Yes, please! If I knew the JIRA magic to do this, I would mumble it.
> Could someone teach me the magic, and if necessary, give me karma to
> mumble?
>
> Thanks,
> -Rick
>
> Kathey Marsden wrote:
>
>> Rick Hillegas (JIRA) wrote:
>>
>>> It appears that fixing this bug will require us to agree on some
>>> mechanism for caching VM-global Derby state. This seems to be an
>>> architectural decision which requires careful thought and
>>> experiment. I think we should defer this to a future release. I am
>>> moving this to 10.3 because thatt's the next release available in
>>> the dropdown. I agree with Kathey that this is a good candidate for
>>> a bug fix release in the 10.2 lineage.
>>>
>>>  
>>>
>> Sounds like a reasonable move since there is no immediate solution
>> apparent.  I was wondering though, could  we could add a  new version
>> that we can use as some of the 10.2 candidates start getting moved
>> out?  I want to say 10.2.2.0 but am not sure that is right.
>>
>> Kathey
>>
>>
>>
>
>

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

[Dag H. Wanvik (JIRA)]

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

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

If you are modelling this on the java.lang.String modulo indexing, it
seems to me that this is slightly wrong:

"The position must be between 1 and the last position of the Lob".

I think it should be 

"The position must be between 1 and the last position + 1 of the Lob",
cf. this example which does not throw exceptions. In the substring of
t2, the position is *one past* the final position of the string, final
position being 0.

String t1 = "";
String t2 = "a";

String t3;

try {
System.out.println("t1.substring(0,0) = '" +
   t1.substring(0,0) +  
"'");
} catch (IndexOutOfBoundsException e) {
System.out.println("t1.substring(0,0) throws");
}

try {
System.out.println("t2.substring(1,1) = '" +
   t2.substring(1,1) +  
"'");
} catch (IndexOutOfBoundsException e) {
System.out.println("t2.substring(1,1) throws");
}
}

that is, you can always request an empty string from the position
*immediately after* the last byte, but not further out. This would
remove the asymmetry you have in the code, too:

if (this.length() == 0) {
if (pos > 1) {
throw new SqlException(agent_.logWriter_, 
new ClientMessageId(SQLState.BLOB_POSITION_TOO_LARGE), 
new Long(pos));
}
} else { // this.length() > 0
if (pos > this.length()) {
throw new SqlException(agent_.logWriter_, 
new ClientMessageId(SQLState.BLOB_POSITION_TOO_LARGE), 
new Long(pos));
}
}
would reduce to:

if (pos > this.length() + 1) {
throw new SqlException(agent_.logWriter_, 
new ClientMessageId(SQLState.BLOB_POSITION_TOO_LARGE), 
new Long(pos));
}

I also think this is the symmetry one would want for programming
convenience, like you have mentioned. 


> 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
> Assigned To: Craig Russell
>Priority: Minor
> Attachments: DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch, 
> 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] Created: (DERBY-1639) Include early-draft notice required by JDBC 4 spec license in NOTICES, release notes and documentation

[Andrew McIntyre (JIRA)]

Include early-draft notice required by JDBC 4 spec license in NOTICES, release 
notes and documentation
--

 Key: DERBY-1639
 URL: http://issues.apache.org/jira/browse/DERBY-1639
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.0.0
Reporter: Andrew McIntyre
 Fix For: 10.2.0.0


from the license:

3. Distribute applications written to the 
Specification to third parties for their testing and 
evaluation use, provided that any such application 
includes the following notice:

  "This is an application written to interoperate 
with an early-draft specification developed under the 
Java Community Process (JCP) and is made available for 
testing and evaluation purposes only. The code is not 
compatible with any specification of the JCP."

This notice needs to be included in the NOTICES file, and should also be used 
to frame discussion of JDBC 4.0 features in the release notes and documentation.


-- 
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-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.

[Yip Ng]

Thanks.  I have a similar patch and I ran derbyall last night but this morning when I check the result, the OS crashed.  So I'll have to run it again...On 8/3/06, 
V.Narayanan (JIRA)  wrote:
 [ http://issues.apache.org/jira/browse/DERBY-1554?page=all ]V.Narayanan updated DERBY-1554:---Attachment: 
DERBY-1554.diffDERBY-1554.statHi,If we could avoid calling the setIdentity() function in the GenericLanguageContext class when we have an multi-row insert the above bug would be fixed. I tried the same in the above patch with a single line fix and it seemed to work.
I was going throught the earlier patch I submitted for 353 when I thought this small fix might resolve this issue. Pls do tell me if you see any problems with the above fix or if u see any case I might have missed.
Attaching relevant diff and stat files. I tested this patch only using the test case with this issue. I also tested test cases for 353 and 439.PLEASE NOTE THAT I HAVE NOT RUN DERBYALL on this patch.
thanxNarayanan> IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.> 
>> Key: DERBY-1554> URL: http://issues.apache.org/jira/browse/DERBY-1554> Project: Derby
>  Issue Type: Bug>  Components: SQL>Affects Versions: 10.2.0.0>Reporter: Daniel John Debrunner> Assigned To: Yip Ng
> Fix For: 10.2.0.0>> Attachments: DERBY-1554.diff, DERBY-1554.stat>>> Changes made in DERBY-353 break the documented behaviour of IDENTITY_VAL_LOCAL(). Now the returned value is modified when a multi-row insert is performed.
> IDENTITY_VAL_LOCAL() should not be updated when this occurs.> For this script the last value returned should be 2 (as in 10.1) but in 10.2 is 4> create table ta (a int, b int generated always as identity);
> insert into ta(a) values 100;> values IDENTITY_VAL_LOCAL();> insert into ta(a) values 200;> values IDENTITY_VAL_LOCAL();> insert into ta(a) values 300,400;> values IDENTITY_VAL_LOCAL();
--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: Re: unused / unnecessary files in derbyclient.jar (DERBY-1424)

[Andrew McIntyre]

On 8/3/06, David Van Couvering <[EMAIL PROTECTED]> wrote:

+1 to the classes that shouldn't be in there.


s/to the/to removing the/ ?


We don't currently use
the classlister utility to determine what classes to include in
derbyclient.jar.  Maybe we should?


I'll take that as a +0.9 for DERBY-1424. :-)

andrew

Re: Startup time for Derby

[Daniel John Debrunner]

Andrew McIntyre wrote:

> On 7/27/06, David Van Couvering <[EMAIL PROTECTED]> wrote:
> 
>> I am here at OSCON and a user of Derby was complaining rather
>> energetically to me at the cost of startup time for Derby.  He said this
>> is a real problem for running unit tests, as this is compounded by
>> running multiple tests, each one starting up a new database.
> 
> 
> This is something that has come up in the past and I just had a random
> thought regarding this.
> 
> The structure of a new, properly shutdown database has to be static
> for a specific version of Derby, right? (ok, almost, see locale note
> below)  So, what if we packaged a new database in a jar file,
> derbynewdb.jar, along with its exact version info, and when a
> connection URL with the create attribute is passed, the engine checks
> that newdb.jar is available and that the version of the newdb jar file
> in the classpath is identical. If so, the engine expands the new,
> empty database from the jar into the local filesystem instead of
> creating all of the system tables from scratch. If the version
> mismatches or the newdb.jar isn't there (or is incomplete?), we create
> a new db from scratch the regular way. A new db compressed into a jar
> file is only 54K for 10.2, not so bad for (re)deployment.
> 
> Someone has to have thought of this before, so I'm wondering what the
> issues are here. One problem that I can think of off-hand would be
> that a database is created with the JVM's current locale as the
> database locale. So it would be necessary to have a way to update the
> database locale after the expansion of the new db from the jar file,
> maybe a system procedure that needs to be called after the expansion
> of the new database from the jar. Another is what if there is a
> failure while uncompressing the db, what do you do on an attempt to
> reconnect? There would need to be a way to verify that you're working
> with a full deck of cards, as it were, but such a verification still
> seems like it would be less heavy-weight than creating a new db from
> scratch.
> 
> Anyway, the idea passed through my head, so I thought I'd throw it out
> there...

I think a useful first step is the ability to create a database from
another database, regardless of its stored form. Restore does this
today, but is limited to reading files. If that was expanded to handle
other stored forms (through the StorageFactory) then the base underlying
technology would exist for what you want, and is more generalized to
allow applications to copy pre-populated (schema and data) databases.

However, to have a existing empty template database that works in all
situations may be more effort than it worth. Apart from the locale
issue, the owner of database objects becomes important with SQL
authorization which will become the default at some point in the future.
I'm concerned that more and more code will have to exist to patch up
this template database. The current Derby scheme of easy to create new
database was in part reaction to my experience with another database
system which used the template scheme.

I think one issue is that the switch to a log that syncs to disk on
every write has slowed database creation time and has slowed performance
in other areas (namely insertion of large BLOBs/CLOBs). Previously the
log was marked as don't sync during db create, now that flag has no
effect and so the database creation has to wait for every log write. I
think this is something that should be addressed.

Dan.

Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Dag H. Wanvik]

Hi,

Andrew McIntyre <[EMAIL PROTECTED]> writes:

> Yep, that's right. I've added this version to JIRA. We need this also
> to track the inevitable removal of our "early-access" language around
> the JDBC 4 bits. Which reminds me...

Could you please also add an entry for version 11? Cf my need
mentioned here:

http://www.nabble.com/forum/ViewPost.jtp?post=5604369&framed=y

Dag

Re: Copyrights

[Jean T. Anderson]

Rick Hillegas wrote:
> I hope that David can commit the work for DERBY-1377 before we cut the
> 10.2 branch next week. Unfortunately, I think David is stuck because
> it's unclear what's required. Here's where I think this issue stands:
> 
> UNRESOLVED ISSUES:
> 
> 1) Do we need to add license headers to our build scripts, property
> files, README files, and other human-readable files which currently
> don't have copyright notices? Or are these files excluded under the
> rubric of "file without any degree of creativity"? Does some other
> escape-clause exlude these files?

If there's any question, I believe there's no harm in adding them.
http://www.apache.org/legal/src-headers.html says:
"If in doubt about the extent of the file's creativity, add the license
header to the file."

> 2) Should the IBM copyrights migrate from the COPYRIGHT to the NOTICE
> file? If so, who is authorized to move these copyrights?

My understanding is a deviation from the ASF guideline, if that's the
right thing to do in this case, needs the DB PMC to accept or reject
it[1]. If PMC approval is needed, time needs to be allowed.  Also, one
option might be to do this [2]:

> Leave it as is, or add our license header above the copyright line and
> remove the header below the copyright line, leaving the copyright line
> as is.

If this seems suitable, we should also run it by the PMC. At any rate,
it would really help for any who objected to also participate in this
discussion beyond simply objecting.

 -jean


[1]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
PROTECTED]

> 3) Are there other unclear issues?
> 
> I would like the community's guidance soon.
> 
> Thanks,
> -Rick
> 

Re: Copyrights

[Jean T. Anderson]

Jean T. Anderson wrote:
> Rick Hillegas wrote:
...
>>2) Should the IBM copyrights migrate from the COPYRIGHT to the NOTICE
>>file? If so, who is authorized to move these copyrights?
> 
> 
> My understanding is a deviation from the ASF guideline, if that's the
> right thing to do in this case, needs the DB PMC to accept or reject
> it[1]. If PMC approval is needed, time needs to be allowed.  Also, one
> option might be to do this [2]:
>  
>>Leave it as is, or add our license header above the copyright line and
>>remove the header below the copyright line, leaving the copyright line
>>as is.

Sorry, the option I posted would be for the current copyright line in
the source files, does not address moving the IBM copyright from the
COPYRIGHT file to NOTICE file. I don't know on that one.

 -jean

> 
> If this seems suitable, we should also run it by the PMC. At any rate,
> it would really help for any who objected to also participate in this
> discussion beyond simply objecting.
> 
>  -jean
> 
> 
> [1]
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
> PROTECTED]
> [2]
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
> PROTECTED]
> 
> 
>>3) Are there other unclear issues?
>>
>>I would like the community's guidance soon.
>>
>>Thanks,
>>-Rick
>>
> 
> 

Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Satheesh Bandaram]

Andrew McIntyre wrote:

> On 8/3/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
>
>> Yes, please! If I knew the JIRA magic to do this, I would mumble it.
>> Could someone teach me the magic, and if necessary, give me karma to
>> mumble?
>
>
> granted. the admin pages are your friends.

Can you please take me off from JIRA-admin group? JIRA says I can't
remove my own membership to this group!

Or Rick, you want to try doing this and use your new karma? :)

Satheesh

Re: Copyrights

[Daniel John Debrunner]

Rick Hillegas wrote:

> I hope that David can commit the work for DERBY-1377 before we cut the
> 10.2 branch next week. Unfortunately, I think David is stuck because
> it's unclear what's required. Here's where I think this issue stands:
> 
> UNRESOLVED ISSUES:
> 
> 1) Do we need to add license headers to our build scripts, property
> files, README files, and other human-readable files which currently
> don't have copyright notices? Or are these files excluded under the
> rubric of "file without any degree of creativity"? Does some other
> escape-clause exlude these files?
> 
> 2) Should the IBM copyrights migrate from the COPYRIGHT to the NOTICE
> file? If so, who is authorized to move these copyrights?

Yes. I will move them and remove the COPYRIGHT FILE. The rule for
copyright statments is the owner has to remove them or give permission
for them to be removed.

> 3) Are there other unclear issues?

One clear issue that no-one has mentioned. Based upon the guidelines at
http://www.apache.org/legal/src-headers.html we should no longer commit
any contribution that has a copyright statement in it. E.g. a new file
should not be accepted if it has a copyright statement in it. The owner
of the copyright needs to remove the statement, so it's not as easy as
the committer simply deleting it.

I don't think there are any other issues outstanding.

Dan.

[jira] Commented: (DERBY-1614) Test harness overrides heap size settings when starting Network Server

[Myrna van Lunteren (JIRA)]

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

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

Assuming that things get put in for a reason and people would document 
(possibly) the reason I did some historical research.

The first incantation in source control of this harness server code that I 
could find already forces a setting of -sm16m -xm32 -noasyncgc for connecting 
through RmiJdbc to Weblogic Server - which was supported in version 1.5 of 
cloudscape.

Code to accept jvmflags was added in in 2001 in cloudscape, and this section 
looked then much like how it was contributed to apache. (see:  
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/harness/NetServer.java?revision=57503&view=markup)

The present code, making this optional depending on jvmflags being set or not 
went in with revision 160372 for DERBY-121.
(see: 
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/harness/NetServer.java?r1=160372&r2=179859)
There is no specific documentation for this part of the change, but I assume 
the intent was to just ensure the NetworkServer's heap size settings would get 
overwritten when set by jvmflags.

I keep going back and forth between A and B. 
I wonder whether the default heap sizes of jdk131 vs. jdk142 vs. jdk15 etc have 
changed. 
I also wonder if it's possible for certain jvms to have default sizes that 
differ from machine to machine (I know they do differ between Windows and 
Linux, for example).
I worry about causing failures on machines where previously the tests ran fine.

On the other hand, this change has been in for a while, so maybe it's not 
affected anyone. And also, the setting is hidden from view. And not working 
properly. And to get it working properly would take more effort, and we should 
also make sure it can't get overwritten by settings coming through on 
testSpecialProps or testJavaFlags. It would be clearer to leave the setting to 
the test and remove it from NetServer.java...

So, I cautiously vote for A. 


> Test harness overrides heap size settings when starting Network Server
> --
>
> Key: DERBY-1614
> URL: http://issues.apache.org/jira/browse/DERBY-1614
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
> Environment: Test frameworks DerbyNet and DerbyNetClient
>Reporter: John H. Embretsen
> Assigned To: John H. Embretsen
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1614_v1.diff, DERBY-1614_v2.diff
>
>
> Test specific heap size settings can be passed to the test harness using the 
> jvmflags system property, for example in a _app.properties file or 
> at the command line when starting a test, e.g "-Djvmflags=-Xms32m^-Xmx32m".
> The test harness almost always overrides such settings when starting a new 
> Network Server using the 
> org.apache.derbyTesting.functionTests.harness.NetServer class of the test 
> harness. Currently, if _either_ -ms _or_ -Xms is missing from the jvmflags, 
> NetServer.start() adds -ms16777216. Also, if _either_ -mx _or_ -Xmx is 
> missing from the jvmflags, NetServer.start() adds -ms33554432. This has been 
> the case since SVN revision 420048 (July 8, 2006).
> Earlier revisions did not override the heap settings unless the newer -Xms or 
> -Xmx flags were used instead of the -ms and -mx flags. A patch for DERBY-1091 
> attempted (among other things) to make the harness recognize the newer flags 
> as well as the older flags, but the resulting behavior is (most likely) not 
> as intended. 
> If a test is run in either the DerbyNet framework or the DerbyNetClient 
> framework, the test-specific JVM flags should (probably) be used for the 
> Network Server JVM as well as the test JVM. Currently, even if non-default 
> heap size flags are passed to the harness, the server JVM will ignore these 
> settings since the harness adds -ms and/or -mx flags _after_ all other heap 
> flags. The exception is if both new and old versions of heap flags are passed 
> to the harness, e.g:
> jvmflags=-ms32m^-Xms32m^-mx128m^-Xmx128m
> Here is the code causing this behaviour:
> if (setJvmFlags && ((jvmflags.indexOf("-ms") == -1) || 
> (jvmflags.indexOf("-Xms") == -1)))
>  // only setMs if no starting memory was given
>  jvm.setMs(16*1024*1024); // -ms16m
> if (setJvmFlags && ((jvmflags.indexOf("-mx") == -1) || 
> (jvmflags.indexOf("-Xmx") == -1)))
>  // only setMx if no max memory was given
>  jvm.setMx(32*1024*1024); // -mx32m

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

Re: Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Andrew McIntyre]

On 8/3/06, Satheesh Bandaram <[EMAIL PROTECTED]> wrote:


Can you please take me off from JIRA-admin group? JIRA says I can't
remove my own membership to this group!


done.

Re: Copyrights

[Jean T. Anderson]

Daniel John Debrunner wrote:
> Rick Hillegas wrote:
...
>>3) Are there other unclear issues?
> 
> One clear issue that no-one has mentioned. Based upon the guidelines at
> http://www.apache.org/legal/src-headers.html we should no longer commit
> any contribution that has a copyright statement in it. E.g. a new file
> should not be accepted if it has a copyright statement in it. The owner
> of the copyright needs to remove the statement, so it's not as easy as
> the committer simply deleting it.

The DB PMC can approve committing a contribution with a copyright
statement in it.

http://issues.apache.org/jira/browse/DERBY-1377#action_12422783 says this:

> Copyright 1997, 2004 The Apache Software Foundation or its licensors, as 
> applicable.
> 
> Removing these might require the permission of the actual copyright holders, 
> which might be a pain to track down as to who has copyright on each file 
> (allowing multiple holders per file). The new ASF policy does allow copyright 
> notices to be left in the header (but would prefer not to). 

Is there a resolution for this?

 -jean

Re: Copyrights

[Daniel John Debrunner]

Jean T. Anderson wrote:

> Daniel John Debrunner wrote:
> 
>>Rick Hillegas wrote:
> 
> ...
> 
>>>3) Are there other unclear issues?
>>
>>One clear issue that no-one has mentioned. Based upon the guidelines at
>>http://www.apache.org/legal/src-headers.html we should no longer commit
>>any contribution that has a copyright statement in it. E.g. a new file
>>should not be accepted if it has a copyright statement in it. The owner
>>of the copyright needs to remove the statement, so it's not as easy as
>>the committer simply deleting it.
> 
> 
> The DB PMC can approve committing a contribution with a copyright
> statement in it.

Where does it say that on the policy page?

http://www.apache.org/legal/src-headers.html

All I see is


If the source file is submitted with a copyright notice included in it,
the copyright owner (or owner's agent) must either:

   1. remove such notices, or
   2. move them to the NOTICE file associated with each applicable
project release, or
   3. provide written permission for the ASF to make such removal or
relocation of the notices.


>From the discussions I've looked at in legal-discuss archives, it's very
clear that the policy for *new* files coming into the ASF that they must
not contain a copyright statement.

Not this is separate from existing copyright statements in existing
files in ASF svn respositories.

Dan.

Re: Copyrights

[Jean T. Anderson]

Daniel John Debrunner wrote:
>Jean T. Anderson wrote: 
>>Daniel John Debrunner wrote:
>>>Rick Hillegas wrote:
>>...
3) Are there other unclear issues?
>>>
>>>One clear issue that no-one has mentioned. Based upon the guidelines at
>>>http://www.apache.org/legal/src-headers.html we should no longer commit
>>>any contribution that has a copyright statement in it. E.g. a new file
>>>should not be accepted if it has a copyright statement in it. The owner
>>>of the copyright needs to remove the statement, so it's not as easy as
>>>the committer simply deleting it.
>>
>>
>>The DB PMC can approve committing a contribution with a copyright
>>statement in it.
> 
> Where does it say that on the policy page?
> 
> http://www.apache.org/legal/src-headers.html
...

Not on that page.

I have that understand from posts on legal-discuss regarding the source
header changes.

First by this post by Roy Fielding [1]:

   On Jun 5, 2006, at 11:04 AM, Stephen McConnell ((DPML)) wrote:
   > In addition to the above I would like to know the ASF position
   > concerning
   > potentially new contributions to the ASF associated to known and
   > reachable
   > contributors via existing copyright assertions who are unwilling to
   > acquiesce to the removal of copyright statements from existing
   > documents.

   The law does not allow us to remove or alter the copyright notice
   without the copyright owner's consent.  When new contributions are
   made, the responsible PMC decides whether the contribution is in a
   form that they deem acceptable, and either accepts it or rejects it.

And this post, also by Roy Fielding [2]:

   On Jun 5, 2006, at 3:38 PM, Noel J. Bergman wrote:
   > Is a copyright entry acceptable only for an initial contribution,
   > and not
   > thereafter?  Or what?  And, yes, I understand that PMCs can make
   > decisions,
   > but we really ought to have a policy to prevent things turning into
   > copywrong.

   A PMC must vote to accept the contribution. The PMC can choose not to
   accept the contribution based on anything it doesn't like.  If we make
   a special rule based on all of the possible anti-social behaviors
   that might lead to chaos, then our PMCs are never going to learn how
   to govern themselves.  We only need ASF-wide rules for the things that
   are required of the ASF as a whole.

Anything that does not match the documented guideline should be popped
to the PMC. And, if there's any doubt about what the PMC can and cannot
do, the PMC itself can get further guidance.

 -jean

[1]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
PROTECTED]

[2]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
PROTECTED]

Re: Copyrights

[Jean T. Anderson]

Jean T. Anderson wrote:
> Daniel John Debrunner wrote: 
>>Rick Hillegas wrote:
>>>3) Are there other unclear issues?
...
This point from DERBY-1377 is falling into the cracks:

> http://issues.apache.org/jira/browse/DERBY-1377#action_12422783 says this:
> 
>>Copyright 1997, 2004 The Apache Software Foundation or its licensors, as 
>>applicable.
>>
>>Removing these might require the permission of the actual copyright holders, 
>>which might be a pain to track down as to who has copyright on each file 
>>(allowing multiple holders per file). The new ASF policy does allow copyright 
>>notices to be left in the header (but would prefer not to). 
> 
> Is there a resolution for this?

Dan, you expressed concern about handling of the "Copyright 1997, 2004
The Apache Software Foundation or its licensors, as applicable." line.
How do you think that should be handled?

thanks,

 -jean

Re: DOCS - Alpha version (PDF) of Admin Guide does not appear on Apache Derby page

[Jean T. Anderson]

Laura Stewart wrote:
> On the Derby Manuals page
> (http://db.apache.org/derby/manuals/index.html)
> 
> when I click on the link for the Alpha PDF version of the Derby Server
> and Administration Guide
> (http://db.apache.org/derby/docs/dev/adminguide/derbyadmin.pdf)
> 
> nothing appears.  When I try the same for the Reference Manual, the
> PDF version of the doc appears.

The Server and Admin Guide is working for me, Laura. And I just verified
I can access all of the alpha PDFs.

Could you try again, Laura?  Maybe somebody caught and fixed something
between the times you and I tried.

 -jean

Re: DOCS - Alpha version (PDF) of Admin Guide does not appear on Apache Derby page

[Laura Stewart]

*** (LS) I refreshed me view.  All of them except the Admin Guide work
for me. Very strange.

On 8/3/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote:

Laura Stewart wrote:
> On the Derby Manuals page
> (http://db.apache.org/derby/manuals/index.html)
>
> when I click on the link for the Alpha PDF version of the Derby Server
> and Administration Guide
> (http://db.apache.org/derby/docs/dev/adminguide/derbyadmin.pdf)
>
> nothing appears.  When I try the same for the Reference Manual, the
> PDF version of the doc appears.

The Server and Admin Guide is working for me, Laura. And I just verified
I can access all of the alpha PDFs.

Could you try again, Laura?  Maybe somebody caught and fixed something
between the times you and I tried.

 -jean




--
Laura Stewart

Re: DOCS - Alpha version (PDF) of Admin Guide does not appear on Apache Derby page

[Jean T. Anderson]

Laura Stewart wrote:
> *** (LS) I refreshed me view.  All of them except the Admin Guide work
> for me. Very strange.

Which browser are you using? I'm opening the PDF from inside Mozilla
Firefox.

If you download the pdf first then open it with Acrobat, does that work?

 -jean

[jira] Commented: (DERBY-1621) Trigger action statement is not recompile when there is a change that would affect it.

[Yip Ng (JIRA)]

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

Yip Ng commented on DERBY-1621:
---

Here is an analysis of the problem and the cause:

At create trigger time, the stored prepared statement 'insert into t2 values 1' 
will get compiled.  All the dependencies of this stored prep stmt will be 
cleared out and will be copied to the SPSDescriptor
which will be serialized to SYSDEPENDS as a stored dependency (provider is 
table descriptor t2)  

When inserting the value 1 to table t1, the table descriptor t1 will have all 
the relevent trigger(s) associated with it at bind time.  At execution time, 
the after trigger action is fired.  The StatementTriggerExecutor will request 
the trigger descriptor tt for its action routine via the SPSDescriptor.  Since 
it is not in the sps cache, it will load a 
copy of SPSDescriptor from SYSSTATEMENTS system table.  Since the valid field 
is still true, there is no need to recompile the stored prep statement.  The 
trigger action gets executed.  Also note that the trigger descriptor tt 
associated with the 'insert into t1 values 1' statement has saved the reference 
for the SPSDescriptor.

At execution time of the create unique index statement, it will invalidated all 
the dependents of the table descriptor t2.  The stored dependency SPSDescriptor 
will load from SYSDEPENDS, so Derby is invalidating this "copy" and also 
successfully updates the SYSSTATEMENTS entry to make this trigger action 's 
valid column to false.

Now the problem arises when we execute "insert into t1 values 1" again since 
its trigger descriptor tt still references with its copy of the SPSDescriptor 
which is still valid, it won't recompile the stored prep stmt causing the 
symptoms described above.

Also note that with the drop index tu statement, at execution time, it 
invalidates all its dependents but the SPSDescriptor is not one of its 
dependents.
 

> Trigger action statement is not recompile when there is a change that would 
> affect it.
> --
>
> Key: DERBY-1621
> URL: http://issues.apache.org/jira/browse/DERBY-1621
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Yip Ng
>Priority: Critical
> Fix For: 10.2.0.0
>
>
> A trigger action statement, such as an INSERT statement is not recompiled 
> when there is some DDL change on the underlying table, such as a CREATE INDEX.
> In the example below a unique index is added to the table (t2) inserted into 
> by the trigger's action statement. When the tirgger fires it does not raise 
> any error (should raise a unique constraint violated error) and does not 
> insert the value into the index. A select from t2 does not show the 
> additional rows in t2 as it is performing an index scan, once the index is 
> dropped the rows appear to the select.
> ij version 10.2
> ij> connect 'jdbc:derby:cs;create=true';
> ij> create table t (i int);
> 0 rows inserted/updated/deleted
> ij> create table t2 (i int);
> 0 rows inserted/updated/deleted
> ij> create trigger tt after insert on t for each statement mode db2sql
> insert into t2 values 1;
> 0 rows inserted/updated/deleted
> ij> insert into t values 1;
> 1 row inserted/updated/deleted
> ij> select * from t2;
> I
> ---
> 1
> 1 row selected
> ij> create unique index tu on t2(i);
> 0 rows inserted/updated/deleted
> ij> insert into t values 1;
> 1 row inserted/updated/deleted
> ij> select * from t2;
> I
> ---
> 1
> 1 row selected
> ij> insert into t values 1;
> 1 row inserted/updated/deleted
> ij> select * from t2;
> I
> ---
> 1
> 1 row selected
> ij> drop index tu;
> 0 rows inserted/updated/deleted
> ij> select * from t2;
> I
> ---
> 1
> 1
> 1
> 3 rows selected

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

[Rick Hillegas]

Jean T. Anderson wrote:


Jean T. Anderson wrote:
 

Daniel John Debrunner wrote: 
   


Rick Hillegas wrote:
 


3) Are there other unclear issues?
   


...
This point from DERBY-1377 is falling into the cracks:

 


http://issues.apache.org/jira/browse/DERBY-1377#action_12422783 says this:

   


Copyright 1997, 2004 The Apache Software Foundation or its licensors, as 
applicable.

Removing these might require the permission of the actual copyright holders, which might be a pain to track down as to who has copyright on each file (allowing multiple holders per file). The new ASF policy does allow copyright notices to be left in the header (but would prefer not to). 
 


Is there a resolution for this?
   



Dan, you expressed concern about handling of the "Copyright 1997, 2004
The Apache Software Foundation or its licensors, as applicable." line.
How do you think that should be handled?

thanks,

-jean
 


I'm afraid I don't understand the issue here. Is it one of the following:

A) We don't know who the "licensors" are and are wondering if we have to 
identify the licensors and ask their permission?


B) The verbiage above implies a copyright claim by the individual 
contributor (or the company which hired the contributor) and we are 
wondering if we have to identify these contributors/companies and ask 
their permission?


C) Something else?

Thanks,
-Rick

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

[Craig Russell (JIRA)]

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

Craig Russell commented on DERBY-1516:
--

Hi Dag,

You know, I read this a hundred times and did not read it as allowing 
t2.substring(1,1), since clearly 1 is beyond the length of the String.

substring(int beginIndex, int endIndex)
Throws:
IndexOutOfBoundsException - if the beginIndex is negative, or endIndex is 
larger than the length of this String object, or beginIndex is larger than 
endIndex.

But you are right and I'll change the implementation to support this. Much 
cleaner indeed.

I will reimplement the test for the case of pos one beyond the length of the 
Lob, which would now be legal. It would always return a zero-length result.

Thanks,

Craig

> 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
> Assigned To: Craig Russell
>Priority: Minor
> Attachments: DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch, 
> 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

Re: DOCS - Alpha version (PDF) of Admin Guide does not appear on Apache Derby page

[Laura Stewart]

***(LS) Mozilla works fine. I am using Windows Explorer.  The
Documentation page does not appear to have a down load option for the
docs.

On 8/3/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote:

Laura Stewart wrote:
> *** (LS) I refreshed me view.  All of them except the Admin Guide work
> for me. Very strange.

Which browser are you using? I'm opening the PDF from inside Mozilla
Firefox.

If you download the pdf first then open it with Acrobat, does that work?

 -jean




--
Laura Stewart

[jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Rick Hillegas (JIRA)]

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

Rick Hillegas updated DERBY-700:


Fix Version/s: 10.2.2.0
   (was: 10.3.0.0)

Thanks for creating the new 10.2.2.0 option, Andrew! I've reassigned this issue 
to that release.

> Derby does not prevent dual boot of database from different classloaders on 
> Linux
> -
>
> Key: DERBY-700
> URL: http://issues.apache.org/jira/browse/DERBY-700
> Project: Derby
>  Issue Type: Bug
>  Components: Store
>Affects Versions: 10.1.2.1
> Environment: ava -version
> java version "1.4.2_08"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
>Reporter: Kathey Marsden
> Assigned To: V.Narayanan
>Priority: Critical
> Fix For: 10.2.2.0
>
> Attachments: DERBY-700.diff, DERBY-700.stat, 
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.diff, 
> DERBY-700_v1_use_to_run_DualBootrepro_multithreaded.stat, DualBootRepro.java, 
> DualBootRepro2.zip, DualBootRepro_mutltithreaded.tar.bz2
>
>
> Derby does not prevent dual boot from two different classloaders on Linux.
> To reproduce run the  program DualBootRepro with no derby jars in your 
> classpath. The program assumes derby.jar is in 10.1.2.1/derby.jar, you can 
> change the location by changing the DERBY_LIB_DIR variable.
> On Linux the output is:
> $java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader [EMAIL PROTECTED]
> FAIL: Booted database in 2nd loader [EMAIL PROTECTED]
> On Windows I get the expected output.
> $ java -cp . DualBootRepro
> Loading derby from file:10.1.2.1/derby.jar
> 10.1.2.1/derby.jar
> Booted database in loader [EMAIL PROTECTED]
> PASS: Expected exception for dualboot:Another instance of Derby may have 
> already booted the database D:\marsden\repro\dualboot\mydb.

-- 
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: DOCS - Alpha version (PDF) of Admin Guide does not appear on Apache Derby page

[Jean T. Anderson]

Laura Stewart wrote:
> ***(LS) Mozilla works fine. I am using Windows Explorer.  The
> Documentation page does not appear to have a down load option for the
> docs.

Can you right-click on the link and choose "save as" or "save target as"?

I'm glad Mozilla works for you. Internet Explorer (6.0) worked for me as
well.

 -jean

> On 8/3/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote:
> 
>> Laura Stewart wrote:
>> > *** (LS) I refreshed me view.  All of them except the Admin Guide work
>> > for me. Very strange.
>>
>> Which browser are you using? I'm opening the PDF from inside Mozilla
>> Firefox.
>>
>> If you download the pdf first then open it with Acrobat, does that work?
>>
>>  -jean
>>
> 
> 

Re: (10.2 maintenance release version for Jira?) Re: [jira] Updated: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

[Rick Hillegas]

Andrew McIntyre wrote:


On 8/3/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:


Yes, please! If I knew the JIRA magic to do this, I would mumble it.
Could someone teach me the magic, and if necessary, give me karma to 
mumble?



granted. the admin pages are your friends.


Thanks, Andrew. Where can I find my new friends, the admin pages? I 
tried clicking on the Administration tab on a JIRA report, but that 
didn't take me to a page with useful links.


Regards,
-Rick




Kathey Marsden wrote:

> Sounds like a reasonable move since there is no immediate solution
> apparent.  I was wondering though, could  we could add a  new version
> that we can use as some of the 10.2 candidates start getting moved
> out?  I want to say 10.2.2.0 but am not sure that is right.



Yep, that's right. I've added this version to JIRA. We need this also
to track the inevitable removal of our "early-access" language around
the JDBC 4 bits. Which reminds me...

Re: Copyrights

[David Van Couvering]

I think I can get started by doing the following:

- Adding the license text to the source files where they are missing
- Changing the license verbiage to meet the new requirements but *not* 
removing the copyright notice.


In a second phase, if when this final issue gets clarified, I can do 
another pass removing the copyright notice from the source files.  Dan 
is already moving the IBM copyright from COPYRIGHTS to NOTICE.


Sound good?

David

Rick Hillegas wrote:

Jean T. Anderson wrote:


Jean T. Anderson wrote:
 

Daniel John Debrunner wrote:   

Rick Hillegas wrote:


3) Are there other unclear issues?
  

...
This point from DERBY-1377 is falling into the cracks:

 

http://issues.apache.org/jira/browse/DERBY-1377#action_12422783 says 
this:


  
Copyright 1997, 2004 The Apache Software Foundation or its 
licensors, as applicable.


Removing these might require the permission of the actual copyright 
holders, which might be a pain to track down as to who has copyright 
on each file (allowing multiple holders per file). The new ASF 
policy does allow copyright notices to be left in the header (but 
would prefer not to). 

Is there a resolution for this?
  


Dan, you expressed concern about handling of the "Copyright 1997, 2004
The Apache Software Foundation or its licensors, as applicable." line.
How do you think that should be handled?

thanks,

-jean
 


I'm afraid I don't understand the issue here. Is it one of the following:

A) We don't know who the "licensors" are and are wondering if we have to 
identify the licensors and ask their permission?


B) The verbiage above implies a copyright claim by the individual 
contributor (or the company which hired the contributor) and we are 
wondering if we have to identify these contributors/companies and ask 
their permission?


C) Something else?

Thanks,
-Rick

[jira] Created: (DERBY-1640) Instability in XATest

[Rick Hillegas (JIRA)]

Instability in XATest
-

 Key: DERBY-1640
 URL: http://issues.apache.org/jira/browse/DERBY-1640
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.2.0.0
Reporter: Rick Hillegas
 Fix For: 10.2.0.0


I am seeing the following diff in XATest, in a clean subversion client running 
under jdk14 on either Linux or cygwin/xp:

52a53
> (1 |PREPARED |false |APP |UserTransaction
54d54
< (1 |PREPARED |false |APP |UserTransaction
Test Failed.
*** End:   XATest jdk1.4.2_08 DerbyNetClient 2006-08-03 13:06:22 ***

Looks like an ordering instability.

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

[Daniel John Debrunner]

Jean T. Anderson wrote:

> Daniel John Debrunner wrote:
> 
>>Jean T. Anderson wrote: 
>>
>>>Daniel John Debrunner wrote:
>>>
Rick Hillegas wrote:
>>>
>>>...
>>>
>3) Are there other unclear issues?

One clear issue that no-one has mentioned. Based upon the guidelines at
http://www.apache.org/legal/src-headers.html we should no longer commit
any contribution that has a copyright statement in it. E.g. a new file
should not be accepted if it has a copyright statement in it. The owner
of the copyright needs to remove the statement, so it's not as easy as
the committer simply deleting it.
>>>
>>>
>>>The DB PMC can approve committing a contribution with a copyright
>>>statement in it.
>>
>>Where does it say that on the policy page?
>>
>>http://www.apache.org/legal/src-headers.html
> 
> ...
> 
> Not on that page.
> 
> I have that understand from posts on legal-discuss regarding the source
> header changes.
> 
> First by this post by Roy Fielding [1]:
> 
>On Jun 5, 2006, at 11:04 AM, Stephen McConnell ((DPML)) wrote:
>> In addition to the above I would like to know the ASF position
>> concerning
>> potentially new contributions to the ASF associated to known and
>> reachable
>> contributors via existing copyright assertions who are unwilling to
>> acquiesce to the removal of copyright statements from existing
>> documents.
> 
>The law does not allow us to remove or alter the copyright notice
>without the copyright owner's consent.  When new contributions are
>made, the responsible PMC decides whether the contribution is in a
>form that they deem acceptable, and either accepts it or rejects it.
> 
> And this post, also by Roy Fielding [2]:
> 
>On Jun 5, 2006, at 3:38 PM, Noel J. Bergman wrote:
>> Is a copyright entry acceptable only for an initial contribution,
>> and not
>> thereafter?  Or what?  And, yes, I understand that PMCs can make
>> decisions,
>> but we really ought to have a policy to prevent things turning into
>> copywrong.
> 
>A PMC must vote to accept the contribution. The PMC can choose not to
>accept the contribution based on anything it doesn't like.  If we make
>a special rule based on all of the possible anti-social behaviors
>that might lead to chaos, then our PMCs are never going to learn how
>to govern themselves.  We only need ASF-wide rules for the things that
>are required of the ASF as a whole.
> 
> Anything that does not match the documented guideline should be popped
> to the PMC. And, if there's any doubt about what the PMC can and cannot
> do, the PMC itself can get further guidance.
> 
>  -jean
> 
> [1]
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
> PROTECTED]
> 
> [2]
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
> PROTECTED]
> 


Later discussion seems to imply Roy is wrong, there is a single policy
for this issue, set by the board. PMC's cannot overrule it.

"Note in B2 of the resolution "there
should be no copyright notice in the header"."

http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200607.mbox/[EMAIL 
PROTECTED]

The board resolution in the legal-discuss matches the policy page, no
mention that PMC's can opt out.

Not clear though.

Dan.

[jira] Updated: (DERBY-1640) Instability in XATest

[Rick Hillegas (JIRA)]

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

Rick Hillegas updated DERBY-1640:
-

Description: 
I am seeing the following diff in XATest, in a clean subversion client running 
under DerbyNetClient framework on jdk14 on either Linux or cygwin/xp:

52a53
> (1 |PREPARED |false |APP |UserTransaction
54d54
< (1 |PREPARED |false |APP |UserTransaction
Test Failed.
*** End:   XATest jdk1.4.2_08 DerbyNetClient 2006-08-03 13:06:22 ***

Looks like an ordering instability.

  was:
I am seeing the following diff in XATest, in a clean subversion client running 
under jdk14 on either Linux or cygwin/xp:

52a53
> (1 |PREPARED |false |APP |UserTransaction
54d54
< (1 |PREPARED |false |APP |UserTransaction
Test Failed.
*** End:   XATest jdk1.4.2_08 DerbyNetClient 2006-08-03 13:06:22 ***

Looks like an ordering instability.


> Instability in XATest
> -
>
> Key: DERBY-1640
> URL: http://issues.apache.org/jira/browse/DERBY-1640
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Fix For: 10.2.0.0
>
>
> I am seeing the following diff in XATest, in a clean subversion client 
> running under DerbyNetClient framework on jdk14 on either Linux or cygwin/xp:
> 52a53
> > (1 |PREPARED |false |APP |UserTransaction
> 54d54
> < (1 |PREPARED |false |APP |UserTransaction
> Test Failed.
> *** End:   XATest jdk1.4.2_08 DerbyNetClient 2006-08-03 13:06:22 ***
> Looks like an ordering instability.

-- 
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-1252) Old clients with new server return wrong database metadata values for some methods

[Rick Hillegas (JIRA)]

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

Rick Hillegas commented on DERBY-1252:
--

Thanks, Dag. The fix looks solid. Derbyall had two diffs for me: 1) the 
wisconsin noise, 2) XATest under DerbyNetClient (DERBY-1640). Committed at 
subversion revision 428510.

> Old clients with new server return wrong database metadata values for some 
> methods
> --
>
> Key: DERBY-1252
> URL: http://issues.apache.org/jira/browse/DERBY-1252
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client, Network Server
>Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 
> 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
>Reporter: Dag H. Wanvik
> Assigned To: Dag H. Wanvik
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1252-10.1.diff, derby1252-10.1.stat, 
> derby1252.diff, derby1252.diff, derby1252.stat
>
>
> With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
> some metadata calls will return the wrong value for both the JCC and
> the Derby clients:
>deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>updatedAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
>ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
> This happens because these values were changed for the 10.2 with
> the addition of updatable scrollable insensitive result sets (DERBY-775),
> combined with a weakness in the way the client and the server 
> cooperates to answer these metadata calls.
> Presently, when the client application invokes these methods, the
> results will be returned by the server without regard to the identity
> of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
> The values to be returned for the methods in question are based solely
> on the values found in the file metadata_net.properties, which is part
> of the server.
> In general, some database metadata is dependent on the combination of
> the capabilities in the client and the server and the returned values
> should reflect this, which in general implies negotiating (down) to
> values which are correct for the actual combination of client and
> server.

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

[Daniel John Debrunner]

Rick Hillegas wrote:

> Jean T. Anderson wrote:
> 
>> Jean T. Anderson wrote:
>>  
>>
>>> Daniel John Debrunner wrote:   
>>>
 Rick Hillegas wrote:
 

> 3) Are there other unclear issues?
>   
>>
>> ...
>> This point from DERBY-1377 is falling into the cracks:
>>
>>  
>>
>>> http://issues.apache.org/jira/browse/DERBY-1377#action_12422783 says
>>> this:
>>>
>>>   
>>>
 Copyright 1997, 2004 The Apache Software Foundation or its
 licensors, as applicable.

 Removing these might require the permission of the actual copyright
 holders, which might be a pain to track down as to who has copyright
 on each file (allowing multiple holders per file). The new ASF
 policy does allow copyright notices to be left in the header (but
 would prefer not to). 
>>>
>>> Is there a resolution for this?
>>>   
>>
>>
>> Dan, you expressed concern about handling of the "Copyright 1997, 2004
>> The Apache Software Foundation or its licensors, as applicable." line.
>> How do you think that should be handled?
>>
>> thanks,
>>
>> -jean
>>  
>>
> I'm afraid I don't understand the issue here. Is it one of the following:
> 
> A) We don't know who the "licensors" are and are wondering if we have to
> identify the licensors and ask their permission?
> 
> B) The verbiage above implies a copyright claim by the individual
> contributor (or the company which hired the contributor) and we are
> wondering if we have to identify these contributors/companies and ask
> their permission?

I think A) & B) are the same.

Legally you cannot remove someone else's copyright notice without
permission, though as far as I understand the law is weak on shared
copright.

I will ask legal-disucss, now I understand what I have to ask.

Dan.

Re: Copyrights

[Jean T. Anderson]

Daniel John Debrunner wrote:
...
> Later discussion seems to imply Roy is wrong, there is a single policy
> for this issue, set by the board. PMC's cannot overrule it.
> 
> "Note in B2 of the resolution "there
> should be no copyright notice in the header"."
> 
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200607.mbox/[EMAIL 
> PROTECTED] 

good catch -- thanks.

> The board resolution in the legal-discuss matches the policy page, no
> mention that PMC's can opt out.
>  
> Not clear though.

yup!

 -jean

Re: Copyrights

[Daniel John Debrunner]

David Van Couvering wrote:

> I think I can get started by doing the following:
> 
> - Adding the license text to the source files where they are missing
> - Changing the license verbiage to meet the new requirements but *not*
> removing the copyright notice.
> 
> In a second phase, if when this final issue gets clarified, I can do
> another pass removing the copyright notice from the source files.  Dan
> is already moving the IBM copyright from COPYRIGHTS to NOTICE.
> 
> Sound good?

+1
Dan.

Re: Copyrights

[Daniel John Debrunner]

Daniel John Debrunner wrote:


> One clear issue that no-one has mentioned. Based upon the guidelines at
> http://www.apache.org/legal/src-headers.html we should no longer commit
> any contribution that has a copyright statement in it. E.g. a new file
> should not be accepted if it has a copyright statement in it. The owner
> of the copyright needs to remove the statement, so it's not as easy as
> the committer simply deleting it.

And new files must have the new licence wording, I didn't realise the
first paragraph had changed until David said he was going to make such
changes.

Dan.

[jira] Resolved: (DERBY-1252) Old clients with new server return wrong database metadata values for some methods

[Dag H. Wanvik (JIRA)]

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

Dag H. Wanvik resolved DERBY-1252.
--

Resolution: Fixed
Derby Info: [Existing Application Impact, Regression]  (was: [Existing 
Application Impact, Patch Available, Regression])

> Old clients with new server return wrong database metadata values for some 
> methods
> --
>
> Key: DERBY-1252
> URL: http://issues.apache.org/jira/browse/DERBY-1252
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client, Network Server
>Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 
> 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
>Reporter: Dag H. Wanvik
> Assigned To: Dag H. Wanvik
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1252-10.1.diff, derby1252-10.1.stat, 
> derby1252.diff, derby1252.diff, derby1252.stat
>
>
> With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
> some metadata calls will return the wrong value for both the JCC and
> the Derby clients:
>deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>updatedAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
>ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
> This happens because these values were changed for the 10.2 with
> the addition of updatable scrollable insensitive result sets (DERBY-775),
> combined with a weakness in the way the client and the server 
> cooperates to answer these metadata calls.
> Presently, when the client application invokes these methods, the
> results will be returned by the server without regard to the identity
> of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
> The values to be returned for the methods in question are based solely
> on the values found in the file metadata_net.properties, which is part
> of the server.
> In general, some database metadata is dependent on the combination of
> the capabilities in the client and the server and the returned values
> should reflect this, which in general implies negotiating (down) to
> values which are correct for the actual combination of client and
> server.

-- 
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-1252) Old clients with new server return wrong database metadata values for some methods

[Kathey Marsden (JIRA)]

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

Kathey Marsden commented on DERBY-1252:
---

now that this is fixed , is there still existing application impact?  If not 
then we should uncheck the box.
"Existing application impact"  should a field  users can query on to see if 
there have been changes that might affect their application. Once a regression 
is fixed it can be unchecked if there is nothing that remains that might impact 
users.




> Old clients with new server return wrong database metadata values for some 
> methods
> --
>
> Key: DERBY-1252
> URL: http://issues.apache.org/jira/browse/DERBY-1252
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client, Network Server
>Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 
> 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
>Reporter: Dag H. Wanvik
> Assigned To: Dag H. Wanvik
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1252-10.1.diff, derby1252-10.1.stat, 
> derby1252.diff, derby1252.diff, derby1252.stat
>
>
> With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
> some metadata calls will return the wrong value for both the JCC and
> the Derby clients:
>deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>updatedAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
>ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
> This happens because these values were changed for the 10.2 with
> the addition of updatable scrollable insensitive result sets (DERBY-775),
> combined with a weakness in the way the client and the server 
> cooperates to answer these metadata calls.
> Presently, when the client application invokes these methods, the
> results will be returned by the server without regard to the identity
> of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
> The values to be returned for the methods in question are based solely
> on the values found in the file metadata_net.properties, which is part
> of the server.
> In general, some database metadata is dependent on the combination of
> the capabilities in the client and the server and the returned values
> should reflect this, which in general implies negotiating (down) to
> values which are correct for the actual combination of client and
> server.

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

[David Van Couvering]

Turns out that trying to hack the script to *not* remove the copyright 
statement, and then at a future run build a new script that *only* 
removes the copyright statement, is more work than I'm willing to do. 
Also, it means doing two passes through the entire source tree (I was 
going to do it one directory at a time), with lots of very careful 
checking and double-checking to make sure it was all done right.  I'd 
rather only go through that once...


Do I understand correctly that code contributed under CLA after the 
original IBM contribution must also require gaining permission from the 
original contributors?  Does this basically mean that we need to get 
permission from every person who has ever contributed code to Derby 
before I can run this script?  I guess this is what you're trying to 
find out, Dan, right?


Thanks,

David

Daniel John Debrunner wrote:

David Van Couvering wrote:


I think I can get started by doing the following:

- Adding the license text to the source files where they are missing
- Changing the license verbiage to meet the new requirements but *not*
removing the copyright notice.

In a second phase, if when this final issue gets clarified, I can do
another pass removing the copyright notice from the source files.  Dan
is already moving the IBM copyright from COPYRIGHTS to NOTICE.

Sound good?


+1
Dan.

Re: Copyrights

[Daniel John Debrunner]

Rick Hillegas wrote:

> I hope that David can commit the work for DERBY-1377 before we cut the
> 10.2 branch next week. Unfortunately, I think David is stuck because
> it's unclear what's required. Here's where I think this issue stands:
> 
> UNRESOLVED ISSUES:
> 
> 1) Do we need to add license headers to our build scripts, property
> files, README files, and other human-readable files which currently
> don't have copyright notices? Or are these files excluded under the
> rubric of "file without any degree of creativity"? Does some other
> escape-clause exlude these files?

So I'll go out on a limb and say:

  output from tests (.out) files have "no degree of creativity" since
they are computer generated from other files.

  property files (.properties) have "no degree of creativity"  since
they are just lists of values

  SQL test scripts (.sql etc) have "no degree of creativity" since they
have no stand-alone purpose and can be considered as a non-creative
representation of a test plan. Sound good :-)

Dan.

Re: Copyrights

[Daniel John Debrunner]

David Van Couvering wrote:


> Do I understand correctly that code contributed under CLA after the
> original IBM contribution must also require gaining permission from the
> original contributors?  Does this basically mean that we need to get
> permission from every person who has ever contributed code to Derby
> before I can run this script?  I guess this is what you're trying to
> find out, Dan, right?

Yes I'm trying to find that out, once my e-mail appears in the
legal-discuss archives I will post a link here.

Dan.

[jira] Commented: (DERBY-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.

[Yip Ng (JIRA)]

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

Yip Ng commented on DERBY-1554:
---

Hi Narayanan

   I looked at the attached patch.  It is returning the wrong result in the 
following case:
It should be null.

ij> create table t1 (i int generated by default as identity, j int);
0 rows inserted/updated/deleted
ij> create table t2 (i int);
0 rows inserted/updated/deleted
ij> insert into t1 (i) select i from t2;
0 rows inserted/updated/deleted
ij> values identity_val_local();
1
---
0

1 row selected



> IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row 
> INSERT statement.
> 
>
> Key: DERBY-1554
> URL: http://issues.apache.org/jira/browse/DERBY-1554
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Yip Ng
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1554.diff, DERBY-1554.stat
>
>
> Changes made in DERBY-353 break the documented behaviour of 
> IDENTITY_VAL_LOCAL(). Now the returned value is modified when a multi-row 
> insert is performed.
> IDENTITY_VAL_LOCAL() should not be updated when this occurs.
> For this script the last value returned should be 2 (as in 10.1) but in 10.2 
> is 4
> create table ta (a int, b int generated always as identity);
> insert into ta(a) values 100;
> values IDENTITY_VAL_LOCAL();
> insert into ta(a) values 200;
> values IDENTITY_VAL_LOCAL();
> insert into ta(a) values 300,400;
> values IDENTITY_VAL_LOCAL();

-- 
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-1554) IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row INSERT statement.

[Yip Ng (JIRA)]

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

Yip Ng commented on DERBY-1554:
---

Hi Narayanan

   It is failing in this case also, the result should be null.  I think the 
rowCount comparison cannot be used
to determine whether to set the identity val or not.  It should be based on the 
source resultset type.

ij> create table t1 (i int generated by default as identity, j int);
0 rows inserted/updated/deleted
ij> create table t2 (i int);
0 rows inserted/updated/deleted
ij> insert into t2 values 10;
1 row inserted/updated/deleted
ij> insert into t1 (i) select i from t2;
1 row inserted/updated/deleted
ij> values identity_val_local();
1
---
10

1 row selected

> IDENTITY_VAL_LOCAL() returned value is modified incorrectly by a multi-row 
> INSERT statement.
> 
>
> Key: DERBY-1554
> URL: http://issues.apache.org/jira/browse/DERBY-1554
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Yip Ng
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1554.diff, DERBY-1554.stat
>
>
> Changes made in DERBY-353 break the documented behaviour of 
> IDENTITY_VAL_LOCAL(). Now the returned value is modified when a multi-row 
> insert is performed.
> IDENTITY_VAL_LOCAL() should not be updated when this occurs.
> For this script the last value returned should be 2 (as in 10.1) but in 10.2 
> is 4
> create table ta (a int, b int generated always as identity);
> insert into ta(a) values 100;
> values IDENTITY_VAL_LOCAL();
> insert into ta(a) values 200;
> values IDENTITY_VAL_LOCAL();
> insert into ta(a) values 300,400;
> values IDENTITY_VAL_LOCAL();

-- 
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-244) with linux, depending on env setting $LANG and console encoding, some i18n tests fail

[Myrna van Lunteren]

On 8/1/06, Rick Hillegas (JIRA)  wrote:

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

Rick Hillegas commented on DERBY-244:
-

I'm afraid I see diffs in these tests when run against jar files on Linux and 
jdk1.4:

urlLocale
messageLocale
iepnegativetests_ES



that's sad.
Can you
1. paste an example of a diff
2. indicate what $LANG is(was) set on your machine?
3. (if you ran a suite) attach the contents of suite_prop.txt (you may
want to check it for & remove sensitive info).

Myrna

Re: Copyrights

[Daniel John Debrunner]

Daniel John Debrunner wrote:

> David Van Couvering wrote:
> 
> 
> 
>>Do I understand correctly that code contributed under CLA after the
>>original IBM contribution must also require gaining permission from the
>>original contributors?  Does this basically mean that we need to get
>>permission from every person who has ever contributed code to Derby
>>before I can run this script?  I guess this is what you're trying to
>>find out, Dan, right?
> 
> 
> Yes I'm trying to find that out, once my e-mail appears in the
> legal-discuss archives I will post a link here.

http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200608.mbox/[EMAIL 
PROTECTED]

Dan.

[jira] Commented: (DERBY-1549) Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR

[Laura Stewart (JIRA)]

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

Laura Stewart commented on DERBY-1549:
--

This list is slightly different than the list of functions in Derby-1548. 
Missing from this list are LN and CEIL.  Should they be added as escape 
functions as well?

Also, for the escape function section in the Reference Manual, were you 
expecting to list *each* of the new functions in this section.. similar to the 
way that ABS is documented? Or  is it appropriate to indicate that any standard 
built-in function can be used in JDBC escape syntax. Only a handful of the 
built-in functions are shown in that section.

Finally, as you look at that section, look at MOD. At the end of MOD there is a 
note that says
"Note: Any Derby built-in function is allowed in this syntax, not just those 
listed in this section."
Seems to me that this note belongs at the beginning of the section (if it 
applies to all of the functions) or
if needs to have some further clarification if it somehow only applies to MOD.  
Please advise.

> Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, 
> PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR
> ---
>
> Key: DERBY-1549
> URL: http://issues.apache.org/jira/browse/DERBY-1549
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
>
> Document in the reference manual in the section "JDBC escape syntax for fn 
> keyword"

-- 
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-1549) Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR

[Daniel John Debrunner (JIRA)]

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

Daniel John Debrunner commented on DERBY-1549:
--

The list of functions is correct, thanks for checking.
They are defined by the JDBC 3.0 specification, appendix C. Derby only supports 
a sub-set of the set defined by JDBC 3.

It's incorrect to say any builtin function can be used in the JDBC escape 
syntax, that would be non-standard behaviour.

I think the line in MOD should be removed, I guess it was meant to be at the 
end of the section, but it is not true. Good catch

> Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, 
> PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR
> ---
>
> Key: DERBY-1549
> URL: http://issues.apache.org/jira/browse/DERBY-1549
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
>
> Document in the reference manual in the section "JDBC escape syntax for fn 
> keyword"

-- 
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-1611) As per the functional spec attached to DERBY-1330, a view should be dropped when a privilege required by the view is revoked.

[Daniel John Debrunner (JIRA)]

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

Daniel John Debrunner updated DERBY-1611:
-

Derby Info:   (was: [Patch Available])

Patch DERBY1611_V1_diff_DropViewOnRevoke.txt committed Revision: 428536 - 
Thanks Mamta

> As per the functional spec attached to DERBY-1330, a view should be dropped 
> when a privilege required by the view is revoked.
> -
>
> Key: DERBY-1611
> URL: http://issues.apache.org/jira/browse/DERBY-1611
> Project: Derby
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Mamta A. Satoor
> Fix For: 10.2.0.0
>
> Attachments: DERBY1611_V1_diff_DropViewOnRevoke.txt, 
> DERBY1611_V1_stat_DropViewOnRevoke.txt
>
>
> A view tracks its privileges requirements using Derby's Dependency Manager. 
> If any one of those required privileges are revoked, the view should be 
> dropped automatically. 
> I am just creating a new jira entry here so it is easier to track sub items 
> of DERBY-1330. Will link this Jira entry to DERBY-1330. 

-- 
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-1549) Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR

[Laura Stewart (JIRA)]

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

Laura Stewart commented on DERBY-1549:
--

Okay, glad that I confirmed the list, and I will remove the note under MOD.

As for documenting the new functions, I assume that they should look similar to 
ABS, since there isn't any further info here or in Derby-592 on what else 
should be documented. For example:

acos (
number
)

Arc cosine of a number. The escape syntax {fn acos(number)} is equivalent to 
the built-in syntax ACOS(number). For more details see the ACOS function.

> Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, 
> PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR
> ---
>
> Key: DERBY-1549
> URL: http://issues.apache.org/jira/browse/DERBY-1549
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
>
> Document in the reference manual in the section "JDBC escape syntax for fn 
> keyword"

-- 
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-1252) Old clients with new server return wrong database metadata values for some methods

[Dag H. Wanvik]

"Kathey Marsden (JIRA)"  writes:

> [ 
> http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12425609 
> ] 
> 
> Kathey Marsden commented on DERBY-1252:
> ---
>
> now that this is fixed , is there still existing application impact?
> If not then we should uncheck the box.  "Existing application
> impact" should a field users can query on to see if there have been
> changes that might affect their application. Once a regression is
> fixed it can be unchecked if there is nothing that remains that
> might impact users.

Yes, I was wondering about that.. For "regression" I guess one could
argue that these flags are a characteristic of the bug, and should be
left, and that, being closed, the problem is gone as
well. "Application impact" seems more belonging to the solution, and
then it gets muddy..

I agree it is more useful (and workable) to let both flags reflect the
current state of the issue (as we do for patch available). I checked
http://db.apache.org/derby/binaries/FilingDerbyIssuesInJira.doc for
explanation of how these fields should be used but didn't find
anything. Does anyone know if is it explained elsewhere? If not, I
think it would be good up update the document.

Thanks,
Dag

[jira] Updated: (DERBY-1252) Old clients with new server return wrong database metadata values for some methods

[Dag H. Wanvik (JIRA)]

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

Dag H. Wanvik updated DERBY-1252:
-

Derby Info:   (was: [Regression, Existing Application Impact])

regression gone after fix

> Old clients with new server return wrong database metadata values for some 
> methods
> --
>
> Key: DERBY-1252
> URL: http://issues.apache.org/jira/browse/DERBY-1252
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client, Network Server
>Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 
> 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
>Reporter: Dag H. Wanvik
> Assigned To: Dag H. Wanvik
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1252-10.1.diff, derby1252-10.1.stat, 
> derby1252.diff, derby1252.diff, derby1252.stat
>
>
> With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
> some metadata calls will return the wrong value for both the JCC and
> the Derby clients:
>deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>updatedAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
>ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
> This happens because these values were changed for the 10.2 with
> the addition of updatable scrollable insensitive result sets (DERBY-775),
> combined with a weakness in the way the client and the server 
> cooperates to answer these metadata calls.
> Presently, when the client application invokes these methods, the
> results will be returned by the server without regard to the identity
> of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
> The values to be returned for the methods in question are based solely
> on the values found in the file metadata_net.properties, which is part
> of the server.
> In general, some database metadata is dependent on the combination of
> the capabilities in the client and the server and the returned values
> should reflect this, which in general implies negotiating (down) to
> values which are correct for the actual combination of client and
> server.

-- 
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-1252) Old clients with new server return wrong database metadata values for some methods

[Kathey Marsden]

Dag H. Wanvik wrote:
I think iregression is good to keep for history.   A fixed regresssion 
is a fixed regression and that makes sense.
Existing application impact is a tool for users so should reflect the 
current state.



Does anyone know if is it explained elsewhere? If not, I
think it would be good up update the document.

 

I sent a proposal for Jira Field clarification  for this and other 
fields.  Please let me know if you have comments.


http://www.nabble.com/Jira-field-definition-clarification-for-Derby-tf2024859.html#a5567827

I will put it up on the Wiki and then hopefully we can phase out the 
Word document.


Kathey

[jira] Updated: (DERBY-1548) Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR

[Laura Stewart (JIRA)]

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

Laura Stewart updated DERBY-1548:
-

Attachment: derby1548_ref.diff
derby1548_ref_html.zip

Attached are a diff file and a zip file which include the documentation changes 
for this issue.

Please use the zip file to review html of the new and updated files which 
document the new built-in functions for Derby 10.2.  These files will be added 
to the Reference Manual in the Built-in Functions section. 
http://db.apache.org/derby/docs/dev/ref/ref-single.html

The updated files are:
Filename Title
rrefsqlj55788   Standard built-in functions

The new files are:
rreffuncacosACOS function
rreffuncasinASIN function
rreffuncatanATAN function
rreffuncceil CEIL nad CEILING functions
rreffunccos  COS function
rreffuncdegrees DEGREES function
rreffuncexp EXP function
rreffuncfloor   FLOOR function
rreffunclog LOG function
rreffuncpi  PI function
rreffuncradians RADIANS function
rreffuncsin SIN function
rreffunctan TAN function

In the diff file, pay particular attention to the index terms added in the 
 tags.
Thanks!



> Document builtin functions - ACOS, ASIN, ATAN, COS, SIN, TAN, PI, DEGREES, 
> RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR
> -
>
> Key: DERBY-1548
> URL: http://issues.apache.org/jira/browse/DERBY-1548
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Laura Stewart
> Attachments: derby1548_ref.diff, derby1548_ref_html.zip, 
> MathFunctions.txt
>
>
> These built-in functions were added in DERBY-475.
> They should be added to the reference guide's built-in function section.

-- 
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-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[Myrna van Lunteren (JIRA)]

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

Myrna van Lunteren updated DERBY-1629:
--

Attachment: DERBY-1629_j9canon.diff

attaching a patch - DERBY-1629_j9canon.diff that updates the j9_22 canon. 
tested the test with wctme5.7.

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1629_j9canon.diff
>
>
> In Java SE 6 runtime environments, an application may not get the SQL 
> Exception with SQL State 38000 when execution of a trigger or procedure fails 
> with an exception caused by Derby internals.  Instead, they will get the 
> underlying exception with it's SQL State.  For an example of this, see 
> lang/procedureInTrigger.sql, which has different output for Java SE 6 
> (encoded in the master/jdk16/procedureInTrigger.out file) than for other Java 
> SE runtimes.

-- 
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-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6

[Myrna van Lunteren (JIRA)]

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

Myrna van Lunteren updated DERBY-1629:
--

Derby Info: [Patch Available, Existing Application Impact, Regression]  
(was: [Existing Application Impact, Regression])

> StandardException.unexpectedUserException() does not correctly catch 
> internally generated exceptions as of JDK 1.6
> --
>
> Key: DERBY-1629
> URL: http://issues.apache.org/jira/browse/DERBY-1629
> Project: Derby
>  Issue Type: Bug
>Reporter: David Van Couvering
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1629_j9canon.diff
>
>
> In Java SE 6 runtime environments, an application may not get the SQL 
> Exception with SQL State 38000 when execution of a trigger or procedure fails 
> with an exception caused by Derby internals.  Instead, they will get the 
> underlying exception with it's SQL State.  For an example of this, see 
> lang/procedureInTrigger.sql, which has different output for Java SE 6 
> (encoded in the master/jdk16/procedureInTrigger.out file) than for other Java 
> SE runtimes.

-- 
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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network

[Craig Russell (JIRA)]

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

Craig Russell updated DERBY-1516:
-

Attachment: DERBY-1516.patch

This patch incorporates all of the comments (thank you, Kathey and Dag) and 
therefore the logic is simpler for detecting invalid positions.

The canons for blobclob4BLOB have been changed to reflect that a request for 
bytes or a substring starting at position (length + 1) is now valid and the 
result will be of zero length, regardless of the length requested. This will 
not break existing applications except possibly regression testing applications 
that depend on Derby throwing an exception for this case. 

> 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
> Assigned To: Craig Russell
>Priority: Minor
> Attachments: DERBY-1516.patch, DERBY-1516.patch, DERBY-1516.patch, 
> DERBY-1516.patch, 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

Regression Test Failure! - TinderBox_Derby 428514 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*TinderBox_Derby* 428514/2006-08-03 22:22:57 CEST
*derbyall*

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

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

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

[jira] Assigned: (DERBY-1549) Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR

[Laura Stewart (JIRA)]

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

Laura Stewart reassigned DERBY-1549:


Assignee: Laura Stewart

> Document support for JDBC escape functions: ACOS, ASIN, ATAN, COS, SIN, TAN, 
> PI , DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR
> ---
>
> Key: DERBY-1549
> URL: http://issues.apache.org/jira/browse/DERBY-1549
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.2.0.0
>Reporter: Daniel John Debrunner
> Assigned To: Laura Stewart
>
> Document in the reference manual in the section "JDBC escape syntax for fn 
> keyword"

-- 
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-1363) Derby should publish a well defined coding convention per the db project guidlines

[Kathey Marsden (JIRA)]

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

Kathey Marsden commented on DERBY-1363:
---

Putting handling of existing code aside, I would like to propose  we adopt  the 
client code format moving forward.My reasons have nothing to do with love 
of that  actual format  but are as follows:

1) We need a coding convention to be in compliance with the db project 
guidlines.
2) A large portion of the code is already in that format, Jeremy made a pass 
after contribution.
3) This issue has wasted huge amounts of time for the Derby community and burnt 
virtually every new developer.
4) The format if as Jeremy described should be fairly easy to configure in most 
IDE's.

Here is Jeremy's description of that format.
http://www.nabble.com/Re%3A-Reformat-client-code--p9229.html
It needs to be researched and documented and perhaps items that are already on 
the checklist like 80 characters per line added.

Jeremy sure was right about the bikeshed discussion [1]  and very wise to just 
pull the band-aid off quick despite all the whining by me and others.  Please 
before you consider raising serious objections to this consider all it has and 
will cost the project if we don't come to consensus on this.  

If  there are no objections,   we can then take the next step to document the 
format and next figure out how to get there for the full code base, but if we 
can get past this step I think we will have made great progress on this issue.

Kathey

http://www.unixguide.net/freebsd/faq/16.19.shtml



> Derby should publish a well defined coding convention per the db project 
> guidlines
> --
>
> Key: DERBY-1363
> URL: http://issues.apache.org/jira/browse/DERBY-1363
> Project: Derby
>  Issue Type: Task
>  Components: Web Site
>Reporter: Kathey Marsden
> Fix For: 10.2.0.0
>
>
> The DB project guidlines dictate that we should have a well defined 
> convention for coding standards.
> http://db.apache.org/source.html says
> "Java Language source code in the repository must be written in conformance 
> to the " Code Conventions for the Java Programming Language as published by 
> Sun, or in conformance with another well-defined convention specified by the 
> subproject. See the FAQ page  for links to subproject conventions."
> We should publish at least a well defined convention for new code in order to 
> comply with the db project guidlines.
> Discussion for whether to reformat or not once that is decided is under 
> discussion in the thread:
> http://www.nabble.com/Code+formatting+debate%2C+confusion+and+wasted+time+%2C+Has+it+gone+on+long+enough--t1710825.html
> but at least the coding standards should be defined.

-- 
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-1612) As per the functional spec attached to DERBY-1330, a constraint should be dropped when a privilege required by the constraint is revoked.

[Mamta A. Satoor (JIRA)]

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

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

Attachment: DERBY1612_V1_stat_DropConstraintOnRevoke.txt
DERBY1612_V1_diff_DropConstraintOnRevoke.txt

This is a patch which will provide partial support for revoke functionality for 
constraints. If revoke statement finds a constraint dependent on the 
table/column on which privilege is being revoked, the constraint will be 
dropped automatically. This functionality is similar to what is supported for 
triggers and views. And just like triggers and views, more work is required so 
that constraint will get dropped only if it depends on the particular privilege 
TYPE or particular column that is being revoked. 

This patch is similar to what has been recently submitted for view 
(DERBY-1611), triggers (DERBY-1539)

Engine code changes
1)DropConstraintConstantAction
Made this class and it's method dropConstraintAndIndex public. In addition, 
change that method to take a LanguageConnectionContext rather than an 
activation. The activation was used merely to get LanguageConnectionContext and 
hence it is ok to remove activation and simply send LanguageConnectionContext. 
This also makes it possible for ConstraintDescriptor to be able to call the 
DropConstraintConstantAction.dropConstraintAndIndex method.

2)The change to pass LanguageConnectionContext rather than the activation to 
DropConstraintConstantAction.dropConstraintAndIndex required changes in the 
calling classes. Those classes are
  a)DropTableConstantAction.java
  b)DropIndexConstantAction.java
  c)AlterTableConstantAction.java
3)Have ConstraintDescriptor call 
DropConstraintConstantAction.dropConstraintAndIndex when a revoke invalidation 
comes in for the constraint. With that call, the ConstraintDescriptor is 
dropping itself because of the revoke invalidation action.

Added following tests to grantRevokeDDL.sql
1)Constraint Test - Test1
Give a constraint privilege at table level to a user. Let user define a foreign 
key constraint based on that privilege.
Later revoke that references privilege and make sure that foreign key 
constraint gets dropped

2)Constraint Test - Test2
Have user mamta1 give a references privilege to mamta3.
Have user mamta2 give a references privilege to mamta3.
Have mamta3 create a table with 2 foreign key constraints relying on both these 
granted privileges.
Revoke one of those privileges and make sure that the foreign key constraint 
defined based on that privilege gets dropped.
Now revoke the 2nd references privilege and make sure that remaining foreign 
key constraint gets dropped

3)Constraint Test - Test3
Have mamta1 grant REFERENCES privilege on one of it's tables to mamta2
Have mamta2 create a table with primary which references mamta1's granted 
REFERENCES privilege
Have mamta2 grant REFERENCES privilege on that table to user mamta3
Have mamta3 create a table which references mamta2's granted REFERENCES 
privilege
So, the tables look as follows
a)mamta1.t11ConstraintTest (primary key)
b)mamta2.t21ConstraintTest (primary key references t11ConstraintTest)
c)mamta3.t31ConstraintTest (primary key references t21ConstraintTest)
Now revoke of granted REFERENCES privilege by mamta1 should drop the foreign 
key reference   by mamta2's table t21ConstraintTest. It should not impact the 
foreign key reference by mamta3's table t31ConstraintTest.

4)Constraint Test - Test4
Grant a REFERENCES permission at public level, create constraint, grant same 
permission at user level 
   and take away the public level permission. It ends up dropping the 
constraint. DERBY-1632

5)Constraint Test - Test5
Grant refrences privilege and select privilege on a table. Have a constraint 
depend on the references privilege. Later, a revoke of select privilege will 
end up dropping the constraint which shouldn't happen. This will be addressed 
in a subsequent patch

6)Constraint Test - Test6
Have a primary key and a unique key on a table and grant reference on both. 
Have another table rely on unique key references privilege to create a foreign 
key constraint. Later, the revoke of primary key reference will end up
dropping the foreign key constraint. This will be fixed in a subsequent patch 
(same as test5)

7)Miscellaneous test - test1 (this test is not directly related to constraint 
work but is a general grant revoke test)
Have mutliple objects depend on the same privilege and make sure they all get 
dropped when the privilege is later revoked.



> As per the functional spec attached to DERBY-1330, a constraint should be 
> dropped when a privilege required by the constraint is revoked.
> -
>
> Key: DERBY-1612
> URL: http://issues.apache.org/jira/browse/DERBY-1612
> Project: Derby
>  Issue Type: N

[jira] Updated: (DERBY-1612) As per the functional spec attached to DERBY-1330, a constraint should be dropped when a privilege required by the constraint is revoked.

[Mamta A. Satoor (JIRA)]

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

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

Derby Info: [Patch Available]

> As per the functional spec attached to DERBY-1330, a constraint should be 
> dropped when a privilege required by the constraint is revoked.
> -
>
> Key: DERBY-1612
> URL: http://issues.apache.org/jira/browse/DERBY-1612
> Project: Derby
>  Issue Type: New Feature
>  Components: SQL
>Affects Versions: 10.2.0.0
>Reporter: Mamta A. Satoor
> Assigned To: Mamta A. Satoor
> Fix For: 10.2.0.0
>
> Attachments: DERBY1612_V1_diff_DropConstraintOnRevoke.txt, 
> DERBY1612_V1_stat_DropConstraintOnRevoke.txt
>
>
> A constraint tracks its privileges requirements using Derby's Dependency 
> Manager. If any one of those required privileges are revoked, the constraint 
> should be dropped automatically. 
> I am just creating a new jira entry here so it is easier to track sub items 
> of DERBY-1330. Will link this Jira entry to DERBY-1330. 

-- 
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-1544) Address remaining upgrade task(s) to complete full upgrade mechanism for GRANT/REVOKE, specifically with changing database owner name from 'DBA' to authorizationId of user

[Deepa Remesh (JIRA)]

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

Deepa Remesh updated DERBY-1544:


Attachment: d1544-patch2-v1.diff
d1544-patch2-v1.status

Attaching a patch 'd1544-patch2-v1.diff' for the second part of this sub-task - 
grant execute privilege to 5 system routines that by default have execute 
privilege to public when a new database is created.

Changes are:
* Adds a method 'grantPublicAccessToSystemRoutines' to DataDictionaryImpl which 
is called when doing a full upgrade. This method goes through list of routines 
that needs to be granted public access and calls 
'createRoutinePermPublicDescriptor' for each routine. This is the same as the 
method that is called during database creation. It is slightly modified to 
allow specifying of an authorization id for the grantor. When upgrading, 
authorization id of user performing upgrade is used.

* Adds a test to upgrade test to verify that the 5 system routines are added to 
the routine permissions table.

With this patch, I ran the upgrade test successfully. derbyall is currently 
running. I'll post the results later.

Please note patch1 is also pending review/commit. I would appreciate any 
feedback on these patches. 

> Address remaining upgrade task(s) to complete full upgrade mechanism for 
> GRANT/REVOKE, specifically with changing database owner name from 'DBA' to 
> authorizationId of user invoking upgrade.
> -
>
> Key: DERBY-1544
> URL: http://issues.apache.org/jira/browse/DERBY-1544
> Project: Derby
>  Issue Type: Sub-task
>  Components: SQL
>Affects Versions: 10.2.0.0
> Environment: generic
>Reporter: Satheesh Bandaram
> Assigned To: Deepa Remesh
> Fix For: 10.2.0.0
>
> Attachments: d1544-patch1-draft.diff, d1544-patch1-v1.diff, 
> d1544-patch1-v1.status, d1544-patch2-v1.diff, d1544-patch2-v1.status
>
>
> Upgrading a database from 10.1 to 10.2 should automatically change database 
> owner, recorded as owner of system schemas in sysschemas, from pseudo user 
> 'DBA' to authorizationID of the user attempting upgrade. 
> Another upgrade change I am thinking about is to grant execute privilege to 5 
> system routines that by default have execute privilege to public when a new 
> database is created. Five system routines, two compress routines and three 
> statistics related routines are given execute privilege to public when a new 
> 10.2 database is created. This is not done when a 10.1 database is upgraded 
> to 10.2 and probably good to include these privileges during database upgrade.
>  

-- 
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-1641) Conglomerate requested does not exist after syscs_import_table with FK

[Matt Frantz (JIRA)]

Conglomerate requested does not exist after syscs_import_table with FK
--

 Key: DERBY-1641
 URL: http://issues.apache.org/jira/browse/DERBY-1641
 Project: Derby
  Issue Type: Bug
Affects Versions: 10.1.3.1
 Environment: Java 1.5.0_06-b05 Linux (CentOS 4)
Reporter: Matt Frantz


I have a repeatable sequence that always causes the "Conglomerate (X) requested 
does not exist" error on my system.  There are several steps.  You can use "ij" 
as follows:

1. Start with a new database, e.g. connect 'jdbc:derby:test;create=true';
2. create table y( pk integer primary key );
3. insert into y values (123);
4. create table z( pk integer not null primary key references y );
5. Create a file containing a single row of ASCII data with the number "123" 
(in ASCII) in it.  e.g. /tmp/z
6. call syscs_util.syscs_import_table( null, 'Z', '/tmp/z', ',', , null, 1 
);
7. Try to access the "Z" table, e.g. SELECT * FROM z; or DROP TABLE z;

At this point, I always get the error.  I can use this sequence in other 
contexts, but the difference, as far as I can tell, is that the table "Z" has a 
column that is both PK and FK.


-- 
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-1637) OutBufferedStream.java fails on ibm131/jdk131 jvms.

[Sunitha Kambhampati (JIRA)]

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

Sunitha Kambhampati updated DERBY-1637:
---

Attachment: 1637_jcc2.4.zip

Hi Tomohito, 

Unfortunately, there is no tmp files on the test machine where this test 
failed. But I am attaching the directory that was available.  

If I can get this to repro on my machine, I'll post the information to the 
jira. Thanks. 

Sunitha. 

> OutBufferedStream.java fails on ibm131/jdk131 jvms.
> ---
>
> Key: DERBY-1637
> URL: http://issues.apache.org/jira/browse/DERBY-1637
> Project: Derby
>  Issue Type: Bug
>  Components: Regression Test Failure
>Affects Versions: 10.2.0.0
> Environment: ibm131, sun jdk131 ,windows. derby jars are 10.2.0.5 
> alpha - (426734)
>Reporter: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: 1637_jcc2.4.zip, outbuffstream_derbyall_report.txt
>
>
> OutBufferedStream test fails with ibm131 and jdk131. I'll attach the report 
> file 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-1252) Old clients with new server return wrong database metadata values for some methods

[Dag H. Wanvik (JIRA)]

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

Dag H. Wanvik updated DERBY-1252:
-

Derby Info: [Regression]

Setting regression again, this field should reflect bug property and not be 
removed when
issue is fixed, cf mail thread 
http://www.nabble.com/Jira-field-definition-clarification-for-Derby-tf2024859.html#a5567827


> Old clients with new server return wrong database metadata values for some 
> methods
> --
>
> Key: DERBY-1252
> URL: http://issues.apache.org/jira/browse/DERBY-1252
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client, Network Server
>Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 
> 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
>Reporter: Dag H. Wanvik
> Assigned To: Dag H. Wanvik
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1252-10.1.diff, derby1252-10.1.stat, 
> derby1252.diff, derby1252.diff, derby1252.stat
>
>
> With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
> some metadata calls will return the wrong value for both the JCC and
> the Derby clients:
>deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>updatedAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
>ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
>ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
> This happens because these values were changed for the 10.2 with
> the addition of updatable scrollable insensitive result sets (DERBY-775),
> combined with a weakness in the way the client and the server 
> cooperates to answer these metadata calls.
> Presently, when the client application invokes these methods, the
> results will be returned by the server without regard to the identity
> of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
> The values to be returned for the methods in question are based solely
> on the values found in the file metadata_net.properties, which is part
> of the server.
> In general, some database metadata is dependent on the combination of
> the capabilities in the client and the server and the returned values
> should reflect this, which in general implies negotiating (down) to
> values which are correct for the actual combination of client and
> server.

-- 
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-1642) As per the functional spec attached to DERBY-1330, a "revoke execute ... restrict" should fail if there are dependent objects on the execute privilege

[Mamta A. Satoor (JIRA)]

As per the functional spec attached to DERBY-1330, a "revoke execute ... 
restrict" should fail if there are dependent objects on the execute privilege
--

 Key: DERBY-1642
 URL: http://issues.apache.org/jira/browse/DERBY-1642
 Project: Derby
  Issue Type: New Feature
  Components: SQL
Affects Versions: 10.2.0.0
Reporter: Mamta A. Satoor
 Assigned To: Mamta A. Satoor


As per the functional spec attached to DERBY-1330, a "revoke execute ... 
restrict" should fail if there are dependent objects on the execute privilege

When revoke execute is executed, a special invalidation action should be sent 
and dependent objects will need to catch that invalidation and throw an 
exception. If there are no dependents, then no exception will be thrown and 
revoke execute will succeed.

I am just creating a new jira entry here so it is easier to track sub items of 
DERBY-1330. Will link this Jira entry to DERBY-1330. 


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