Re: full stack trace with TestConnectionMethods.java
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
[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
[ 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
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
[ 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
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
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
[ 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
[ 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.
[ 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
[ 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
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.
[ 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
[ 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 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
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
[ 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
[ 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
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
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
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
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
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?
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.
[ 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
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
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
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
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
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
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
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
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)
+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
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
[ 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
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.
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)
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
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
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
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 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
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
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
[ 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
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
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
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
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 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
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
*** (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
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.
[ 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
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
[ 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
***(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
[ 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
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
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
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
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
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
[ 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
[ 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
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
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
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 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
[ 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
[ 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
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
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
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.
[ 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.
[ 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
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 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
[ 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
[ 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.
[ 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
[ 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
"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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[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
[ 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
[ 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.
[ 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.
[ 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
[ 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
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.
[ 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
[ 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
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