Re: [jira] Reopened: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
Dyre Tjeldvoll (JIRA) wrote (2006-01-23 16:23:10): [ http://issues.apache.org/jira/browse/DERBY-815?page=all ] Dyre Tjeldvoll reopened DERBY-815: -- Actually, this fix has not been oommitted yet. The commit message mentioned the wrong issue number Yes. The patch was for DERBY-825. h have to try to fix the svn log. Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() - Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Type: Sub-task Components: Network Server, Performance Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.0.2.2 Reporter: Knut Anders Hatlen Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.2.0.0 Attachments: derby-815.diff, derby-815.stat, derbyall_report.txt Reported by Kathey Marsden in DERBY-212: In reviewing the Network Server Code and profiling there were several areas that showed potential for providing performance improvement. Functions that need optimizing to prevent unneeded object creation and excessive decoding: parseSQLDTA_work() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway pgp200fVcHfeX.pgp Description: PGP signature
[jira] Resolved: (DERBY-825) writeSQLCAGRP() should use byte[] constants instead of Strings where feasible
[ http://issues.apache.org/jira/browse/DERBY-825?page=all ] Bernt M. Johnsen resolved DERBY-825: Resolution: Fixed Comitted as #370806 Fri Jan 20 14:34:53 CET 2006bernt The log message errouneous and ended up under DERBY-815. writeSQLCAGRP() should use byte[] constants instead of Strings where feasible - Key: DERBY-825 URL: http://issues.apache.org/jira/browse/DERBY-825 Project: Derby Type: Sub-task Components: Network Server, Performance Reporter: Dyre Tjeldvoll Assignee: Dyre Tjeldvoll Priority: Minor Attachments: derby-825.diff, derby-825.stat, derbynetclientmats_report.txt writeSQLCAGRP() writes Strings into the message being built. Profiling shows that it is more expensive to write a String than a byte[] because the String must be converted to UTF8. writeSQLCAGRP() writes 5 bytes for SQLState, and this is done by either writing a String constant, or the return value from SQLException.getSQLState(). For the common case where there is no exception (SQLState = 5xspace), or the exception is a dummy exception (SQLState=0 or 02000, End of Data), this is wasteful because the String has to be converted to byte[] each time, and in the case of the dummy exception, a new String object will be created each time getSQLState() is called, even if the exception object is the same (there is no caching, which is reasonable since exceptions are meant to be thrown, not kept around for a long time). A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted into the message with writeBytes(). If writeSQLCAGRP() is called with no SQLException (null) there is no attempt to put an internationalized error message into the outgoing message (The third argument to writeSQLCAXGRP() is null). This is reasonable, but the same optimization is not done when the exception is one of the dummy exceptions mentioned previously. In this case an internationalized version of the message End of Data is constructed and inserted into the message. It would be better to call writeSQLCAXGRP(..,null,..) in this case as well, since it isn't needed by the client in this case. Finally, writeSQLCAERRWARN() uses writeScalarPaddedBytes() to write values that also can be stored as byte[] constants, and written faster with writeBytes() -- 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] Reopened: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
On Jan 24, 2006, at 12:37 AM, Bernt M. Johnsen wrote: Yes. The patch was for DERBY-825. h have to try to fix the svn log. To change the log message, do: svn propedit --revprop -r 370806 svn:log This will bring up the log message in your editor, and you can fix it as necessary. andrew
Re: [jira] Reopened: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
Andrew McIntyre wrote (2006-01-24 01:38:16): On Jan 24, 2006, at 12:37 AM, Bernt M. Johnsen wrote: Yes. The patch was for DERBY-825. h have to try to fix the svn log. To change the log message, do: svn propedit --revprop -r 370806 svn:log Thanks. Dyre found the same command in the docs. Fixed now. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway pgpwuHeD99vrw.pgp Description: PGP signature
Re: [jira] Commented: (DERBY-167) Inserting values in an identity column
Hello. Sorry that I left these issues. I left DERBY-368, which corresponds to solution 2 and 3 in DERBY-167, and resolve DERBY-167 itself. Best regards. Satheesh Bandaram (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-167?page=comments#action_12363743 ] Satheesh Bandaram commented on DERBY-167: - Hi Tomohito... Do you still plan to continue work on this issue? You already submitted your new enhancement that adds BY DEFAULT option, taking care of solution 1 in the description. If you think this addresses the problem sufficiently, please update the resolution. Inserting values in an identity column -- Key: DERBY-167 URL: http://issues.apache.org/jira/browse/DERBY-167 Project: Derby Type: Improvement Components: SQL Versions: 10.1.1.0 Environment: SQL Reporter: Christian Rodriguez Assignee: Tomohito Nakayama Attachments: DERBY-167_7.patch It is not possible to insert a specific value in a column defined as identity. This makes it very hard to migrate from other RDBMSs or to import data dumped from other databases. For example, an autoincrement column in MySQL should be an identity column. The problem is that when the data is dumped from MySQL to a file, it generates inserts with values. These values cant be inserted in the Derby table. Posible solutions: 1. being able to generate by default as identity 2. being able to disable the identity feature for a column 3. being able to generate a column as non identity and after data is populated, alter table to add the identity to the column. -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
[jira] Resolved: (DERBY-167) Inserting values in an identity column
[ http://issues.apache.org/jira/browse/DERBY-167?page=all ] Tomohito Nakayama resolved DERBY-167: - Resolution: Fixed Solution 1 in this issue was done. Inserting values in an identity column -- Key: DERBY-167 URL: http://issues.apache.org/jira/browse/DERBY-167 Project: Derby Type: Improvement Components: SQL Versions: 10.1.1.0 Environment: SQL Reporter: Christian Rodriguez Assignee: Tomohito Nakayama Attachments: DERBY-167_7.patch It is not possible to insert a specific value in a column defined as identity. This makes it very hard to migrate from other RDBMSs or to import data dumped from other databases. For example, an autoincrement column in MySQL should be an identity column. The problem is that when the data is dumped from MySQL to a file, it generates inserts with values. These values cant be inserted in the Derby table. Posible solutions: 1. being able to generate by default as identity 2. being able to disable the identity feature for a column 3. being able to generate a column as non identity and after data is populated, alter table to add the identity to the column. -- 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-821) Client driver: Implicitly close exhausted result sets on the server
[ http://issues.apache.org/jira/browse/DERBY-821?page=comments#action_12363814 ] Knut Anders Hatlen commented on DERBY-821: -- Answer to my own question about why QRYCLSIMP is disabled when LMTBLKPRC is used: The DB2 driver seems to send QRYCLSIMP=1 in the OPNQRY message, but it closes the result set explicitly with a CLSQRY anyway. My best guess is that the disabling has something to do with this. I will modify the network server so that it disables QRYCLSIMP when the DB2 driver is used and the protocol is LMTBLKPRC, and enables it for the client driver (also when LMTBLKPRC is being used). Client driver: Implicitly close exhausted result sets on the server - Key: DERBY-821 URL: http://issues.apache.org/jira/browse/DERBY-821 Project: Derby Type: Improvement Components: Network Client, Network Server, Performance Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Forward-only result sets that are exhausted should be implicitly closed on the server. This way, ResultSet.close() does not have to send an explicit close message generating unnecessary network traffic. The DRDA protocol supports this. From the description of OPNQRY (open query): The qryclsimp parameter controls whether the target server implicitly closes a non-scrollable query upon end of data (SQLSTATE 02000) in association with the cursor type. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
[ http://issues.apache.org/jira/browse/DERBY-815?page=all ] Bernt M. Johnsen resolved DERBY-815: Resolution: Fixed Committed revision 371897. Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() - Key: DERBY-815 URL: http://issues.apache.org/jira/browse/DERBY-815 Project: Derby Type: Sub-task Components: Network Server, Performance Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.0.2.2 Reporter: Knut Anders Hatlen Assignee: Dyre Tjeldvoll Priority: Minor Fix For: 10.2.0.0 Attachments: derby-815.diff, derby-815.stat, derbyall_report.txt Reported by Kathey Marsden in DERBY-212: In reviewing the Network Server Code and profiling there were several areas that showed potential for providing performance improvement. Functions that need optimizing to prevent unneeded object creation and excessive decoding: parseSQLDTA_work() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-816) In DDMWriter and DDMReader, use system routines in java.util.Arrays and System.arrayCopy
[ http://issues.apache.org/jira/browse/DERBY-816?page=comments#action_12363818 ] Knut Anders Hatlen commented on DERBY-816: -- I agree with Dyre and Bryan that there's little value in these changes. I guess DDMReader and DDMWriter have been cleaned up after DERBY-212 was filed, but the issue was not updated. I suggest we close this sub-task as won't fix. In DDMWriter and DDMReader, use system routines in java.util.Arrays and System.arrayCopy Key: DERBY-816 URL: http://issues.apache.org/jira/browse/DERBY-816 Project: Derby Type: Sub-task Components: Network Server, Newcomer, Performance Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.2.0.0, 10.1.3.0, 10.1.2.2 Reporter: Knut Anders Hatlen Assignee: Dyre Tjeldvoll Priority: Trivial Fix For: 10.2.0.0 Attachments: derby-816.diff, derby-816.stat, derbyall_report.txt Reported by Kathey Marsden in DERBY-212: In DDMWriter and DDMReader, use System Routines in java.util.Arrays and System.arrayCopy instead of writing code to do functions like copy arrays and pad strings. -- 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-819) Provide JDBC4 SQLException subclasses support in Embedded driver
[ http://issues.apache.org/jira/browse/DERBY-819?page=all ] Anurag Shekhar updated DERBY-819: - Attachment: (was: derby-819.diff) Provide JDBC4 SQLException subclasses support in Embedded driver Key: DERBY-819 URL: http://issues.apache.org/jira/browse/DERBY-819 Project: Derby Type: Sub-task Components: JDBC Environment: all Reporter: Anurag Shekhar Assignee: Anurag Shekhar Priority: Minor Attachments: stat.out -- 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-819) Provide JDBC4 SQLException subclasses support in Embedded driver
[ http://issues.apache.org/jira/browse/DERBY-819?page=all ] Anurag Shekhar updated DERBY-819: - Attachment: derby-819.diff corrected indentation problems in Util.java and InternalDriver.java derbyall status 5 tests failed on solaris 10 x86 derbyall/derbynetclientmats/derbynetmats.fail:derbynet/sysinfo.java derbyall/derbynetclientmats/derbynetmats.fail:stress/stress.multi derbyall/derbyall.fail:i18n/urlLocale.sql derbyall/derbyall.fail:i18n/messageLocale.sql derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql Provide JDBC4 SQLException subclasses support in Embedded driver Key: DERBY-819 URL: http://issues.apache.org/jira/browse/DERBY-819 Project: Derby Type: Sub-task Components: JDBC Environment: all Reporter: Anurag Shekhar Assignee: Anurag Shekhar Priority: Minor Attachments: derby-819.diff, stat.out -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-839) Internationalize messages CallableStatement40 to Cursor.java in org.apache.derby.client.am
[ http://issues.apache.org/jira/browse/DERBY-839?page=all ] Anurag Shekhar reassigned DERBY-839: Assign To: Anurag Shekhar Internationalize messages CallableStatement40 to Cursor.java in org.apache.derby.client.am -- Key: DERBY-839 URL: http://issues.apache.org/jira/browse/DERBY-839 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering Assignee: Anurag Shekhar -- 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-326) Improve streaming of large objects for network server and client
[ http://issues.apache.org/jira/browse/DERBY-326?page=all ] Tomohito Nakayama updated DERBY-326: Attachment: ReEncodedInputStream.java.modifiedForLongRun This is a result of long run with modification of ReEncodedInputStream.java not to create buffer for each time. Attached ReEncodedInputStream.java.modifiedForLongRun is ReEncodedInputStream after the modification. = TestRun =1 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Populating data Data length inserted into clob = 537638 Avg time for test[1 ]=20661.984ms = = TestRun =2 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[2 ]=20764.193ms = = TestRun =3 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[3 ]=20772.66ms = = TestRun =4 Data from file to insert into Clob. = file_500k.txt buffer (k) =1 read blocks of data =false rows in table =100 Avg time for test[4 ]=20760.312ms = Throw away the result of the first run OUTPUT= Avg time taken to read 100rows+ (ignore first run )=20765ms I found that it is a little faster than before patch. However not so much ... Improve streaming of large objects for network server and client Key: DERBY-326 URL: http://issues.apache.org/jira/browse/DERBY-326 Project: Derby Type: Improvement Components: Network Server, Network Client, Performance Reporter: Kathey Marsden Assignee: Tomohito Nakayama Attachments: ClobTest.zip, DERBY-326.patch, DERBY-326_2.patch, DERBY-326_3.patch, DERBY-326_4.patch, DERBY-326_5.patch, DERBY-326_5_indented.patch, ReEncodedInputStream.java.modifiedForLongRun Currently the stream writing methods in network server and client require a length parameter. This means that we have to get the length of the stream before sending it. For example in network server in EXTDTAInputStream we have to use getString and getbytes() instead of getCharacterStream and getBinaryStream so that we can get the length. SQLAM Level 7 provides for the enhanced LOB processing to allow streaming without indicating the length, so, the writeScalarStream methods in network server DDMWriter.java and network client Request.java can be changed to not require a length. Code inspection of these methods seems to indicate that while the length is never written it is used heavily in generating the DSS. One strange thing is that it appears on error, the stream is padded out to full length with zeros, but an actual exception is never sent. Basically I think perhaps these methods need to be rewritten from scratch based on the spec requirements for lobs. After the writeScalarStream methods have been changed, then EXTDAInputStream can be changed to properly stream LOBS. See TODO tags in this file for more info. I am guessing similar optimizations available in the client as well, but am not sure where that code is. -- 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-326) Improve streaming of large objects for network server and client
Hello. I follow myself. Tomohito Nakayama (JIRA) wrote: This is a result of long run with modification of ReEncodedInputStream.java not to create buffer for each time. This is not completely correct. ReEncodedInputStream.java.modifiedForLongRun does not create decoded buffer for each time when reEncode was created. However, encocded buffer is created for each time as before. To escape creating encoded buffer for each time, I think DERBY-760 is needed to be done. Best regards. -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Features of the JUnit test execution harness
Hello, I have wanted to rewrite a old canon based test to a JUnit test for a while, but each time I get started I always run into issues that we do not have guidelines for yet. So, I have a few questions I would like some feedback on. I know there are a lot of issues to consider, far more then the one I mention here, but I hope to get a feeling of the general direction we want to move in. 1) Should we support specific ordering of tests (within a single class)? This feature is wanted if a number of tests operate on shared data and each test method can be seen as a step in the test. If the order is mixed up, the intermediate results will not be as expected and all the tests may fail. In general, assuming anything about the execution order of tests is strongly disencouraged. However, since we are testing a database system, we might want to allow for this. This feature can influence the both the size of the test methods and the execution time for the test/suite. 2) Should we support setting up a shared test fixture for a set of tests? This is a common issue with JUnit, and there are mechanisms to handle it. For instance, we could let tests that require this to wrap itself in a TestSetup instance (as described in the JUNit FAQ). Letting DerbyJUnitTest extend TestSetup is another solution, but it might have unwanted side-effects. 3) Many tests just want a database to work on. Other tests want to create their own database due to specific requirements. How do we make this easy for the developer? 4) Should it be possible to run single JUnit test/suite from the command line by simply invoking the main method? Personally, I think this should be possible. This require us to remove the current use of main for running a test in the old test harness, which I believe is doable with a few changes (in the old harness). 5) Is the ultimate goal to end up with a pure JUnit based test harness? If this is the goal, we should design for this and accept some extra work for plugging JUnit tests into the old test harness. 6) Where, and how, do we want to store settings for a test? 7) How is it determined which framework(s) a JUnit test should be run in? (i.e. embedded, client, JCC) If you have other opinions or comments related to JUnit testing, please put them forth :) I hope we are able to get a discussion on all or some of these issues, and that it results in a Wiki page describing JUnit testing for Derby. I created a page here: http://wiki.apache.org/db-derby/DerbyJUnitTesting -- Kristian
Re: [jira] Updated: (DERBY-819) Provide JDBC4 SQLException subclasses support in Embedded driver
Anurag Shekhar (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-819?page=all ] Anurag Shekhar updated DERBY-819: - Attachment: (was: derby-819.diff) and then Anurag Shekhar updated DERBY-819: - Attachment: derby-819.diff I belive it's a good habit to use a new name for the patch file when updating it in Jira, including a version number or a date e.g. derby-819_3.diff or derby-819_20060124.diff. This just reduces the chance that a committer will commit the wrong patch, by accidently using an older version that was already on their system. With this approach there is also no need to remove the old patch, they can be useful sometimes, to compare the aprroaches. Dan.
[jira] Updated: (DERBY-85) NPE when creating a trigger on a table and default schema doesn't exist.
[ http://issues.apache.org/jira/browse/DERBY-85?page=all ] Dyre Tjeldvoll updated DERBY-85: Attachment: (was: derbyall_report.txt) NPE when creating a trigger on a table and default schema doesn't exist. Key: DERBY-85 URL: http://issues.apache.org/jira/browse/DERBY-85 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.0 Reporter: A B Assignee: Dyre Tjeldvoll BACKGROUND: When connecting to a Derby db with a user id and password, the default schema is USER. For example, if I connect with: ij connect 'jdbc:derby:myDB;user=someUser;password=somePwd'; then the default schema is SOMEUSER. PROBLEM: It turns out that if a table t1 exists in a non-default schema and the default schema (in this case, SOMEUSER) doesn't exist yet (because no objects have been created in that schema), then attempts to create a trigger on t1 using its qualified name will lead to a null pointer exception in the Derby engine. REPRO: In ij: -- Create database with default schema SOMEUSER. ij connect 'jdbc:derby:myDB;create=true;user=someUser;password=somePwd'; -- Create table t1 in a non-default schema; in this case, call it ITKO. ij create table itko.t1 (i int); 0 rows inserted/updated/deleted -- Now schema ITKO exists, and T1 exists in schema ITKO, but default schema SOMEUSER does NOT exist, because we haven't created any objects in that schema yet. -- So now we try to create a trigger in the ITKO (i.e. the non-default) schema... ij create trigger trig1 after update on itko.t1 for each row mode db2sql select * from sys.systables; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. A look at the derby.log file shows the stack trace given below. In a word, it looks like the compilation schema field of SYS.SYSTRIGGERS isn't getting set, and so it ends up being null. That causes the NPE in subsequent processing... java.lang.NullPointerException at org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(SYSSTATEMENTSRowFactory.java:200) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(DataDictionaryImpl.java:2890) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(CreateTriggerConstantAction.java:354) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(CreateTriggerConstantAction.java:258) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:366) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1100) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:509) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:467) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:210) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:176) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56) at org.apache.derby.tools.ij.main(ij.java:60) -- 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-85) NPE when creating a trigger on a table and default schema doesn't exist.
[ http://issues.apache.org/jira/browse/DERBY-85?page=all ] Dyre Tjeldvoll updated DERBY-85: Attachment: (was: derby-85.stat) NPE when creating a trigger on a table and default schema doesn't exist. Key: DERBY-85 URL: http://issues.apache.org/jira/browse/DERBY-85 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.0 Reporter: A B Assignee: Dyre Tjeldvoll BACKGROUND: When connecting to a Derby db with a user id and password, the default schema is USER. For example, if I connect with: ij connect 'jdbc:derby:myDB;user=someUser;password=somePwd'; then the default schema is SOMEUSER. PROBLEM: It turns out that if a table t1 exists in a non-default schema and the default schema (in this case, SOMEUSER) doesn't exist yet (because no objects have been created in that schema), then attempts to create a trigger on t1 using its qualified name will lead to a null pointer exception in the Derby engine. REPRO: In ij: -- Create database with default schema SOMEUSER. ij connect 'jdbc:derby:myDB;create=true;user=someUser;password=somePwd'; -- Create table t1 in a non-default schema; in this case, call it ITKO. ij create table itko.t1 (i int); 0 rows inserted/updated/deleted -- Now schema ITKO exists, and T1 exists in schema ITKO, but default schema SOMEUSER does NOT exist, because we haven't created any objects in that schema yet. -- So now we try to create a trigger in the ITKO (i.e. the non-default) schema... ij create trigger trig1 after update on itko.t1 for each row mode db2sql select * from sys.systables; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. A look at the derby.log file shows the stack trace given below. In a word, it looks like the compilation schema field of SYS.SYSTRIGGERS isn't getting set, and so it ends up being null. That causes the NPE in subsequent processing... java.lang.NullPointerException at org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(SYSSTATEMENTSRowFactory.java:200) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(DataDictionaryImpl.java:2890) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(CreateTriggerConstantAction.java:354) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(CreateTriggerConstantAction.java:258) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:366) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1100) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:509) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:467) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:210) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:176) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56) at org.apache.derby.tools.ij.main(ij.java:60) -- 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-85) NPE when creating a trigger on a table and default schema doesn't exist.
[ http://issues.apache.org/jira/browse/DERBY-85?page=all ] Dyre Tjeldvoll updated DERBY-85: Attachment: (was: derby-85.diff) NPE when creating a trigger on a table and default schema doesn't exist. Key: DERBY-85 URL: http://issues.apache.org/jira/browse/DERBY-85 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.0 Reporter: A B Assignee: Dyre Tjeldvoll BACKGROUND: When connecting to a Derby db with a user id and password, the default schema is USER. For example, if I connect with: ij connect 'jdbc:derby:myDB;user=someUser;password=somePwd'; then the default schema is SOMEUSER. PROBLEM: It turns out that if a table t1 exists in a non-default schema and the default schema (in this case, SOMEUSER) doesn't exist yet (because no objects have been created in that schema), then attempts to create a trigger on t1 using its qualified name will lead to a null pointer exception in the Derby engine. REPRO: In ij: -- Create database with default schema SOMEUSER. ij connect 'jdbc:derby:myDB;create=true;user=someUser;password=somePwd'; -- Create table t1 in a non-default schema; in this case, call it ITKO. ij create table itko.t1 (i int); 0 rows inserted/updated/deleted -- Now schema ITKO exists, and T1 exists in schema ITKO, but default schema SOMEUSER does NOT exist, because we haven't created any objects in that schema yet. -- So now we try to create a trigger in the ITKO (i.e. the non-default) schema... ij create trigger trig1 after update on itko.t1 for each row mode db2sql select * from sys.systables; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. A look at the derby.log file shows the stack trace given below. In a word, it looks like the compilation schema field of SYS.SYSTRIGGERS isn't getting set, and so it ends up being null. That causes the NPE in subsequent processing... java.lang.NullPointerException at org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(SYSSTATEMENTSRowFactory.java:200) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(DataDictionaryImpl.java:2890) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(CreateTriggerConstantAction.java:354) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(CreateTriggerConstantAction.java:258) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:366) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1100) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:509) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:467) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:210) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:176) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56) at org.apache.derby.tools.ij.main(ij.java:60) -- 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-85) NPE when creating a trigger on a table and default schema doesn't exist.
[ http://issues.apache.org/jira/browse/DERBY-85?page=all ] Dyre Tjeldvoll updated DERBY-85: Attachment: derby-85.stat derby-85.diff derbyall_report.txt New patch based on the latest trunk. The patch is as before, but the test case is now a simple ij-test, that does not cause any SecurityManager problems. Hopefully this issue can be committed soon, (if I scratch this itch any more I'm going to get gangrene). NPE when creating a trigger on a table and default schema doesn't exist. Key: DERBY-85 URL: http://issues.apache.org/jira/browse/DERBY-85 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.0 Reporter: A B Assignee: Dyre Tjeldvoll Attachments: derby-85.diff, derby-85.stat, derbyall_report.txt BACKGROUND: When connecting to a Derby db with a user id and password, the default schema is USER. For example, if I connect with: ij connect 'jdbc:derby:myDB;user=someUser;password=somePwd'; then the default schema is SOMEUSER. PROBLEM: It turns out that if a table t1 exists in a non-default schema and the default schema (in this case, SOMEUSER) doesn't exist yet (because no objects have been created in that schema), then attempts to create a trigger on t1 using its qualified name will lead to a null pointer exception in the Derby engine. REPRO: In ij: -- Create database with default schema SOMEUSER. ij connect 'jdbc:derby:myDB;create=true;user=someUser;password=somePwd'; -- Create table t1 in a non-default schema; in this case, call it ITKO. ij create table itko.t1 (i int); 0 rows inserted/updated/deleted -- Now schema ITKO exists, and T1 exists in schema ITKO, but default schema SOMEUSER does NOT exist, because we haven't created any objects in that schema yet. -- So now we try to create a trigger in the ITKO (i.e. the non-default) schema... ij create trigger trig1 after update on itko.t1 for each row mode db2sql select * from sys.systables; ERROR XJ001: Java exception: ': java.lang.NullPointerException'. A look at the derby.log file shows the stack trace given below. In a word, it looks like the compilation schema field of SYS.SYSTRIGGERS isn't getting set, and so it ends up being null. That causes the NPE in subsequent processing... java.lang.NullPointerException at org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(SYSSTATEMENTSRowFactory.java:200) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(DataDictionaryImpl.java:2890) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(CreateTriggerConstantAction.java:354) at org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(CreateTriggerConstantAction.java:258) at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:366) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1100) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:509) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:467) at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299) at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433) at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310) at org.apache.derby.impl.tools.ij.Main.go(Main.java:210) at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:176) at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56) at org.apache.derby.tools.ij.main(ij.java:60) -- 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-819) Provide JDBC4 SQLException subclasses support in Embedded driver
[ http://issues.apache.org/jira/browse/DERBY-819?page=comments#action_12363832 ] Daniel John Debrunner commented on DERBY-819: - -1 The use of InternalDriver.activeDriver() to obtain a factory exposes Derby to potential NullPointerExceptions in a shutdown or error on boot situation. I see that you saw one in your testing as you have a comment on that in the shutdown code. Such NPEs will hide the real error from users, making Derby harder to use. I think the solution is to move some of the code from java/engine/org/apache/derby/impl/jdbc/Util.java to be factory methods on InternalDriver. or methods on EmbedConnection or EmbedConnectionChild. I think you will find that most, if not all, cases these static Util methods are called from a JDBC implementation object which has a reference to its InternalDriver factory. Such a change would then remove the need for special code in the shutdown case. Basically this move to a factory based allocation for SQLException obejcts should make the Util class go away. Also the new patch is missing the test code. Provide JDBC4 SQLException subclasses support in Embedded driver Key: DERBY-819 URL: http://issues.apache.org/jira/browse/DERBY-819 Project: Derby Type: Sub-task Components: JDBC Environment: all Reporter: Anurag Shekhar Assignee: Anurag Shekhar Priority: Minor Attachments: derby-819.diff, stat.out -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-840) International messages DatabaseMetaData to GetFileInputStreamAction in org.apache.derby.client.am
[ http://issues.apache.org/jira/browse/DERBY-840?page=all ] V.Narayanan reassigned DERBY-840: - Assign To: V.Narayanan International messages DatabaseMetaData to GetFileInputStreamAction in org.apache.derby.client.am - Key: DERBY-840 URL: http://issues.apache.org/jira/browse/DERBY-840 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering Assignee: V.Narayanan -- 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-862) Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6
Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6 -- Key: DERBY-862 URL: http://issues.apache.org/jira/browse/DERBY-862 Project: Derby Type: Improvement Components: Javadoc Reporter: Rick Hillegas Right now, the derbydocs target produces a blizzard of warnings. In addition, javadoc fails under jdk1.6 because of illegal html in Property.java and ij.jj. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-862) Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-862?page=all ] Rick Hillegas reassigned DERBY-862: --- Assign To: Rick Hillegas Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6 -- Key: DERBY-862 URL: http://issues.apache.org/jira/browse/DERBY-862 Project: Derby Type: Improvement Components: Javadoc Reporter: Rick Hillegas Assignee: Rick Hillegas Right now, the derbydocs target produces a blizzard of warnings. In addition, javadoc fails under jdk1.6 because of illegal html in Property.java and ij.jj. -- 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-862) Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-862?page=all ] Rick Hillegas updated DERBY-862: Attachment: clean_javadoc.output svn_status.bug862 bug862.diff The attached patch (bug862.diff) cleans up the javadoc warnings for the derbydocs target run under jdk1.4. In addition, it allows derbydocs to run successfully on jdk 1.6. The clean 1.4 derbydocs run is attached as clean_javadoc.output. This patch touches a large number of files: the svn_status is attached as svn_status.bug862. The derbydocs run under jdk 1.6 still has some warnings. These are caused by the grammar generator, which creates code that has variables named enum. Javadoc under 1.6 objects that enum is a keyword. Cleaning up this warning is a more delicate task which I'm deferring. This patch also fixes the build under 1.6, which was broken by recent SQLException work. I have successfully run the jdbc4 tests under the 1.6 vm. Even though all the changes are to header comments, I ran derbyall as a sanity check. The tests passed except for NSinSameJVM (under DerbyNetClient), which fails identically in a clean snapshot of the mainline. Clean up the big pile of javadoc warnings for the derbydocs target and make derbydocs run under jdk1.6 -- Key: DERBY-862 URL: http://issues.apache.org/jira/browse/DERBY-862 Project: Derby Type: Improvement Components: Javadoc Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: bug862.diff, clean_javadoc.output, svn_status.bug862 Right now, the derbydocs target produces a blizzard of warnings. In addition, javadoc fails under jdk1.6 because of illegal html in Property.java and ij.jj. -- 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-863) Improve DDMWriter and DDMReader traces
Improve DDMWriter and DDMReader traces -- Key: DERBY-863 URL: http://issues.apache.org/jira/browse/DERBY-863 Project: Derby Type: Improvement Components: Network Server Versions: 10.1.1.0, 10.2.0.0 Reporter: Bryan Pendleton Priority: Minor Improve the DDMWriter and DDMReader traces to better support DRDA protocol bug analysis. Among the ways that these traces could be improved: - Show the related JDBC api calls for improved context, as is done by the client-side tracing - Recognize and display in a human-readable format the DSS protocol envelope, such as the block headers, the protocol flags, the chaining fields, the code point, etc. This is partly done, but the current implementation tends to emit this information only for the first message in a multi-message block - Improve legibility for extremely long messages. In particular, when buffers become very large due to continuations and/or chaining, the buffer can exceed 64K and then the hex offsets in the traces wrap around, which can be quite confusing. A close read of http://wiki.apache.org/db-derby/DssProtocolErrors will provide lots of ideas for ways to improve the traces. Basically, the type of analysis done in this Wiki page should pretty much jump off the screen when reading the traces. This issue arose out of my work on DERBY-125, DERBY-170, DERBY-491 and DERBY-492; you may want to consult those issues for additional background information. -- 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-866) BUILT-IN Derby User Management (DDL) Enhancements
[ http://issues.apache.org/jira/browse/DERBY-866?page=all ] Francois Orsini updated DERBY-866: -- Attachment: Derby_User_Enhancement.html Attached proposal specifications - please post comments in the JIRA itself. BUILT-IN Derby User Management (DDL) Enhancements - Key: DERBY-866 URL: http://issues.apache.org/jira/browse/DERBY-866 Project: Derby Type: Improvement Components: Security Versions: 10.2.0.0 Reporter: Francois Orsini Fix For: 10.2.0.0 Attachments: Derby_User_Enhancement.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption. -- 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-867) Performance issues with large object handling in DDMWriter
Performance issues with large object handling in DDMWriter -- Key: DERBY-867 URL: http://issues.apache.org/jira/browse/DERBY-867 Project: Derby Type: Improvement Components: Network Server, Performance Versions: 10.1.1.0, 10.2.0.0 Reporter: Bryan Pendleton Priority: Minor There are some performance issues related to the way that DDMWriter handles extremely large network messages, such as those that arise in DERBY-125 and DERBY-492. The performance problems involve both memory usage and CPU cycles. Among the problems that could be investigated and improved: 1) The DDMWriter internal byte array grows, but never shrinks (except when the DDMWriter as a whole is collected). This means that there may be some memory wastage when the buffer grows to a large value, then is later used for only small buffers. 2) When the buffer grows, it tends to double in size. When you start gettting to moderately large buffer sizes, this may mean that the buffer over-expands during a growth event, and grows to a larger size than is needed, again leading to memory wastage. 3) I'm not sure what would happen if memory were unavailable when the buffer wanted to grow; I think it would be a very hard error. There may be ways to handle this better, such as: waiting a while to see if memory becomes available; writing previously chained messages out of the buffer to free up space, etc. At the very least, it would be nice if an out-of-memory problem were handled cleanly, for example by terminating this connection but leaving the rest of the Network Server online and available for other users. 4) Perhaps we could eliminate the expansion all together by instead of expanding have a pool of buffers available to all the DDMWriters. If a DDMWriter needs to write more, it picks up a new buffer and returns it to the pool when no longer needed. 5) Large DDM objects which require Layer B segmentation are written as a single object, then later the segmentation is added after the payload data is complete. This processing is handled by endDdm() and finalizeDssLength(). This code currently copies the bytes around in the buffer two extra times: once to insert the extended length bytes at the front of the large DDM object, and a second time to insert the DSS Continuation Headers every 32K bytes. Given the API between DDMWriter and its callers, it may be impossible to totally remove this memory copying, but it does seem like we could reduce from 2 full copies to 1, by combining the insertion of the extended length bytes with the continuation header segmentation. It might also be possible to detect a large object once it spills out from one DSS block into the second block, and hence avoid copying for subsequent blocks, even if those first two blocks do have to be copied once. There may be other opportunities in this part of the code; this issue is just a collection of the ideas that came up while the developers were discussing bugs DERBY-125, DERBY-170, DERBY-491, and DERBY-492. A review of the processing that occurs in those test cases should be performed as part of working on this bug. -- 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-840) International messages DatabaseMetaData to GetFileInputStreamAction in org.apache.derby.client.am
[ http://issues.apache.org/jira/browse/DERBY-840?page=comments#action_12363849 ] David Van Couvering commented on DERBY-840: --- When creating message ids for this subtask, please use the range XN100 - XN150 International messages DatabaseMetaData to GetFileInputStreamAction in org.apache.derby.client.am - Key: DERBY-840 URL: http://issues.apache.org/jira/browse/DERBY-840 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering Assignee: V.Narayanan -- 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-841) Internationalize messages in GetResourceBundleAction to ParameterMetadata in org.apache.derby.client.am
[ http://issues.apache.org/jira/browse/DERBY-841?page=comments#action_12363850 ] David Van Couvering commented on DERBY-841: --- Message ids XN150 - XN200 Internationalize messages in GetResourceBundleAction to ParameterMetadata in org.apache.derby.client.am --- Key: DERBY-841 URL: http://issues.apache.org/jira/browse/DERBY-841 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering -- 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-846) Internationalze NetAgent to NetDatabaseMetadata40 in org.apache.derby.client.net
[ http://issues.apache.org/jira/browse/DERBY-846?page=comments#action_12363856 ] David Van Couvering commented on DERBY-846: --- XN401 - XN450 Internationalze NetAgent to NetDatabaseMetadata40 in org.apache.derby.client.net Key: DERBY-846 URL: http://issues.apache.org/jira/browse/DERBY-846 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering -- 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-845) Internationalize CcsidManager to FdocaSimpleArray in org.apache.derby.client.net
[ http://issues.apache.org/jira/browse/DERBY-845?page=comments#action_12363855 ] David Van Couvering commented on DERBY-845: --- XN351 - XN400 Internationalize CcsidManager to FdocaSimpleArray in org.apache.derby.client.net Key: DERBY-845 URL: http://issues.apache.org/jira/browse/DERBY-845 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering -- 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-847) Internationalize NetIndoubtTransaction to NetSqlca in org.apache.derby.client.net
[ http://issues.apache.org/jira/browse/DERBY-847?page=comments#action_12363857 ] David Van Couvering commented on DERBY-847: --- XN451 - XN500 Internationalize NetIndoubtTransaction to NetSqlca in org.apache.derby.client.net - Key: DERBY-847 URL: http://issues.apache.org/jira/browse/DERBY-847 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering -- 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-844) Internationalize all classes in org.apache.derby.client top-level package
[ http://issues.apache.org/jira/browse/DERBY-844?page=comments#action_12363853 ] David Van Couvering commented on DERBY-844: --- XN301 - XN350 Internationalize all classes in org.apache.derby.client top-level package - Key: DERBY-844 URL: http://issues.apache.org/jira/browse/DERBY-844 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering -- 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-848) Internationalize NetSqldta to OpenSocketAction in org.apache.derby.client.net
[ http://issues.apache.org/jira/browse/DERBY-848?page=comments#action_12363858 ] David Van Couvering commented on DERBY-848: --- XN501 - XN550 Internationalize NetSqldta to OpenSocketAction in org.apache.derby.client.net - Key: DERBY-848 URL: http://issues.apache.org/jira/browse/DERBY-848 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering -- 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-860) Internationalize SqlWarning and its usages
[ http://issues.apache.org/jira/browse/DERBY-860?page=comments#action_12363861 ] David Van Couvering commented on DERBY-860: --- Use message id XN011 - XN049 Internationalize SqlWarning and its usages -- Key: DERBY-860 URL: http://issues.apache.org/jira/browse/DERBY-860 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering Assignee: David Van Couvering -- 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-842) Internationalize messages in PreparedStatement to Section in org.apache.derby.client.am
[ http://issues.apache.org/jira/browse/DERBY-842?page=comments#action_12363851 ] David Van Couvering commented on DERBY-842: --- XN200 - XN250 Internationalize messages in PreparedStatement to Section in org.apache.derby.client.am --- Key: DERBY-842 URL: http://issues.apache.org/jira/browse/DERBY-842 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering -- 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-326) Improve streaming of large objects for network server and client
Tomohito Nakayama (JIRA) wrote: This is a result of long run ... I found that it is a little faster than before patch. However not so much ... This is very surprising, is it not? Are you saying that your conclusion is that there is very little performance benefit to the DERBY-326 change? Or am I misunderstanding your comment? Is the issue that we won't realize the DERBY-326 performance benefits until we also implement DERBY-760? thanks, bryan
Re: Features of the JUnit test execution harness
David W. Van Couvering wrote: Kristian Waagan wrote: 4) Should it be possible to run single JUnit test/suite from the command line by simply invoking the main method? Personally, I think this should be possible. This require us to remove the current use of main for running a test in the old test harness, which I believe is doable with a few changes (in the old harness). I think this is essential for debugging and incremental testing. +1 on this idea. I think it's essential that a single test can be run. I don't think it's essential that it is from test's main method. The harness produces the useful functionality of setting up the correct environment for the test, not sure if that could be duplicated in evey main method for every test. Dan.
Re: documenting DERBY -573, optimizer overrides
Hi Mamta,I've fixed the typos (they were related to bad line breaks in the WordPad version that I originally drafted the topic in).I have a handful of questions about your other comments, though: 4) As for the examples, you can find them in db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/optimizerOverrides.out Please let me know if you need any specific information/examples other than what is in that master file. I do need some help extracting relevant examples from the source that you provided. Which specific ones would be best to use?5)Also, like Satheesh mentioned, we need to let the users know that they can see their optimizer overrides in RUNSTAT output
. If
they don't see their overrides there, it is possible that the user has misspelled "DERBY_PROPERTIES" or didn't put - between DERBY and PROPERTIES, I'm assuming that this update would go in the tuning guide as a separate topic in the "Working with RunTimeStatistics" section. Can you confirm?6)In the end, when you talk about various properties, mention whether they belong afterFROM or after table. Jeff brought up this point in his comments.Please confirm my understanding of where the four properties can be used: joinOrder can be used with a FROM clause; index, constraint, and joinStrategy can be used only within a TableExpression. Is that correct?Thanks,Mamta Satoor [EMAIL PROTECTED] wrote:Hi Eric,Thanks for working on the documentation part of this feature.Couple comments 1)Wherever you have referenced DERBY-PROPERTIES as DERBY PROPERTIES, please put a - between the 2 words. Following are the specific lines that need to be changed. "You can override the default behavior of the Derby query optimizer by including a --DERBY PROPERTIES " "Make sure that you adhere to the correct syntax when using the -- DERBY PROPERTIES" "The following four properties are available for use in a --DERBY PROPERTIES"2)There isa typo "forc e" instead of"force"3)There is another typo "app ropriate " instead of "appropriate "4)As for the examples,
you can
find them in db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/optimizerOverrides.out Please let me know if you need any specific information/examples other than what is in that master file.5)Also, like Satheesh mentioned, we need to let the users know that they can see their optimizer overrides in RUNSTAT output. If they don't see their overrides there, it is possible that the user has misspelled "DERBY_PROPERTIES" or didn't put - between DERBY and PROPERTIES, 6)In the end, when you talk about various properties, mention whether they belong afterFROM or after table. Jeff brought up this point in his comments.Hope this helps, MamtaOn 1/20/06, Eric Radzinski [EMAIL PROTECTED] wrote: Here's my attempt at documenting the optimizer overrides that are introduced by DERBY -573. I'm assuming that this information would be added to the Tuning Guide, probably as a topic within "Performance and optimization" (let me know if anything needs to be added to the Ref Guide or any other book(s)). Overriding the default optimizer behavior You can override the default behavior of the Derby query optimizer by including a --DERBY PROPERTIES clause and an associated property as a comment within an SQL statement. Because optimizer overrides are expressed as comments, they must be included at the end of a line. You can specify optimi
zer
override properties for an entire FROM clause, for tables in the FROM clause, or for both. The syntax for FROM clause properties is:FROM [ -- DERBY-PROPERTIES propertyName = value ] TableExpression [,TableExpression]*The syntax for table optimizer override properties, which must be included at the end of a TableExpression, is:{TableName | ViewName } [ [ AS ] CorrelationName [ (SimpleColumnName [ , SimpleColumnName]* ) ] ] [ -- DERBY-PROPERTIES clause]Note that the space between -- and DERBY-PROPERTIES is
optional. Important: Make sure that you adhere to the correct syntax when using the -- DERBY PROPERTIES clause. Failure to do so will cause the parser to interpret i t as a comment and ignore it.The following four properties are available for use in a --DERBY PROPERTIES clause:constraint The Derby optimizer chooses an index, including the indexes that enforce constraints, as the access path for query execution if the index is useful. If there is more than one useful index, in most cases Derby chooses the index that is most useful. Use the constraint property to override the index that the optimizer selects and force the use of a particular index or force a table scan. To force the use of the index that enforces a primary key or unique constraint, use the constraint property and specify the unqualified name of the constraint. The const
raint
property can be specified only on base tables; it
Re: Features of the JUnit test execution harness
Daniel John Debrunner wrote: David W. Van Couvering wrote: Kristian Waagan wrote: 4) Should it be possible to run single JUnit test/suite from the command line by simply invoking the main method? Personally, I think this should be possible. This require us to remove the current use of main for running a test in the old test harness, which I believe is doable with a few changes (in the old harness). I think this is essential for debugging and incremental testing. +1 on this idea. I think it's essential that a single test can be run. I don't think it's essential that it is from test's main method. The harness produces the useful functionality of setting up the correct environment for the test, not sure if that could be duplicated in evey main method for every test. Good point Dan. Citing Dan: ...harness produces the useful functionality of setting up the correct environment for the test, Can somebody please explain to me what is actually done by the harness? I did have a quick look at the harness code, but I would need to study it a bit more to understand what it actually does. Stating what the harness does when it comes to setting up the environment for tests would be good for the general understanding of the test execution process. -- Kristian Dan.
[jira] Created: (DERBY-868) language specific docs need implemented
language specific docs need implemented --- Key: DERBY-868 URL: http://issues.apache.org/jira/browse/DERBY-868 Project: Derby Type: Improvement Components: Documentation Environment: any Reporter: scott hutinger Derby Docs needs to implement languages other than US English somewhat quickly. Currently a document exists that should be in the build environment. If no action is taken, this seems to indicate that this is not important. I feel this is very important myself, although I only speak english and a very small bit of swahili (university course instead of art) :-) Currently some architecture needs to be in place to allow for multiple additions of languages fairly easily. I would vote for a brute force attack and add the current document today, and figure out the architecture in the future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements
Hi Francois, Some questions on the proposal. I am not sure if database is the right place to do authentication. For example, your proposal still calls for sysadmin to know user passwords (at least initially). Who has the authorization to run ALTER USER? Database keeping user passwords may not be a good idea for many reasons. How to ensure no one is snooping on the protocol to read clear text password that is embedded as part of SQL statement? Can a sysadmin turn on tracing in network server or in the engine to see what password users are picking for themselfs? Why not sure LDAP or some other standard authentication models? It may be good to strengthen Derby authentication, but not necessarily by making Derby manage passwords. You said current user management would work as is in addition to the new proposal. How do you propose to keep these two in sync? Could a user be present in both ways and what happens if their passwords are different? Why not make SYSUSERS a system table now, instead of a VTI? Making it a system catalog has benifits like dictionary management. Satheesh Francois Orsini (JIRA) wrote: BUILT-IN Derby User Management (DDL) Enhancements - Key: DERBY-866 URL: http://issues.apache.org/jira/browse/DERBY-866 Project: Derby Type: Improvement Components: Security Versions: 10.2.0.0 Reporter: Francois Orsini Fix For: 10.2.0.0 Attachments: Derby_User_Enhancement.html Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached to the JIRA). Abstract: This feature aims at improving the way BUILT-IN users are managed in Derby by providing a more intuitive and familiar DDL interface. Currently (in 10.1.2.1), Built-In users can be defined at the system and/or database level. Users created at the system level can be defined via JVM or/and Derby system properties in the derby.properties file. Built-in users created at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property. Defining a user at the system level is very convenient and practical during the development phase (EOD) of an application - However, the user's password is not encrypted and consequently appears in clear in the derby.properties file. Hence, for an application going into production, whether it is embedded or not, it is preferable to create users at the database level where the password is encrypted. There is no real ANSI SQL standard for managing users in SQL but by providing a more intuitive and known interface, it will ease Built-In User management at the database level as well as Derby's adoption.
Re: Tagline for Derby
David W. Van Couvering wrote: I'm not that attached to it. Open Source Database is fine with me. Another option is to just drop the concept of the tag line, I'm not sure why one is needed. I especially believe that the Derby logo should be free of any trademark issues, so there is no requirement to have permission from a third-party to have our own logo. Another issue with a tag line is that it is English centric. Does the logo's tag line need to change in Japan, France etc? Dan.
[jira] Commented: (DERBY-860) Internationalize SqlWarning and its usages
[ http://issues.apache.org/jira/browse/DERBY-860?page=comments#action_12363873 ] David Van Couvering commented on DERBY-860: --- My mistake, SQLWarnings have their own SQL State class, 01, which I will use for all SQLWarning messages Internationalize SqlWarning and its usages -- Key: DERBY-860 URL: http://issues.apache.org/jira/browse/DERBY-860 Project: Derby Type: Sub-task Components: Network Client Reporter: David Van Couvering Assignee: David Van Couvering -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (DERBY-868) language specific docs need implemented
Hi Scott, Thanks for the reminder. This slipped off my radar due to the holidays. My current thinking is to just add a pt_BR subdirectory underneath src, building to a pt_BR subdirectory in out, and we can move the current docs down into an en (or en_US) dir sometime in the future. andrew On Jan 24, 2006, at 11:43 AM, scott hutinger (JIRA) wrote: language specific docs need implemented --- Key: DERBY-868 URL: http://issues.apache.org/jira/browse/DERBY-868 Project: Derby Type: Improvement Components: Documentation Environment: any Reporter: scott hutinger Derby Docs needs to implement languages other than US English somewhat quickly. Currently a document exists that should be in the build environment. If no action is taken, this seems to indicate that this is not important. I feel this is very important myself, although I only speak english and a very small bit of swahili (university course instead of art) :-) Currently some architecture needs to be in place to allow for multiple additions of languages fairly easily. I would vote for a brute force attack and add the current document today, and figure out the architecture in the future. -- 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-868) language specific docs need implemented
[ http://issues.apache.org/jira/browse/DERBY-868?page=all ] scott hutinger updated DERBY-868: - Attachment: pt_BR_build.diff The diff is a brute force method of a build, along with the following information: [EMAIL PROTECTED] trunk]$ ls src adminguide devguide dtd getstart getstart_pt_BR ref tools tuning [EMAIL PROTECTED] trunk]$ ls out adminguide devguide getstart getstart_pt_BR ref tools tuning [EMAIL PROTECTED] trunk]$ This attack is pretty bad, but allows for the build currently at the moment. It's a start to get something going, although it's not a pretty architecture. The only reason I suggest this, is for the following reason: drwxrwxr-x 2 srh srh 4096 Dec 22 14:39 getstart_pt_BR This was from December 22, 2005. It's now been a month :-) language specific docs need implemented --- Key: DERBY-868 URL: http://issues.apache.org/jira/browse/DERBY-868 Project: Derby Type: Improvement Components: Documentation Environment: any Reporter: scott hutinger Attachments: pt_BR_build.diff Derby Docs needs to implement languages other than US English somewhat quickly. Currently a document exists that should be in the build environment. If no action is taken, this seems to indicate that this is not important. I feel this is very important myself, although I only speak english and a very small bit of swahili (university course instead of art) :-) Currently some architecture needs to be in place to allow for multiple additions of languages fairly easily. I would vote for a brute force attack and add the current document today, and figure out the architecture in the future. -- 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-700) Derby does not prevent dual boot of database from different classloaders on Linux
For the generic 2 JVM problem we considered a process id scheme, but gave up when we could not find encough pure java support. There are actually 2 issues: 1) enforce the lock 2) determine if the existing lock is false, ie. the creating process exited without cleaning up the lock file. Until jdk1.4.2 and file locking we suffered from not being able to reliably implement #2. We had 2 options, either assume the lock file was valid and force someone to clean up the lock file or go ahead and boot while logging an error message. Because it was so easy to leave the lock file around we did the error message approach. There was a property users could enable to force a hard error if the lock file was around. So the process id approach needs the following jvm support, if using the traditional lock file approach: 1) some way to uniquely identify a running JVM instance 2) some way to identify if that JVM is running We are looking for a pure java solution. I just checked the java 1.4.2 System interface and no portable solution jumped out at me. But having said that, maybe the dual class loader issue can be treated as a secondary locking issue - an additional lock requested before the existing cross process locking scheme (which does work, pure java across all jvm's = 1.4.2). I think rather than process id we may just need to figure out if 2 class loaders from the SAME jvm are trying to access the file. This may be an easier problem to solve. I think there is some solution to be had using system properties to share information across the class loaders. Maybe something like: o the monitor sets a system property to a UUID which uniquely identifies the JVM it is running in. If the property exists already no work is done. o the monitor also creates a unique id for it's existence in the classloader. o db boot now checks the uuid.dat file in the db directory and sees if the lock is owned by anyone, and if so is it owned by this classloader as identified by the monitor unique id. o Question is how to tell if the existing lock file has been falsely left around by an exited class loader? I assume there is no way to ask the JVM if classloader X exists. Can we just count on monitor code to do the right thing with the lock file in most cases and in the case of JVM failure we won't be looking at that lock file anyway? Bryan Pendleton wrote: Suresh Thalamati wrote: Any ideas to fix this problem ? What if you included some additional information in the lock files, and then changed the locking algorithm so that it considered more than just the presence or absence of the lock file, and whether it could be locked successfully or not. For example, in traditional Unix programming, one would put the process ID of the process which was locking the thing into the file, either in the contents of the file or in the name of the file. That way, another process which came along and discovered the lock file could know not only that some other process was trying to lock the object, but also the process ID of that process. To adapt this algorithm to your case, you would need some sort of unique identifier for each class loader. Then, class loader A in the VM would encounter the lock file, and would see that class loader B in that VM had created the lock file, and would know that the database was locked and a lock error should be returned. In pseudocode: if (file exists I am able to lock the file (the file was written by a different process || the file was written by a different class-loader)) then the database is locked, return lock error Does this work? thanks, bryan
Re: How do I contribute translation?
Daniel John Debrunner wrote: Halley Pacheco de Oliveira wrote: Andrew, I did what you told me to do and the contributed translation is in Derby Getting Started manual translated into Brazilian Portuguese Seems like this is potentially a bug enough contribution to require Halley to have an ICLA on file. Halley, have you submitted an ICLA to the ASF? http://www.apache.org/licenses/#clas Hi, Halley, Have you had a chance to submit an ICLA yet? I don't spot an entry for you yet at http://people.apache.org/~jim/committers.html. Please let us know if you have any questions or if you have already sent the ICLA in. regards, -jean
Re: Features of the JUnit test execution harness
David W. Van Couvering wrote: Hi, Kristian, thanks for your questions. My one overriding thought is we should take this in incremental steps -- do all of these questions need to be answered before we can rewrite a single old canon-based test to a JUnit test? Can some of these questions be deferred? Yes, they can be deferred. I did not intend to say that we should try to fix/implement all issues/features at in one step. My main point of concern, is that it is too hard to write JUnit tests now, because there is so little information available. Just have a look at the number of JUnit tests that have been added to the repository - it sure ain't many! The conversion process, which I understand is fully based on it's my itch initiatives, is also moving along very, very slowly. Kristian Waagan wrote: Hello, I have wanted to rewrite a old canon based test to a JUnit test for a while, but each time I get started I always run into issues that we do not have guidelines for yet. So, I have a few questions I would like some feedback on. I know there are a lot of issues to consider, far more then the one I mention here, but I hope to get a feeling of the general direction we want to move in. 1) Should we support specific ordering of tests (within a single class)? This feature is wanted if a number of tests operate on shared data and each test method can be seen as a step in the test. If the order is mixed up, the intermediate results will not be as expected and all the tests may fail. In general, assuming anything about the execution order of tests is strongly disencouraged. However, since we are testing a database system, we might want to allow for this. This feature can influence the both the size of the test methods and the execution time for the test/suite. I thought if you name your tests correctly (e.g. test_010, test_020, etc.) then they are run in that order. Or is that not the case because all method names on a class are hashed? This is not the case. Tests are not ordered by method names. I do not know the implementation details about ordering when using reflection. I do know that when adding one test at a time in suite(), they are stored in a Vector and thus ordered (and executed in order). But please note that this is not a documented feature of JUnit. Assuming that's not the case, it seems to me that if you have specific ordering requirements, you could use multiple test classes, create a suite of those classes, and use the TestSetup mechanism you describe below to do any setup work prior to running the suite. Might work. In my opinion, the best thing is to write each test to be totally independent, but I am looking for ways to handle tests that are dependent on each other because I suspect that need will arise. 2) Should we support setting up a shared test fixture for a set of tests? This is a common issue with JUnit, and there are mechanisms to handle it. For instance, we could let tests that require this to wrap itself in a TestSetup instance (as described in the JUNit FAQ). Letting DerbyJUnitTest extend TestSetup is another solution, but it might have unwanted side-effects. I think there is a lot of value to having something like this (see above for an example). 3) Many tests just want a database to work on. Other tests want to create their own database due to specific requirements. How do we make this easy for the developer? I think if you have a TestSetup mechanism, then a suite of tests can depend on the fact that a database has been created. Creating a database is pretty darn easy already; are there particular things that are repetetive or error-prone? No. As long as you have the driver name and the connection string (including the correct protocol and database path/name), it is very easy. This information must be passed on to the test setup class when suite() is run, and with the current harness implementation (with respect to JUnit tests) this information is not available then. There are easy workarounds, but they are not written down anywhere... This is actually a matter of question 6. 4) Should it be possible to run single JUnit test/suite from the command line by simply invoking the main method? Personally, I think this should be possible. This require us to remove the current use of main for running a test in the old test harness, which I believe is doable with a few changes (in the old harness). I think this is essential for debugging and incremental testing. +1 on this idea. 5) Is the ultimate goal to end up with a pure JUnit based test harness? If this is the goal, we should design for this and accept some extra work for plugging JUnit tests into the old test harness. I can see us getting there over time, but this is a Very Big Effort. Are there particular things we have to decide upon now in order for this to be possible in the future? I don't know of any, but someone
Re: [jira] Updated: (DERBY-665) Remove backup(File ...) methods
I am looking at committing this patch. Suresh Thalamati (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-665?page=all ] Suresh Thalamati updated DERBY-665: --- Attachment: derby665.diff This patch removes the unused bacpup functions with File as paramteter, TESTS : derbyall test suite passed on Windows XP/JDK142 It would be great if some can review and commit this patch. svn stat: M java\engine\org\apache\derby\impl\db\BasicDatabase.java M java\engine\org\apache\derby\impl\store\access\RAMAccessManager.java M java\engine\org\apache\derby\impl\store\raw\RawStore.java M java\engine\org\apache\derby\iapi\store\access\AccessFactory.java M java\engine\org\apache\derby\iapi\store\raw\RawStoreFactory.java M java\engine\org\apache\derby\database\Database.java Remove backup(File ...) methods --- Key: DERBY-665 URL: http://issues.apache.org/jira/browse/DERBY-665 Project: Derby Type: Improvement Components: Store Versions: 10.2.0.0 Environment: Any Reporter: Øystein Grøvlen Assignee: Suresh Thalamati Priority: Minor Attachments: derby665.diff The code contains backup methods both for specifying the backup directory both as a String and as a File parameter. Only the String versions are currently used. The File versions should be removed to avoid duplication of code etc. Examples of such methods are: BasicDatabase.backup BasicDatabase.backupAndEnableLogArchiveMode RAMAccessManager.backup RAMAccessManager.backupAndEnableLogArchiveMode RawStore.backupAndEnableLogArchiveMode plus corresponding interfaces.
Re: Tagline for Derby
Daniel John Debrunner wrote: David W. Van Couvering wrote: I'm not that attached to it. Open Source Database is fine with me. Another option is to just drop the concept of the tag line, I'm not sure why one is needed. I especially believe that the Derby logo should be free of any trademark issues, so there is no requirement to have permission from a third-party to have our own logo. Another issue with a tag line is that it is English centric. Does the logo's tag line need to change in Japan, France etc? Regarding open source, there's OSI: http://opensource.org/trademarks/ And a google search for open source trademark yielded: http://www.spi-inc.org/news/1998/19981124 http://www.opensource.org/pressreleases/osi-launch.php I prefer no tag line at all. -jean
Re: [jira] Created: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements
Hi Satheesh, Thanks for the initial feedback. Please find some answers enclosed below.On 1/24/06, Satheesh Bandaram [EMAIL PROTECTED] wrote: Hi Francois, Some questions on the proposal. I am not sure if database is the right place to do authentication. For example, your proposal still calls for sysadmin to know user passwords (at least initially). Who has the authorization to run ALTER USER? Database keeping user passwords may not be a good idea for many reasons. How to ensure no one is snooping on the protocol to read clear text password that is embedded as part of SQL statement? Can a sysadmin turn on tracing in network server or in the engine to see what password users are picking for themselfs? This proposal does not discuss how a sysadmin (dba) type of user is defined, as obviously we don't have System privileges support as well as roles (yet) - specs for these are incoming . Here it how it would work in the meantime: - For a database to be created and assuming 'sqlStandard' authorization mode is enabled and we have support for certain system privileges such as the CREATE DATABASE one, a grantee, would be allowed to create a database and assign a 'dba' (or 'admin') role to a new user in the just created database. Again, this is assuming there is support for Roles and System privileges but features can be done in phases as you know. Derby supports authentication at the System and Database level - Derby databases can defined their own security restrictions/settings independently of the system level - as you know, derby databases can be moved around independently of the derby system realm - there is no 'master' system tables (i.e. mo master DB) in Derby and it was done so that databases could be detached, accessed without having to be defined in some sort of master database containing metadata to access user databases - this is a very powerful and flexible model but it has a cost... An application should be able to have a database which itself is either being shipped to a user or distributed with user credentials and authorization (privileges) metadata being defined as part of the database. In order to run ALTER USER, the individual would need to have the CREATE USER privilege (we don't have that right now). Derby has a Built-In authentication provider (scheme) which allows Derby to run its own user authentication realm - You can't always assume LDAP, many applications don't use or have access to LDAP and are not always connected, yet they still want to be able to protect access to a DB. As far as snooping the clear text password on the network, we do have the same issue with the current scheme of calling SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY across a networked JDBC connectoin - in fact, there is a similar issue with LDAP authentication, some people use SSL in order to solve this but in our case, DRDA also has mechanisms for resetting a user password over a network and in a secure way - hence we could either piggyback on existing and similar DRDA mechanisms or have the admin use an SSL-enabled (or IPSEC) derby connection for such admin commands... Why not sure LDAP or some other standard authentication models? It may be good to strengthen Derby authentication, but not necessarily by making Derby manage passwords. Derby Built-In authentication is important - again, not everyone is using LDAP, especially with small departmental level type of databases as well as embedded / disconnected ones. Derby already manages user passwords at the database level when a user is defined in a database. Derby stores user password in a secure fashion (they cannot be decrypted easily and if at all - they are single-hashed) - the transport of passwords across a network is defined and handled in the DRDA specifications which themselves are part of a standard - encrypting a password in a DB is not related to how a password is transported across the network - they are both important to address and we have the means. You said current user management would work as is in addition to the new proposal. How do you propose to keep these two in sync? Could a user be present in both ways and what happens if their passwords are different? No - this phase I proposal is to enhance the DDL support for managing Built-In Derby users in a database. We would still be using database properties to store the actual user/password combination as presently. You cannot have 2 users of the same name in a derby database - the only way to achieve something close would be to define a user at the system level and the same at the database level, and this last one would take precedence - also, in derby it is possible to set a a database property to only consider database properties and not the system ones, meaning that even if some users would be defined at the system level, they would not be granted access to the database which has authentication turned ON. Why not make SYSUSERS a system table now, instead of a VTI? Making it a system
[jira] Commented: (DERBY-400) Network client message strings not internationalized
[ http://issues.apache.org/jira/browse/DERBY-400?page=comments#action_12363876 ] David Van Couvering commented on DERBY-400: --- For those of you working on internationalizing the network client messages, you need to take care when choosing a SQL State for a new client messages (e.g. one that is not duplicated or closely duplicated in the engine's messages.properties file). In most cases you can use XN which means a vendor-specific SQL State. However, if the error matches a predefined SQL State (either a class, subclass, or entire state) in the SQL2003 spec, you should use that. For example, an exception that affects the connection should use the prefix 08. A connection failure must be exactly 08006, connection does not exist 08003. The SQL State definitions can be found in section 23.1 of the SQL 2003 spec. Somebody correct me if I'm missing something, but there is also an entire set of SQLStates required by DRDA which (in general) are currently not being set by the client code. These SQLStates are defined in Chapter 8 (Volume 1) of the DRDA spec. We will need to set the SQL State appropriately based on this spec in the org/apache/derby/client/net classes. I know this code is hard to parse through if you're new to DRDA, so please do send out email if you need help/guidance. Note that doing this as correctly as possible is important for portability and also for future JDBC4 work where you create the appropriate SQLException subclass based on the SQL State... Thanks, David Network client message strings not internationalized Key: DERBY-400 URL: http://issues.apache.org/jira/browse/DERBY-400 Project: Derby Type: Improvement Components: Network Client Versions: 10.1.1.0 Reporter: David Van Couvering Assignee: David Van Couvering Priority: Minor Attachments: DERBY-400.diff In investigating DERBY-254, I discovered that all SQLExceptions are thrown with hardcoded English error messages. This needs to be modified to use message string resource bundles similar to the embedded code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-838) Create internationalization framework for network client
[ http://issues.apache.org/jira/browse/DERBY-838?page=all ] David Van Couvering closed DERBY-838: - Assign To: David Van Couvering Create internationalization framework for network client Key: DERBY-838 URL: http://issues.apache.org/jira/browse/DERBY-838 Project: Derby Type: Sub-task Reporter: David Van Couvering Assignee: David Van Couvering This sub-task is to establish the internationalization framework for the network client. Once this is established multiple individuals could conceivably internationalize messages in parallel. I will be creating separate subtasks for groups of classes to have their messages internationalized, and will make them Newcomer tasks. -- 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-400) Network client message strings not internationalized
[ http://issues.apache.org/jira/browse/DERBY-400?page=comments#action_12363877 ] David Van Couvering commented on DERBY-400: --- By the way, the SQL 2003 spec states that there is a specific SQL State class for Remote Database Access, which is HZ. It refers to table 33, SQLState Class Codes for RDA, which is a zen moment, because the table is empty. Can anyone explain the relationship between the HZ class for RDA and the SQL States defined in the DRDA spec, which do not make any reference or use of the HZ class? Thanks, David Network client message strings not internationalized Key: DERBY-400 URL: http://issues.apache.org/jira/browse/DERBY-400 Project: Derby Type: Improvement Components: Network Client Versions: 10.1.1.0 Reporter: David Van Couvering Assignee: David Van Couvering Priority: Minor Attachments: DERBY-400.diff In investigating DERBY-254, I discovered that all SQLExceptions are thrown with hardcoded English error messages. This needs to be modified to use message string resource bundles similar to the embedded code. -- 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-864) Network Client should not assume length of Layer B segment is 32K
[
http://issues.apache.org/jira/browse/DERBY-864?page=comments#action_12363878 ]
Knut Anders Hatlen commented on DERBY-864:
--
David's question: Do we have version detection at that level of granularity in
the protocol?
The client driver has a class ProductLevel with methods
- boolean greaterThanOrEqualTo(int versionLevel, int releaseLevel, int
modificationLevel)
- boolean lessThan(int versionLevel, int releaseLevel, int modificationLevel)
which let you detect the version of the server.
In Reply.java, we could have something like this:
if
(netAgent_.netConnection_.databaseMetaData_.productLevel_.greaterThanOrEqualTo(10,
2, 0)) {
// new behaviour
} else {
// old behaviour
}
Network Client should not assume length of Layer B segment is 32K
-
Key: DERBY-864
URL: http://issues.apache.org/jira/browse/DERBY-864
Project: Derby
Type: Improvement
Components: Network Client
Versions: 10.2.0.0
Reporter: Bryan Pendleton
Priority: Minor
The Network Client, when processing a Layer-B Segmented DSS block, currently
uses the following code:
[java/client/org/apache/derby/client/net/Reply.java]:
if ((continueHeaderLength 0x8000) == 0x8000) {
// the last dss header is again continued
continueHeaderLength = 32767;
dssIsContinued_ = true;
} else {
// the last dss header was not contiued so update
continue state flag
dssIsContinued_ = false;
}
According to my reading of the DRDA spec, this code is making an assumption
which is not truly justified by the DSS protocol, namely that if a segment is
continued, then its length must be 32767. In practice, the Network Server
does implement such a behavior, but I think it would be safer for the client
to not make such an assumption, and rather it should get the *actual* length
from the contents of the DSS continuation header.
However, there is a slight complexity here. Prior to the fix for DERBY-125,
the Network Server did not set the length value of the DSS Continuation
Header. Instead of sending a DSS Continuation Header of 0x, it sent a
value of 0x8000.
Therefore, when changing the client, care must be taken to not break
compatibility between a new client and an old server. I can think of two ways
to do this:
- if the client sees that the the length is 0, it could treat a length of 0
as meaning a length of 32767, or
- if the client can detect the version of the server, and can see that the
server is a version prior to DERBY-125, it could assume that the length is
always 32767, as it does now.
See http://wiki.apache.org/db-derby/DssProtocolErrors for more information on
DSS continuations, and see DERBY-125 for some other background information
on 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-868) language specific docs need implemented
[ http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12363879 ] Andrew McIntyre commented on DERBY-868: --- With revision 372013, I've checked in beginning build infrastructure for pt_BR. Just put the translated 'getstart' directory of files into the pt_BR directory, and run 'ant pt_BR' at the top. I'd like to keep the details of the build for the translations with the translated files. At some point in the future, the English manuals should be refactored similarly. language specific docs need implemented --- Key: DERBY-868 URL: http://issues.apache.org/jira/browse/DERBY-868 Project: Derby Type: Improvement Components: Documentation Environment: any Reporter: scott hutinger Attachments: pt_BR_build.diff Derby Docs needs to implement languages other than US English somewhat quickly. Currently a document exists that should be in the build environment. If no action is taken, this seems to indicate that this is not important. I feel this is very important myself, although I only speak english and a very small bit of swahili (university course instead of art) :-) Currently some architecture needs to be in place to allow for multiple additions of languages fairly easily. I would vote for a brute force attack and add the current document today, and figure out the architecture in the future. -- 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-868) language specific docs need implemented
[ http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12363880 ] Andrew McIntyre commented on DERBY-868: --- Note also that the current translation of the Getting Started manual referred to in the description cannot yet be committed, as the contributor does not have an ICLA on file. language specific docs need implemented --- Key: DERBY-868 URL: http://issues.apache.org/jira/browse/DERBY-868 Project: Derby Type: Improvement Components: Documentation Environment: any Reporter: scott hutinger Attachments: pt_BR_build.diff Derby Docs needs to implement languages other than US English somewhat quickly. Currently a document exists that should be in the build environment. If no action is taken, this seems to indicate that this is not important. I feel this is very important myself, although I only speak english and a very small bit of swahili (university course instead of art) :-) Currently some architecture needs to be in place to allow for multiple additions of languages fairly easily. I would vote for a brute force attack and add the current document today, and figure out the architecture in the future. -- 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-866) BUILT-IN Derby User Management (DDL) Enhancements
[ http://issues.apache.org/jira/browse/DERBY-866?page=comments#action_12363881 ] Francois Orsini commented on DERBY-866: --- Hi Satheesh, Thanks for the initial feedback. Please find some answers enclosed below. On 1/24/06, Satheesh Bandaram wrote: Hi Francois, Some questions on the proposal. 1. I am not sure if database is the right place to do authentication. For example, your proposal still calls for sysadmin to know user passwords (at least initially). Who has the authorization to run ALTER USER? Database keeping user passwords may not be a good idea for many reasons. How to ensure no one is snooping on the protocol to read clear text password that is embedded as part of SQL statement? Can a sysadmin turn on tracing in network server or in the engine to see what password users are picking for themselfs? This proposal does not discuss how a sysadmin (dba) type of user is defined, as obviously we don't have System privileges support as well as roles (yet) - specs for these are incoming . Here it how it would work in the meantime: - For a database to be created and assuming 'sqlStandard' authorization mode is enabled and we have support for certain system privileges such as the CREATE DATABASE one, a grantee, would be allowed to create a database and assign a 'dba' (or 'admin') role to a new user in the just created database. Again, this is assuming there is support for Roles and System privileges but features can be done in phases as you know. Derby supports authentication at the System and Database level - Derby databases can defined their own security restrictions/settings independently of the system level - as you know, derby databases can be moved around independently of the derby system realm - there is no 'master' system tables (i.e. mo master DB) in Derby and it was done so that databases could be detached, accessed without having to be defined in some sort of master database containing metadata to access user databases - this is a very powerful and flexible model but it has a cost... An application should be able to have a database which itself is either being shipped to a user or distributed with user credentials and authorization (privileges) metadata being defined as part of the database. In order to run ALTER USER, the individual would need to have the CREATE USER privilege (we don't have that right now). Derby has a Built-In authentication provider (scheme) which allows Derby to run its own user authentication realm - You can't always assume LDAP, many applications don't use or have access to LDAP and are not always connected, yet they still want to be able to protect access to a DB. As far as snooping the clear text password on the network, we do have the same issue with the current scheme of calling SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY across a networked JDBC connectoin - in fact, there is a similar issue with LDAP authentication, some people use SSL in order to solve this but in our case, DRDA also has mechanisms for resetting a user password over a network and in a secure way - hence we could either piggyback on existing and similar DRDA mechanisms or have the admin use an SSL-enabled (or IPSEC) derby connection for such admin commands... 1. Why not sure LDAP or some other standard authentication models? It may be good to strengthen Derby authentication, but not necessarily by making Derby manage passwords. Derby Built-In authentication is important - again, not everyone is using LDAP, especially with small departmental level type of databases as well as embedded / disconnected ones. Derby already manages user passwords at the database level when a user is defined in a database. Derby stores user password in a secure fashion (they cannot be decrypted easily and if at all - they are single-hashed) - the transport of passwords across a network is defined and handled in the DRDA specifications which themselves are part of a standard - encrypting a password in a DB is not related to how a password is transported across the network - they are both important to address and we have the means. 1. You said current user management would work as is in addition to the new proposal. How do you propose to keep these two in sync? Could a user be present in both ways and what happens if their passwords are different? No - this phase I proposal is to enhance the DDL support for managing Built-In Derby users in a database. We would still be using database properties to store the actual user/password combination as presently. You cannot have 2 users of the same name in a derby database - the only way to achieve something close would be to define a user at the system level and the same at the database level, and this last one would take precedence - also, in derby it is possible to set a a database property to only consider database properties and not the system ones, meaning
Re: [jira] Created: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements
Francois Orsini wrote: Hi Satheesh, Thanks for the initial feedback. Please find some answers enclosed below. [snip] 1. Why not sure LDAP or some other standard authentication models? It may be good to strengthen Derby authentication, but not necessarily by making Derby manage passwords. Derby Built-In authentication is important - again, not everyone is using LDAP, especially with small departmental level type of databases as well as embedded / disconnected ones. +1. I like us allowing LDAP, but I would be very uncomfortable making it a requirement for user managment. begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
Re: Tagline for Derby
Apache 2.0 is registered at OSI under: http://www.opensource.org/licenses/apache2.0.php For what it's worth, --francoisOn 1/24/06, Jean T. Anderson [EMAIL PROTECTED] wrote: Daniel John Debrunner wrote: David W. Van Couvering wrote:I'm not that attached to it.Open Source Database is fine with me. Another option is to just drop the concept of the tag line, I'm not sure why one is needed. I especially believe that the Derby logo should be free of any trademark issues, so there is no requirement to have permission from a third-party to have our own logo. Another issue with a tag line is that it is English centric. Does the logo's tag line need to change in Japan, France etc?Regarding open source, there's OSI: http://opensource.org/trademarks/And a google search for open source trademark yielded:http://www.spi-inc.org/news/1998/19981124 http://www.opensource.org/pressreleases/osi-launch.phpI prefer no tag line at all.-jean
Re: Tagline for Derby
Francois Orsini wrote: Apache 2.0 is registered at OSI under: http://www.opensource.org/licenses/apache2.0.php For what it's worth, For convenience, the OSI make copies of approved licenses available and Apache 2.0 is an approved license (see http://www.opensource.org/licenses/index.php). --I think that's what you're seeing. -jean --francois On 1/24/06, *Jean T. Anderson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Daniel John Debrunner wrote: David W. Van Couvering wrote: I'm not that attached to it. Open Source Database is fine with me. Another option is to just drop the concept of the tag line, I'm not sure why one is needed. I especially believe that the Derby logo should be free of any trademark issues, so there is no requirement to have permission from a third-party to have our own logo. Another issue with a tag line is that it is English centric. Does the logo's tag line need to change in Japan, France etc? Regarding open source, there's OSI: http://opensource.org/trademarks/ And a google search for open source trademark yielded: http://www.spi-inc.org/news/1998/19981124 http://www.opensource.org/pressreleases/osi-launch.php I prefer no tag line at all. -jean
Re: Features of the JUnit test execution harness
On 1/24/06, Kristian Waagan [EMAIL PROTECTED] wrote: David W. Van Couvering wrote: Hi, Kristian, thanks for your questions.My one overriding thought is we should take this in incremental steps -- do all of these questions need to be answered before we can rewrite a single old canon-based test to a JUnit test?Can some of these questions be deferred?Yes, they can be deferred. I did not intend to say that we should try tofix/implement all issues/features at in one step.My main point of concern, is that it is too hard to write JUnit tests now, because there is so little information available. Just have a lookat the number of JUnit tests that have been added to the repository - itsure ain't many! The conversion process, which I understand is fully based on it's my itch initiatives, is also moving along very, very slowly. +1 - I have now written some derby jUnit tests myself and I agree that it may not be that obvious from the beginning (different paradigm from canon-based tests) - I used jUnit before so it did help. I'm currently scratching a few itches but I'd be glad to post some instructions unless some itch-scratching idle volunteer want to take into that heroic task ;-) - jUnit aims at making unit testing easier and more effective therefore we just need to make the Derby jUnit adoption easier and more effective ;-)
Re: Tagline for Derby
Jean T. Anderson wrote: Daniel John Debrunner wrote: David W. Van Couvering wrote: I'm not that attached to it. Open Source Database is fine with me. Another option is to just drop the concept of the tag line, I'm not sure why one is needed. I especially believe that the Derby logo should be free of any trademark issues, so there is no requirement to have permission from a third-party to have our own logo. Another issue with a tag line is that it is English centric. Does the logo's tag line need to change in Japan, France etc? Regarding open source, there's OSI: http://opensource.org/trademarks/ I did find out that Open Source is not trademarked by anyone in the US, it's too generic according to this. http://www.opensource.org/pressreleases/certified-open-source.php (of course that's US Law, Open Source might be a trademark elsewhere). I had thought that it was a trademark of the OSI. Dan.
Re: Features of the JUnit test execution harness
Francois Orsini wrote: On 1/24/06, *Kristian Waagan* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: David W. Van Couvering wrote: Hi, Kristian, thanks for your questions. My one overriding thought is we should take this in incremental steps -- do all of these questions need to be answered before we can rewrite a single old canon-based test to a JUnit test? Can some of these questions be deferred? Yes, they can be deferred. I did not intend to say that we should try to fix/implement all issues/features at in one step. My main point of concern, is that it is too hard to write JUnit tests now, because there is so little information available. Just have a look at the number of JUnit tests that have been added to the repository - it sure ain't many! The conversion process, which I understand is fully based on it's my itch initiatives, is also moving along very, very slowly. +1 - I have now written some derby jUnit tests myself and I agree that it may not be that obvious from the beginning (different paradigm from canon-based tests) - I used jUnit before so it did help. I'm currently scratching a few itches but I'd be glad to post some instructions unless some itch-scratching idle volunteer want to take into that heroic task ;-) - jUnit aims at making unit testing easier and more effective therefore we just need to make the Derby jUnit adoption easier and more effective ;-) I would like my concerns to be cleared up before too many tests use the current Junit facility. The rampant catching and ignoring of SQLExceptions is not good. Dan.
Re: Tagline for Derby
Right this is where I got it from - I mentioned this as Derby is an Apache (2.0) based project - Hence, am curious as to what the trademark issue would be really for a tagline such Open Source Database (the one you mentioned) - is a separate license needed or not?On 1/24/06, Jean T. Anderson [EMAIL PROTECTED] wrote:Francois Orsini wrote: Apache 2.0 is registered at OSI under: http://www.opensource.org/licenses/apache2.0.php For what it's worth,For convenience, the OSI make copies of approved licenses available and Apache 2.0 is an approved license (seehttp://www.opensource.org/licenses/index.php). --I think that's whatyou're seeing.-jean --francois On 1/24/06, *Jean T. Anderson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Daniel John Debrunner wrote: David W. Van Couvering wrote:I'm not that attached to it.Open Source Database is fine with me. Another option is to just drop the concept of the tag line, I'm not sure why one is needed. I especially believe that the Derby logo should be free of any trademark issues, so there is no requirement to have permission from a third-party to have our own logo. Another issue with a tag line is that it is English centric. Does the logo's tag line need to change in Japan, France etc? Regarding open source, there's OSI: http://opensource.org/trademarks/ And a google search for open source trademark yielded: http://www.spi-inc.org/news/1998/19981124 http://www.opensource.org/pressreleases/osi-launch.php I prefer no tag line at all. -jean
[jira] Created: (DERBY-870) Update documentation on setting up LDAP user authentication.
Update documentation on setting up LDAP user authentication. - Key: DERBY-870 URL: http://issues.apache.org/jira/browse/DERBY-870 Project: Derby Type: Improvement Components: Documentation Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.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 Reporter: Sunitha Kambhampati Priority: Minor http://db.apache.org/derby/docs/dev/devguide/rdevcsecure608.html This talks about needing jndi.jar , ldap.jar and providerUtil.jar. I think this is not true anymore with the latest 1.4.2 vms atleast, and should be updated. It seems like with 1.4.2 etc, all these classes are in rt.jar. Need to verify and the doc needs to be updated. -- 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-870) Update documentation on setting up LDAP user authentication.
[ http://issues.apache.org/jira/browse/DERBY-870?page=comments#action_12363887 ] Francois Orsini commented on DERBY-870: --- Correct - Minor nit is that I think they started to be included at part of JRE 1.3.1... Update documentation on setting up LDAP user authentication. Key: DERBY-870 URL: http://issues.apache.org/jira/browse/DERBY-870 Project: Derby Type: Improvement Components: Documentation Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.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 Reporter: Sunitha Kambhampati Priority: Minor http://db.apache.org/derby/docs/dev/devguide/rdevcsecure608.html This talks about needing jndi.jar , ldap.jar and providerUtil.jar. I think this is not true anymore with the latest 1.4.2 vms atleast, and should be updated. It seems like with 1.4.2 etc, all these classes are in rt.jar. Need to verify and the doc needs to be updated. -- 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: conflict between Derby API and JDBC 4.0
Three months ago, we shelved this topic, promising to return to it later. I would like to reach consensus on this problem now. In a nutshell: JDBC4 introduces new methods whose signatures contain generics. Because of this, DataSource implementations can't satisfy both the JDBC3 and JDBC4 contracts. I would like to restart the discussion by proposing the following: 1) Derby's public API will contain two sets of DataSource implementations, one which satisfies the JDBC3 contract and one which satisfies JDBC4. 2) The documented, approved way to obtain DataSources will be to call factory methods on EmbeddedDriver and ClientDriver. These factory methods will hand back either JDBC3 or JDBC4 DataSources depending on the vm. 3) JDBC4 DataSources will have private constructors. 4) In contrast, the JDBC3 DataSources will continue to expose public constructors. Existing Derby applications won't have to change, provided that they are run on jdk1.3, jdk1.4, or jdk1.5. 5) However, we will raise exceptions if applications try to construct JDBC3 DataSources while running on jdk1.6. The exceptions will tell the customer to call the appropriate factory methods. Note that this describes the behavior of Derby 10.2. We make no promises about what will happen if the customer tries to run earlier versions of Derby on jdk1.6. Under those combinations, the customer will see runtime exceptions when trying to invoke JDBC4-specific methods. Please let me know what you think. Thanks, -Rick Rick Hillegas wrote: Thanks, Dan. For the record, I think that this affects org.apache.derby.jdbc as follows: - ClientConnectionPoolDataSource (implements javax.sql.ConnectionPoolDataSource, which extends javax.sql.CommonDataSource, which mentions QueryObjectGenerator, which is new to 1.6 and mentions generics). - ClientDataSource (implements javax.sql.DataSource, which mentions generics) - ClientXADataSource (same as ClientDataSource) - EmbeddedConnectionPoolDataSource (same as ClientDataSource) - EmbeddedDataSource (same as ClientDataSource) - EmbeddedSimpleDataSource (same as ClientDataSource) - EmbeddedXADataSource (same as ClientDataSource) Regards, -Rick Daniel John Debrunner wrote: Rick Hillegas wrote: I would like advice on how to handle the conflict between the public Derby API and JDBC 4.0. This issue was raised by Dan in his comments on bug 587. A) Does this issue block the submission of the 587 fix? I don't think so. But I think we would want to resolve the issue before release a Derby version that contained this code. Though potentially resolution could wait until JDBC 4.0 was official. B) How do we want to handle this conflict in 10.2? The problem is that some javax.sql interfaces are incompatible between jdk1.4 and jdk1.6. A class implementing one of these interfaces can't run on both the 1.4 and 1.6 vms. This is a showstopper for Derby because i) our public API contains classes which implement these incompatible interfaces and ii) we ship a single jar which we expect will run on all supported vms. The comments on bug 587 suggest some solutions: 1) Some, as yet not understood, classloader trick. 2) Abandon requirement (ii) and release separate Derby deployments for 1.4 and 1.6. I would say 2) is out, it seems overkill for a single class to drive a switch to multiple/different versions for different environments. 3) Change our public API. I would appreciate some discussion of this serious problem. Beyond that, I will think more :-) Dan.
[jira] Created: (DERBY-871) remote host support in test harness needs more work because of security manager changes
remote host support in test harness needs more work because of security manager changes --- Key: DERBY-871 URL: http://issues.apache.org/jira/browse/DERBY-871 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Myrna van Lunteren Assigned to: Myrna van Lunteren Priority: Minor With the changes to have security manager run for tests with useprocess=false, the remote host support in the test harness no l onger works. permissions need to be passed in derby_test.policy for the client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tagline for Derby
Francois Orsini wrote: Right this is where I got it from - I mentioned this as Derby is an Apache (2.0) based project - Hence, am curious as to what the trademark issue would be really for a tagline such Open Source Database (the one you mentioned) - is a separate license needed or not? My concern was using the words open source, but other email from Dan indicates that this shouldn't be an issue. But I seriously wonder if we want to have a tagline that could require explanation -- and translation, as Dan also pointed out. Apache Derby doesn't require any translation. Open Source Database is definitely English-centric. -jean On 1/24/06, *Jean T. Anderson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Francois Orsini wrote: Apache 2.0 is registered at OSI under: http://www.opensource.org/licenses/apache2.0.php For what it's worth, For convenience, the OSI make copies of approved licenses available and Apache 2.0 is an approved license (see http://www.opensource.org/licenses/index.php). --I think that's what you're seeing. -jean --francois On 1/24/06, *Jean T. Anderson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Daniel John Debrunner wrote: David W. Van Couvering wrote: I'm not that attached to it. Open Source Database is fine with me. Another option is to just drop the concept of the tag line, I'm not sure why one is needed. I especially believe that the Derby logo should be free of any trademark issues, so there is no requirement to have permission from a third-party to have our own logo. Another issue with a tag line is that it is English centric. Does the logo's tag line need to change in Japan, France etc? Regarding open source, there's OSI: http://opensource.org/trademarks/ And a google search for open source trademark yielded: http://www.spi-inc.org/news/1998/19981124 http://www.opensource.org/pressreleases/osi-launch.php I prefer no tag line at all. -jean
[jira] Commented: (DERBY-868) language specific docs need implemented
[ http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12363891 ] scott hutinger commented on DERBY-868: -- Jean noted the problem with the ICLA, I have sent email to Halley Pacheco de Oliveira and Jean T. Anderson at the same time noting the ICLA problem. I asked Jean if any nice method to include many languages might exist within the document web pages. language specific docs need implemented --- Key: DERBY-868 URL: http://issues.apache.org/jira/browse/DERBY-868 Project: Derby Type: Improvement Components: Documentation Environment: any Reporter: scott hutinger Attachments: pt_BR_build.diff Derby Docs needs to implement languages other than US English somewhat quickly. Currently a document exists that should be in the build environment. If no action is taken, this seems to indicate that this is not important. I feel this is very important myself, although I only speak english and a very small bit of swahili (university course instead of art) :-) Currently some architecture needs to be in place to allow for multiple additions of languages fairly easily. I would vote for a brute force attack and add the current document today, and figure out the architecture in the future. -- 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-868) language specific docs need implemented
[ http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12363892 ] Jean T. Anderson commented on DERBY-868: I'm not sure I understand this: I asked Jean if any nice method to include many languages might exist within the document web pages. Are you asking about displaying the translated doc from the web site? Adding links for translated docs to http://db.apache.org/derby/manuals/ shouldn't be any issue at all -- easy to do. Or are you asking something else? language specific docs need implemented --- Key: DERBY-868 URL: http://issues.apache.org/jira/browse/DERBY-868 Project: Derby Type: Improvement Components: Documentation Environment: any Reporter: scott hutinger Attachments: pt_BR_build.diff Derby Docs needs to implement languages other than US English somewhat quickly. Currently a document exists that should be in the build environment. If no action is taken, this seems to indicate that this is not important. I feel this is very important myself, although I only speak english and a very small bit of swahili (university course instead of art) :-) Currently some architecture needs to be in place to allow for multiple additions of languages fairly easily. I would vote for a brute force attack and add the current document today, and figure out the architecture in the future. -- 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-398) Exclude tests for J2ME/CDC/Foundation platform
[ http://issues.apache.org/jira/browse/DERBY-398?page=comments#action_12363896 ] Kathey Marsden commented on DERBY-398: -- Thanks Deepa for bringing these tests into J2ME I think that maybe for ProcedureTest, instead of having a reduced copy ProcedureTest169, we should perhaps have a SimpleProcedureTest and then have ProcedureTest extend that to eliminate the duplicate code. Exclude tests for J2ME/CDC/Foundation platform -- Key: DERBY-398 URL: http://issues.apache.org/jira/browse/DERBY-398 Project: Derby Type: Sub-task Components: Test Reporter: Deepa Remesh Assignee: Deepa Remesh Attachments: derby-398_2.diff, derby-398_2.status, derbyall_report_2.txt, jdbcapi_lang_patch.diff, jdbcapi_lang_patch.status, jdk14_tests_3.diff, jdk14_tests_3.status, nullSQLText_patch.diff, nullSQLText_patch.status, parameterMapping.diff, parameterMapping.status, readme_patch.diff, store_patch.diff, store_patch.status, wisc_rename_patch.diff, wisc_rename_patch.status, wisconsin_patch.diff, wisconsin_patch.status Exclude tests which use DriverManager, Driver or BigDecimal classes which are not in J2ME or JSR169. Ensure that derbyall can be run successfully in J2ME/CDC/Foundation platform using the JDBC Optional Package for CDC/Foundation Profile (JSR169). -- 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-868) language specific docs need implemented
[ http://issues.apache.org/jira/browse/DERBY-868?page=comments#action_12363897 ] Andrew McIntyre commented on DERBY-868: --- Also note that once the translated files are committed and hooked into the build, the new translated manual will be sync'd over to http://db.apache.org/derby/docs/dev/ with the rest of the nightly doc build. language specific docs need implemented --- Key: DERBY-868 URL: http://issues.apache.org/jira/browse/DERBY-868 Project: Derby Type: Improvement Components: Documentation Environment: any Reporter: scott hutinger Attachments: pt_BR_build.diff Derby Docs needs to implement languages other than US English somewhat quickly. Currently a document exists that should be in the build environment. If no action is taken, this seems to indicate that this is not important. I feel this is very important myself, although I only speak english and a very small bit of swahili (university course instead of art) :-) Currently some architecture needs to be in place to allow for multiple additions of languages fairly easily. I would vote for a brute force attack and add the current document today, and figure out the architecture in the future. -- 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: Tagline for Derby
Jean T. Anderson wrote: Francois Orsini wrote: Right this is where I got it from - I mentioned this as Derby is an Apache (2.0) based project - Hence, am curious as to what the trademark issue would be really for a tagline such Open Source Database (the one you mentioned) - is a separate license needed or not? My concern was using the words open source, but other email from Dan indicates that this shouldn't be an issue. But I seriously wonder if we want to have a tagline that could require explanation -- and translation, as Dan also pointed out. I think no tagline would be fine. I noticed, however, that a Google search for open source database did not hit our website in at least the first 10 pages, but did see many other open source database alternatives there. I am guessing that tag line would add us to the search, but perhaps there is something else we could do with our website to put us there. Kathey
[jira] Commented: (DERBY-869) documentation to address Derby-783
[ http://issues.apache.org/jira/browse/DERBY-869?page=comments#action_12363899 ] Eric Radzinski commented on DERBY-869: -- Attached patch address changes to the ALTER TABLE column-alteration functionality that was introduced by Derby-783. HTML file included for review... documentation to address Derby-783 -- Key: DERBY-869 URL: http://issues.apache.org/jira/browse/DERBY-869 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.0 Reporter: Eric Radzinski Attachments: derby869.diff, rrefsqlj81859.html document changes to ALTER TABLE syntax to address Derby-783 -- 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-869) documentation to address Derby-783
[ http://issues.apache.org/jira/browse/DERBY-869?page=all ] Eric Radzinski updated DERBY-869: - Attachment: derby869.diff rrefsqlj81859.html Attached patch address changes to ALTER TABLE column-alteration functionality that was introduced by Derby-783. HTML file included for review. documentation to address Derby-783 -- Key: DERBY-869 URL: http://issues.apache.org/jira/browse/DERBY-869 Project: Derby Type: Sub-task Components: Documentation Versions: 10.0.2.0 Reporter: Eric Radzinski Attachments: derby869.diff, rrefsqlj81859.html document changes to ALTER TABLE syntax to address Derby-783 -- 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: Features of the JUnit test execution harness
I agree with you that is disconcerting, but can't JUnit tests be written that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest cleaned up to everyone's satisfaction? BTW, if you don't like the rampant catching and ignoring, is anything preventing you from going in and fixing it? :) I suppose we need to hear from Rick about his feelings around this before we go and reverse his changes... David Daniel John Debrunner wrote: I would like my concerns to be cleared up before too many tests use the current Junit facility. The rampant catching and ignoring of SQLExceptions is not good. Dan. begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
Re: conflict between Derby API and JDBC 4.0
Rick Hillegas wrote: Three months ago, we shelved this topic, promising to return to it later. I would like to reach consensus on this problem now. In a nutshell: JDBC4 introduces new methods whose signatures contain generics. Because of this, DataSource implementations can't satisfy both the JDBC3 and JDBC4 contracts. I would like to restart the discussion by proposing the following: 1) Derby's public API will contain two sets of DataSource implementations, one which satisfies the JDBC3 contract and one which satisfies JDBC4. 2) The documented, approved way to obtain DataSources will be to call factory methods on EmbeddedDriver and ClientDriver. These factory methods will hand back either JDBC3 or JDBC4 DataSources depending on the vm. How does this work in app server environments where you simply specify the DataSource class name directly in the settings for a connection pool? Do I as someone deploying into an app server have to choose which Derby DataSource to use? Also, you have described the public API. Am I to assume that internally the JDBC 4 DataSource will somehow be able to take advantage of the inheritance framework that currently exists today? It also seems a little odd to have EmbeddedDriver/ClientDriver be a factory for DataSource which then uses EmbeddedDriver/ClientDriver to manufacture connections... I guess it's OK, but I worry about circular dependencies... Will there also be separate XADataSource and ConnectionPoolDataSource implementations for JDBC3-- and JDBC4++? David begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
[jira] Updated: (DERBY-398) Exclude tests for J2ME/CDC/Foundation platform
[ http://issues.apache.org/jira/browse/DERBY-398?page=all ] Deepa Remesh updated DERBY-398: --- Attachment: (was: parameterMapping.diff) Exclude tests for J2ME/CDC/Foundation platform -- Key: DERBY-398 URL: http://issues.apache.org/jira/browse/DERBY-398 Project: Derby Type: Sub-task Components: Test Reporter: Deepa Remesh Assignee: Deepa Remesh Attachments: derby-398_2.diff, derby-398_2.status, derbyall_report_2.txt, jdbcapi_lang_patch.diff, jdbcapi_lang_patch.status, jdk14_tests_3.diff, jdk14_tests_3.status, nullSQLText_patch.diff, nullSQLText_patch.status, readme_patch.diff, store_patch.diff, store_patch.status, wisc_rename_patch.diff, wisc_rename_patch.status, wisconsin_patch.diff, wisconsin_patch.status Exclude tests which use DriverManager, Driver or BigDecimal classes which are not in J2ME or JSR169. Ensure that derbyall can be run successfully in J2ME/CDC/Foundation platform using the JDBC Optional Package for CDC/Foundation Profile (JSR169). -- 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-398) Exclude tests for J2ME/CDC/Foundation platform
[ http://issues.apache.org/jira/browse/DERBY-398?page=all ] Deepa Remesh updated DERBY-398: --- Attachment: (was: parameterMapping.status) Exclude tests for J2ME/CDC/Foundation platform -- Key: DERBY-398 URL: http://issues.apache.org/jira/browse/DERBY-398 Project: Derby Type: Sub-task Components: Test Reporter: Deepa Remesh Assignee: Deepa Remesh Attachments: derby-398_2.diff, derby-398_2.status, derbyall_report_2.txt, jdbcapi_lang_patch.diff, jdbcapi_lang_patch.status, jdk14_tests_3.diff, jdk14_tests_3.status, nullSQLText_patch.diff, nullSQLText_patch.status, readme_patch.diff, store_patch.diff, store_patch.status, wisc_rename_patch.diff, wisc_rename_patch.status, wisconsin_patch.diff, wisconsin_patch.status Exclude tests which use DriverManager, Driver or BigDecimal classes which are not in J2ME or JSR169. Ensure that derbyall can be run successfully in J2ME/CDC/Foundation platform using the JDBC Optional Package for CDC/Foundation Profile (JSR169). -- 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-756) OutOfMemory Error on continous execution of select statement using COUNT() and DISTINCT on same connection
Hello.. I was wondering if this fix will be available soon. Thank you very much for your time. Sincerely, -Mark
[jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.
[ http://issues.apache.org/jira/browse/DERBY-491?page=all ] Bryan Pendleton updated DERBY-491: -- Attachment: svn_jan_24_2006.diff Updated patch, against latest trunk. I added a few additional comments to this patch to try to explain the changes more clearly, and also I added a reference to this bug entry to help the reader find more information. Now that DERBY-125 has been committed (thanks!), the regression test passes cleanly, and I have also run the entire derbyall suite with this patch. I think that this patch proposal is now ready for review. Kathey, Army, other interested reviewers, please have a look and tell me what you think! Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure. --- Key: DERBY-491 URL: http://issues.apache.org/jira/browse/DERBY-491 Project: Derby Type: Sub-task Components: Network Server Versions: 10.1.1.0, 10.2.0.0, 10.0.2.2 Environment: Derby Network Server running with either JDBC or ODBC driver. Reporter: A B Assignee: Bryan Pendleton Attachments: changes.html, storedProcs.java, stored_proc_repro.java, svn_Jan_13_2006.status, svn_Jan_13_3006.diff, svn_jan_24_2006.diff When Derby Network Server tries to return ~32K or greater data as part of the result set for a stored procedure, a protocol exception occurs and causes deallocation of the connection. Repro can be found in the stored_proc_repro.java file, which uses the stored procedure BIG_COL declared in storedProcs.java. Both files are attached to this bug. -- 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: Features of the JUnit test execution harness
David W. Van Couvering wrote: I agree with you that is disconcerting, but can't JUnit tests be written that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest cleaned up to everyone's satisfaction? Depends, at some point you put the potential burden of fixing all those new tests on the person doing the cleanup, that should have been part of the original submission. BTW, if you don't like the rampant catching and ignoring, is anything preventing you from going in and fixing it? :) Nope, apart from time. There's also nothing stopping me from veto'ing the original submission and reverting it until it handles exceptions in a way that does not have the potential to hide bugs. Guess which is less effort for me. :-) I suppose we need to hear from Rick about his feelings around this before we go and reverse his changes... Actually that doesn't matter, since they are not 'his changes', it's now code at Apache Derby. Dan.
Multiple causes for same SQL State
I have noticed that there can be multiple exceptions that can map to the same standard SQL State. For example, 08003 means connection does not exist. I have found at least two places where this is valid. I think it's reasonable to do something like this in SQLState.java String CONN_ERROR_1 = 08003.C.1; String CONN_ERROR_2 = 08003.C.2; The code that extracts severity from the message id would not be impacted, as it only looks at the 7th character. This seems reasonable to me, but looks like a break from what has been done in the past. Is there anything I'm missing that I should be aware of before I take this approach? Thanks, David begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
Re: conflict between Derby API and JDBC 4.0
Rick Hillegas wrote: Three months ago, we shelved this topic, promising to return to it later. I would like to reach consensus on this problem now. In a nutshell: JDBC4 introduces new methods whose signatures contain generics. Are generics represented by new entries in the class file that break on older VMs? Because of this, DataSource implementations can't satisfy both the JDBC3 and JDBC4 contracts. I would like to restart the discussion by proposing the following: 1) Derby's public API will contain two sets of DataSource implementations, one which satisfies the JDBC3 contract and one which satisfies JDBC4. 2) The documented, approved way to obtain DataSources will be to call factory methods on EmbeddedDriver and ClientDriver. These factory methods will hand back either JDBC3 or JDBC4 DataSources depending on the vm. -1 Breaks the established pattern of how DataSource objects are used. 3) JDBC4 DataSources will have private constructors. -1 Breaks the established pattern of how DataSource objects are used. 4) In contrast, the JDBC3 DataSources will continue to expose public constructors. Existing Derby applications won't have to change, +1 provided that they are run on jdk1.3, jdk1.4, or jdk1.5. -1 Much like I expect a application written against JDK 1.4 to run on JDK 1.5, shouldn't I expect an application written against JDK 1.4 to run on 1.6? Or is there some change in Java binary compatibility I'm unaware of? 5) However, we will raise exceptions if applications try to construct JDBC3 DataSources while running on jdk1.6. The exceptions will tell the customer to call the appropriate factory methods. -1 JDBC 3.0 DataSources/applications should work fine on JDK 1.6/JDBC 4.0. Again, unless Java binary compatibility is broken. Note that this describes the behavior of Derby 10.2. We make no promises about what will happen if the customer tries to run earlier versions of Derby on jdk1.6. Under those combinations, the customer will see runtime exceptions when trying to invoke JDBC4-specific methods. I agree with this, Derby 10.0 and 10.1 do not support JDBC 4.0, so calling JDBC 4.0 methods against their drivers/data sources etc. will lead to abstract method exceptions or similar. Dan.
Re: Multiple causes for same SQL State
David W. Van Couvering wrote: I have noticed that there can be multiple exceptions that can map to the same standard SQL State. For example, 08003 means connection does not exist. I have found at least two places where this is valid. I think it's reasonable to do something like this in SQLState.java String CONN_ERROR_1 = 08003.C.1; String CONN_ERROR_2 = 08003.C.2; The code that extracts severity from the message id would not be impacted, as it only looks at the 7th character. This seems reasonable to me, but looks like a break from what has been done in the past. Is there anything I'm missing that I should be aware of before I take this approach? I think this approach is already taken for a few errors in the embedded case. Dan.
Re: Tagline for Derby
Yes, sounds like it would be nice to have Derby shows up earlier than 10 pages down the walk... ;) On 1/24/06, Kathey Marsden [EMAIL PROTECTED] wrote: Jean T. Anderson wrote: Francois Orsini wrote: Right this is where I got it from - I mentioned this as Derby is an Apache (2.0) based project - Hence, am curious as to what the trademark issue would be really for a tagline such Open Source Database (the one you mentioned) - is a separate license needed or not? My concern was using the words open source, but other email from Dan indicates that this shouldn't be an issue. But I seriously wonder if we want to have a tagline that could require explanation -- and translation, as Dan also pointed out. I think no tagline would be fine. I noticed, however, that a Google search for open source database did not hit our website in at least the first 10 pages, but did see many other open source database alternatives there. I am guessing that tag line would add us to the search, but perhaps there is something else we could do with our website to put us there. Kathey
[jira] Resolved: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.
[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton resolved DERBY-125: --- Fix Version: 10.2.0.0 Resolution: Fixed Fixed in the trunk with commit of revision 371603 Network Server can send DSS greater than 32K to client, which breaks DRDA protocol. --- Key: DERBY-125 URL: http://issues.apache.org/jira/browse/DERBY-125 Project: Derby Type: Bug Components: Network Server Reporter: A B Assignee: Bryan Pendleton Fix For: 10.2.0.0 Attachments: changes.html, offByOne.jar, repro.java, svn_jan_12_2006.status, svn_jan_22_2006.diff BACKGROUND: DRDA protocol, which is the protocol used by Derby Network Server, dictates that all DSS objects with data greater than 32,763 bytes should be broken down into multiple continuation DSSes. PROBLEM: When Network Server receives a prepareStatement call that has a very large number of parameters, it can end up sending a reply DSS that is greater than 32K long to the client; doing so breaks DRDA protocol. REPRODUCTION: Note that this reproduction does NOT cause a protocol exception against the JCC driver--without further investigation, it would appear JCC doesn't mind that the DSS is too long. However, other DRDA clients (such as the DB2 ODBC client) will see that the data is too long and will fail because of it. To reproduce, one can create a simple table and then prepare a statement such as: SELECT id FROM t1 WHERE id in ( ?, ?, [ ... lots and lots of param markers ... ], ?) Note that JCC uses deferred prepare by default; when connecting, one must append the deferPrepares=false attribute to the end of the URL in order to reproduce the problem (that or just try to execute the statement, since preparation will be done at execution time). When doing the prepare, I added a line in the flush method of org.apache.derby.impl.drda.DDMWriter.java to see how large the reply DSS was, and for cases where the number of parameter markers was high, the number of bytes in the single DSS would surpass 32K, and thus break protocol. NOTES: Network Server correctly uses continuation DSSes for LOBs and for result set data (data returned as the result of a query) that is greater than 32K. The problem appears to be in other cases, such as for the prepareStatement call described above. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ] Bryan Pendleton resolved DERBY-170: --- Fix Version: 10.2.0.0 Resolution: Fixed Fixed in the trunk by commit of revision 369549. Inserting large string value into non-existent table causes communication link failure over Network Server. --- Key: DERBY-170 URL: http://issues.apache.org/jira/browse/DERBY-170 Project: Derby Type: Bug Components: Network Server Environment: Derby Network Server running with either JDBC or ODBC driver. Reporter: A B Assignee: Bryan Pendleton Fix For: 10.2.0.0 Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of large data transfer, though the context in which the transfer occurs is different for each failure. Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the assert_repro.java file attached to this bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-756) OutOfMemory Error on continous execution of select statement using COUNT() and DISTINCT on same connection
[ http://issues.apache.org/jira/browse/DERBY-756?page=all ]
Manish Khettry resolved DERBY-756:
--
Resolution: Fixed
Modified DistinctScalarAggregateResultSet:close to free resources initialized
during open.
OutOfMemory Error on continous execution of select statement using COUNT()
and DISTINCT on same connection
--
Key: DERBY-756
URL: http://issues.apache.org/jira/browse/DERBY-756
Project: Derby
Type: Bug
Components: Demos/Scripts, JDBC, Network Client, Network Server, SQL
Versions: 10.0.2.1, 10.1.2.1
Environment: Windows XP, Java 1.5.0_05, Derby network server 10.0.2.1,
10.1.2.1, Derby heapsize 128m, IBM Universal JDBC driver
Reporter: Bill Chen
Assignee: Manish Khettry
Priority: Critical
Attachments: mem_leak.diff
The OutOfMemory is thrown when I continously execute a sql statement on an
openned JDBC connection. A PreparedStatement and ResultSet is created on the
connection everytime and close after each execution. I suspect that the bug
is related to function COUNT() with keyword DISTINCT. For example, select
count(distinct ID) from TEST where FLAG 2. It will be fine if DISTINCT is
not used, or select count(*) is used.
The exception like Exception in thread DRDAConnThread_2
java.lang.OutOfMemoryError: Java heap space could be thrown on Derby side,
or sometimes on client side.
Please find the test code and schema I used for testing:
create table:
CREATE TABLE Test
(
ID BIGINT NOT NULL,
NAME VARCHAR(512) NOT NULL,
FLAG int,
CONSTRAINT PK_ID PRIMARY KEY (ID)
);
insert data:
insert into TEST values (0, 'name0', 0);
insert into TEST values (1, 'name1', 1);
insert into TEST values (2, 'name2', 2);
Java client:
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.DriverManager;
import java.sql.SQLException;
public class DerbyTest
{
static public void main(String args[]) throws Exception
{
Class.forName(com.ibm.db2.jcc.DB2Driver);
Connection conn = null;
try
{
conn =
DriverManager.getConnection(jdbc:derby:net://localhost:1527/testDB,
admin, admin);
for (int i = 0; i 1000; i++)
{
System.out.println(Query +i);
String sql = select count(distinct ID) from TEST where FLAG
2;
PreparedStatement pStmt = null;
ResultSet rs = null;
try
{
pStmt = conn.prepareStatement(sql);
rs = pStmt.executeQuery();
if (rs.next())
{
rs.getInt(1);
}
}
catch (SQLException e)
{
e.printStackTrace();
}
finally
{
if (rs != null)
rs.close();
if (pStmt != null)
pStmt.close();
}
}
}
finally
{
if (conn != null)
conn.close();
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-808) PreparedStatements can take longer to execute than Statements. There seem to be a problem with searchClauseTransitiveClosure method in PredicateList.java
[ http://issues.apache.org/jira/browse/DERBY-808?page=all ] Satheesh Bandaram reopened DERBY-808: - Reopening to just update the description. PreparedStatements can take longer to execute than Statements. There seem to be a problem with searchClauseTransitiveClosure method in PredicateList.java - Key: DERBY-808 URL: http://issues.apache.org/jira/browse/DERBY-808 Project: Derby Type: Bug Components: SQL Versions: 10.1.2.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.2 Attachments: DERBY-808.patch PreparedStatements could take much longer than Statements because of incorrect search clause transitive closure optimization. For the customer case I investigated this problem, Statement would complete in about 13 seconds, where as equivalent PreparedStatement ran forever. (stoped it after hours) I think there a problem with PredicateList.searchClauseTransitiveClosure method. This method tries to add new search clauses based on equality join between tables involved. Current code only looks for ConstantNodes on the right side of searchClauses. This would miss ParameterNodes, so Derby might miss search clause transitive closure optimizations for PreparedStatements. -- 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-808) PreparedStatements can take longer to execute than equivalent Statements when there are multiple join conditions mixed with some search clauses.
[ http://issues.apache.org/jira/browse/DERBY-808?page=all ] Satheesh Bandaram updated DERBY-808: Summary: PreparedStatements can take longer to execute than equivalent Statements when there are multiple join conditions mixed with some search clauses. (was: PreparedStatements can take longer to execute than Statements. There seem to be a problem with searchClauseTransitiveClosure method in PredicateList.java) PreparedStatements can take longer to execute than equivalent Statements when there are multiple join conditions mixed with some search clauses. Key: DERBY-808 URL: http://issues.apache.org/jira/browse/DERBY-808 Project: Derby Type: Bug Components: SQL Versions: 10.1.2.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.2 Attachments: DERBY-808.patch PreparedStatements could take much longer than Statements because of incorrect search clause transitive closure optimization. For the customer case I investigated this problem, Statement would complete in about 13 seconds, where as equivalent PreparedStatement ran forever. (stoped it after hours) I think there a problem with PredicateList.searchClauseTransitiveClosure method. This method tries to add new search clauses based on equality join between tables involved. Current code only looks for ConstantNodes on the right side of searchClauses. This would miss ParameterNodes, so Derby might miss search clause transitive closure optimizations for PreparedStatements. -- 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: Tagline for Derby
Kathey Marsden wrote: Jean T. Anderson wrote: Francois Orsini wrote: Right this is where I got it from - I mentioned this as Derby is an Apache (2.0) based project - Hence, am curious as to what the trademark issue would be really for a tagline such Open Source Database (the one you mentioned) - is a separate license needed or not? My concern was using the words open source, but other email from Dan indicates that this shouldn't be an issue. But I seriously wonder if we want to have a tagline that could require explanation -- and translation, as Dan also pointed out. I think no tagline would be fine. I noticed, however, that a Google search for open source database did not hit our website in at least the first 10 pages, but did see many other open source database alternatives there. I am guessing that tag line would add us to the search, but perhaps there is something else we could do with our website to put us there. The tagline is part of the image -- does google index images? -jean
[jira] Closed: (DERBY-808) PreparedStatements can take longer to execute than equivalent Statements when there are multiple join conditions mixed with some search clauses.
[ http://issues.apache.org/jira/browse/DERBY-808?page=all ] Satheesh Bandaram closed DERBY-808: --- Resolution: Fixed Closing this issue after updating description. PreparedStatements can take longer to execute than equivalent Statements when there are multiple join conditions mixed with some search clauses. Key: DERBY-808 URL: http://issues.apache.org/jira/browse/DERBY-808 Project: Derby Type: Bug Components: SQL Versions: 10.1.2.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.2 Attachments: DERBY-808.patch PreparedStatements could take much longer than Statements because of incorrect search clause transitive closure optimization. For the customer case I investigated this problem, Statement would complete in about 13 seconds, where as equivalent PreparedStatement ran forever. (stoped it after hours) I think there a problem with PredicateList.searchClauseTransitiveClosure method. This method tries to add new search clauses based on equality join between tables involved. Current code only looks for ConstantNodes on the right side of searchClauses. This would miss ParameterNodes, so Derby might miss search clause transitive closure optimizations for PreparedStatements. -- 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: Features of the JUnit test execution harness
Daniel John Debrunner wrote: David W. Van Couvering wrote: I agree with you that is disconcerting, but can't JUnit tests be written that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest cleaned up to everyone's satisfaction? Depends, at some point you put the potential burden of fixing all those new tests on the person doing the cleanup, that should have been part of the original submission. The other issue is that we have a great opportunity to start out with JUnit tests that follow a consistent pattern and provide a great example for others to follow. If we add a number of tests now that haphazardly use the methods in DerbyJUnitTest (because they are not well commented) then we have a set of tests like the current ones. No pattern, no obvious starting point leading to people inventing their own ways to get connections, run ddl, handle exceptions etc. Dan.
[jira] Updated: (DERBY-796) jdbc 4.0 specific Blob and Clob method support
[ http://issues.apache.org/jira/browse/DERBY-796?page=all ] V.Narayanan updated DERBY-796: -- Attachment: lob_1.diff As pointed out in the above comments reflection is used and this was making the process slow. This has been overcome with the following changes. 1) ClientJDBCObjectFactory is an interface having two implementations a) ClientJDBCObjectFactoryImpl b) ClientJDBCObjectFactoryImpl40 ClientJDBCObjectFactoryImpl is compiled by jdk1.4 ClientJDBCObjectFactoryImpl40 is compiled by mustang (compiled optionally if jdk16 variable is present in ant.properties) 2) The method getFactory() in the ClientDriver class would initialize a variable of type ClientJDBCObjectFactory with an appropriate implementation depending on the jdk version under use. 3) This method is then used to return an instance of the factory implementation that will be used to return the approriate JDBC interface implementations to the user Issues that were addresses earlier and have been fixed -- 1) comments have been added to the ClientJDBCObjectFactory,ClientJDBCObjectFactoryImpl,ClientJDBCObjectFactoryImpl40 classes. Comments have also been added to the atLeast method in Configuration.java 2) I have raised a JIRA issue for setCharacterStreamInternal to be modified (DERBY-856) . setBinaryStreamInternal is being modified as part of DERBY-599 3) Reflection would'nt be used for every object creation as in the previous case and would be only be used in getFactory to rerurn a factory implementation. thanx Narayanan jdbc 4.0 specific Blob and Clob method support -- Key: DERBY-796 URL: http://issues.apache.org/jira/browse/DERBY-796 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Environment: jdbc 4.0 on all platforms Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Fix For: 10.2.0.0 Attachments: lob.diff, lob_1.diff -- 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: conflict between Derby API and JDBC 4.0
Rick Hillegas wrote: Three months ago, we shelved this topic, promising to return to it later. I would like to reach consensus on this problem now. In a nutshell: JDBC4 introduces new methods whose signatures contain generics. Because of this, DataSource implementations can't satisfy both the JDBC3 and JDBC4 contracts. So that's not quite true, a JDBC 4.0 DataSource implementation does satisfy both JDBC 4.0 and JDBC 3.0. I've been looking at if it would be possible to have a single implementation that worked in both. Ie. would the reference to new classes and the generics absolutely make the class not work in JDBC 3.0. Most likely yes, but it's worth throwing out there. One question I do have on the JDBC 4.0 spec, is what is the purpose of this method in javax.sql.DataSource? T T createQueryObject(java.lang.ClassT ifc) throws SQLException For some reason it's not seen as required for a ConnectionPoolDataSource or an XADataSource, so why is it needed on DataSource? As far as I can tell it seems to be a short-cut for getConnection().createQueryObject(java.lang.ClassT ifc) (using the getConnection() method on javax.sql.DataSource). Should we ask this question to the JDBC 4.0 review? The whole ease of section 20.1 in JDBC 4.0 I'd assumed would be above the level of the JDBC driver, it's somewhat disconcerting to me that it's that closely linked to the low level driver. Related to that, does anyone have any idea how the QueryObjectGenerator interface is meant to be used. What piece of code would call CommonDataSource.getQueryObjectGenerator()? Would it be a wrapping DataSource implementation (e.g. from a app server). Section 20.1.6 seems to be no help here. Section 20.2.2.1 has this sentence: If the JDBC driver does not provide its own implementation of a QueryObjectGenerator, it must invoke the default QueryObjectGenerator implementation provided by Java SE 6. I can't see any mention of how a driver implementation finds the defaultQueryObjectGenerator implementation. Dan.
