[jira] Commented: (DERBY-3021) Replication: Add a ReplicationSlave controller that will manage replication on the slave side
[ https://issues.apache.org/jira/browse/DERBY-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527963 ] Jørgen Løland commented on DERBY-3021: -- I have not rerun the tests since there are no code changes. - Silly assumption; sorry about that one :-/ I have found the error and am now *running tests* on it before submitting. Replication: Add a ReplicationSlave controller that will manage replication on the slave side - Key: DERBY-3021 URL: https://issues.apache.org/jira/browse/DERBY-3021 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby-3021-1.diff, derby-3021-1.stat, derby-3021-1b.diff, derby-3021-1b.stat The replication slave role includes many tasks: * set up a network connection with the master * receive chunks of log from the master, and parse these into individual log records * append log records to the local log file * make sure that the recovery process is not allowed to access the logfile we are currently writing to * etc This issue is for adding a controller that will start/stop/initiate all services needed for the replication slave role. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3021) Replication: Add a ReplicationSlave controller that will manage replication on the slave side
[ https://issues.apache.org/jira/browse/DERBY-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527969 ] Øystein Grøvlen commented on DERBY-3021: I have already committed a fix as version 576288. For me, ErrorCodeTest now runs without errors. Replication: Add a ReplicationSlave controller that will manage replication on the slave side - Key: DERBY-3021 URL: https://issues.apache.org/jira/browse/DERBY-3021 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby-3021-1.diff, derby-3021-1.stat, derby-3021-1b.diff, derby-3021-1b.stat The replication slave role includes many tasks: * set up a network connection with the master * receive chunks of log from the master, and parse these into individual log records * append log records to the local log file * make sure that the recovery process is not allowed to access the logfile we are currently writing to * etc This issue is for adding a controller that will start/stop/initiate all services needed for the replication slave role. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3051) Replication: Modify logging subsystem to append log records to the replication buffer when in replication master mode
[ https://issues.apache.org/jira/browse/DERBY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527999 ] Øystein Grøvlen commented on DERBY-3051: Patch looks good. I have only nits on my list: 1. LogToFile#inReplicationMasterMode: LogToFile also has a member inSlaveMode. Maybe that should be called inReplicationSlaveMode for uniformity? Also, I think the declaration of these two member fields should be placed together. 2. LogToFile#appendLogRecord: Any particular reason that MasterFactory#appendLogRecord has a different ordering of the parameters than LogToFile#appendLogRecord. I think the code would be easier to read if the methods had the same parameter ordering. 3. LogToFile#flush: What does the '?' behind INVALID_LOG_INSTANT mean? 4. LogToFile#startReplicationMasterRole, javadoc: I would say 'pass log records' instead of 'send ...' in order to make it clearer that the MasterFactory is on the same node, and that we here are not talking about sending it over the network to the MasterFactory. 5. LogToFile#stopReplicationMasterRole, javadoc: Seems not right to mention ReadOnly here since that is a different implementation of LogFactory. 6. LogFactory#(start|stop)ReplicationMasterRole, javadoc: The javadoc references to the corresponding ReadOnly methods does not seem necessary to me. Replication: Modify logging subsystem to append log records to the replication buffer when in replication master mode - Key: DERBY-3051 URL: https://issues.apache.org/jira/browse/DERBY-3051 Project: Derby Issue Type: Sub-task Components: Services, Store Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby_3051_1.diff, derby_3051_1.stat When Derby has the replication master role for a database 'x', it should ship all log records generated for this database to the Derby with the slave role. A replication buffer was added to Derby in DERBY-2926. This issue is for modifying the logging subsystem to append log records to this buffer every time a log records is appended to the disk buffer (LogAccessFile). This will, of course, only be done if it has the master role. Currently, I have identified two modifications that will be required in LogToFile: * LogToFile#appendLogRecord needs to append to the replication buffer after appending to the disk buffer * LogToFile#flush (i.e., the method used to force buffered log records to disk) must notify the Master Controller (DERBY-2977) that a flush has taken place. The MasterController will decide if any action is required because of this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
When is 10.3.1.5 release planned?
Is there a schedule for a 10.3.1.5 release? The wiki docs don't seem to go beyond 10.3.1.4 and I need a release with a bug fix that has been made since 10.3.1.4. Thanks Tim
[jira] Created: (DERBY-3078) Better error messages needed when foreign key constraint creation fails because of delete-connection violations
Better error messages needed when foreign key constraint creation fails because of delete-connection violations --- Key: DERBY-3078 URL: https://issues.apache.org/jira/browse/DERBY-3078 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.2.2.0 Environment: N/A Reporter: Nick Williamson Priority: Minor Derby produces messages like this when creating a schema: ERROR 42915: Foreign Key 'PIN_FK1' is invalid because 'the delete rule of foreign key can not be CASCADE. (The relationship would cause another table to be delete-connected to the same table through multiple paths with different delete rules or with delete rule equal to SET NULL.) ERROR 42915: Foreign Key 'VC_FK3' is invalid because 'the delete rule of foreign key must be CASCADE. (The relationship would cause the table to be delete-connected to the same table through multiple relationships and such relationships must have the same delete rule (NO ACTION, RESTRICT or CASCADE).) In a large schema with many FK constraints, it is extremely difficult to identify the table that is actually causing the problem. Obviously, one of them will be either the table to which the constraint is being added or the table that is referenced by the constraint, but which is the other table? I have to examine all the children parents of the tables involved in the constraint and keep working iteratively up down through their own parents and children until I finally find two conflicting delete paths for the same table. There have been several instances where I'm just unable to get to the bottom of the problem because of the complexity of the table relationships in my schema. The error messages need to explicitly name the tables instead of referring to the table and the other table, and they need to give the name of the already-existing FK constraint that has prevented this FK constraint from being created successfully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2235) Server doesnt support timestamps with timezone
[ https://issues.apache.org/jira/browse/DERBY-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528044 ] Bernt M. Johnsen commented on DERBY-2235: - Brorwsing through the SQL2003 standard, I find that Dan is right. A timestamp without timezone has no associated timezone, not even implicit. So '2000-01-01 12:00:00' in LA is '2000-01-01 12:00:00' in NY since no timezone is associated with the datatype. Then it is the application's problem to interpret the values. The standard *does* say, however, that the current SQL-session's timezone is applied if timezone is required (e.g when cast to TIMESTAMP WITH TIMEZONE). Quote from the standard: If time zone interval is not specified, then no assumption is made about time zone displacement. However, should a time zone displacement be required during subsequent processing, the current default time zone displacement of the SQL-session will be applied at that time. Server doesnt support timestamps with timezone -- Key: DERBY-2235 URL: https://issues.apache.org/jira/browse/DERBY-2235 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.2.2.0 Reporter: Ken Johanson Priority: Minor DML with datetime literals having timzone offset data (ISO-8601): update tbl set dt1 = '2007-01-03 04:13:43.006 -0800' Causes: SQLException: The syntax of the string representation of a datetime value is incorrect. Error: -1 SQLSTATE: 22007 I believe that even if the storage does not (does it?) support timezone storage, the input of a TZ could be normalized (offset applied) to the default TZ. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3051) Replication: Modify logging subsystem to append log records to the replication buffer when in replication master mode
[ https://issues.apache.org/jira/browse/DERBY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-3051: - Attachment: derby_3051_1b.diff derby_3051_1b.stat Attaching a patch, v1b, incorporating comments from Narayanan and Øystein. Narayanan: You are correct; before the stopReplicationMaster method is ever called, startReplicationMaster has been called. This means that in read only databases, a cannot replicate readonly database exception has already been thrown. Replication: Modify logging subsystem to append log records to the replication buffer when in replication master mode - Key: DERBY-3051 URL: https://issues.apache.org/jira/browse/DERBY-3051 Project: Derby Issue Type: Sub-task Components: Services, Store Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby_3051_1.diff, derby_3051_1.stat, derby_3051_1b.diff, derby_3051_1b.stat When Derby has the replication master role for a database 'x', it should ship all log records generated for this database to the Derby with the slave role. A replication buffer was added to Derby in DERBY-2926. This issue is for modifying the logging subsystem to append log records to this buffer every time a log records is appended to the disk buffer (LogAccessFile). This will, of course, only be done if it has the master role. Currently, I have identified two modifications that will be required in LogToFile: * LogToFile#appendLogRecord needs to append to the replication buffer after appending to the disk buffer * LogToFile#flush (i.e., the method used to force buffered log records to disk) must notify the Master Controller (DERBY-2977) that a flush has taken place. The MasterController will decide if any action is required because of this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3069) Derby does not resolve functions bound to methods with varargs.
[ https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3069: - Derby Info: [Patch Available] This patch passes the existing regression tests. Does not, however, introduce any new tests yet. Derby does not resolve functions bound to methods with varargs. --- Key: DERBY-3069 URL: https://issues.apache.org/jira/browse/DERBY-3069 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-3069-01-varargs-aa.diff, z.java, z.sql Varargs were added in Java 5. It would be nice if Derby let you invoke a function bound to a method with a variable length argument list. The Reference Guide states a small number of restrictions for methods which can be invoked as Derby functions: They must be public, static, and not have arguments which are long datatypes. I see no reason that Derby shouldn't be able to resolve and invoke functions which are bound to methods which don't suffer these limitations but which have variable argument lists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3051) Replication: Modify logging subsystem to append log records to the replication buffer when in replication master mode
[ https://issues.apache.org/jira/browse/DERBY-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528053 ] Jørgen Løland commented on DERBY-3051: -- Patch 1b passes all tests. Replication: Modify logging subsystem to append log records to the replication buffer when in replication master mode - Key: DERBY-3051 URL: https://issues.apache.org/jira/browse/DERBY-3051 Project: Derby Issue Type: Sub-task Components: Services, Store Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: Jørgen Løland Attachments: derby_3051_1.diff, derby_3051_1.stat, derby_3051_1b.diff, derby_3051_1b.stat When Derby has the replication master role for a database 'x', it should ship all log records generated for this database to the Derby with the slave role. A replication buffer was added to Derby in DERBY-2926. This issue is for modifying the logging subsystem to append log records to this buffer every time a log records is appended to the disk buffer (LogAccessFile). This will, of course, only be done if it has the master role. Currently, I have identified two modifications that will be required in LogToFile: * LogToFile#appendLogRecord needs to append to the replication buffer after appending to the disk buffer * LogToFile#flush (i.e., the method used to force buffered log records to disk) must notify the Master Controller (DERBY-2977) that a flush has taken place. The MasterController will decide if any action is required because of this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-3069) Derby does not resolve functions bound to methods with varargs.
[ https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas reassigned DERBY-3069: Assignee: Rick Hillegas Derby does not resolve functions bound to methods with varargs. --- Key: DERBY-3069 URL: https://issues.apache.org/jira/browse/DERBY-3069 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: z.java, z.sql Varargs were added in Java 5. It would be nice if Derby let you invoke a function bound to a method with a variable length argument list. The Reference Guide states a small number of restrictions for methods which can be invoked as Derby functions: They must be public, static, and not have arguments which are long datatypes. I see no reason that Derby shouldn't be able to resolve and invoke functions which are bound to methods which don't suffer these limitations but which have variable argument lists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3069) Derby does not resolve functions bound to methods with varargs.
[ https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3069: - Attachment: derby-3069-01-varargs-aa.diff Attaching derby-3069-01-aa.diff. This allows you to run functions which are bound to methods which have vararg signatures. Touches the following files: M java/engine/org/apache/derby/iapi/services/loader/ClassInspector.java This is the compile-time bind() logic. This allows you to resolve function declarations against methods which have vararg signatures. This also exposes helper methods for determining whether a method has a vararg signature. M java/engine/org/apache/derby/impl/sql/compile/MethodCallNode.java M java/engine/org/apache/derby/impl/sql/compile/StaticMethodCallNode.java This is the compile-time generate() piece, which generates the byte code needed to invoke varags methods. For varargs signatures, this method builds a concluding array argument and stuffs it with the trailing arguments specified by the user. Derby does not resolve functions bound to methods with varargs. --- Key: DERBY-3069 URL: https://issues.apache.org/jira/browse/DERBY-3069 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4 Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-3069-01-varargs-aa.diff, z.java, z.sql Varargs were added in Java 5. It would be nice if Derby let you invoke a function bound to a method with a variable length argument list. The Reference Guide states a small number of restrictions for methods which can be invoked as Derby functions: They must be public, static, and not have arguments which are long datatypes. I see no reason that Derby shouldn't be able to resolve and invoke functions which are bound to methods which don't suffer these limitations but which have variable argument lists. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Running the junit testsuite with a remote server
I'm interested in running the junit tests with a remote server, but as far as I can see there is no easy way to do so yet. I found two relevant jiras: https://issues.apache.org/jira/browse/DERBY-1973 (Support running JUnit tests directly with a remote server) http://issues.apache.org/jira/browse/DERBY-2638 (Create an option for junit tests to run only client tests) As these are currently unassigned I was thinking of taking a closer look myself. A couple of questions: What interface should be used to instruct the test framework that you want to use a network server (probably started manually) running on a given host portnumber, instead of the default localhost location? And along the same lines, what is the best way to instruct the test framework that you want to run only the client tests (or only the embedded tests)? For choosing to run only a subset of tests, like the client tests, I see a few possibilities: * Create some new top level suite, for instance Suites.client that runs only the client tests. * Set a property (on the commandline) when starting Suites.All (or any other subsuite) that instructs the framework to only run the client tests. * Make it possible to do both of the above. For instructing the framework to use a specific hostname and portnumber instead of the defaults I don't have any good ideas except using properties. The DERBY-1973 report says Ideally this would be through a test decorator and not setting properties on the command line., though. Any suggestions on the best way to solve this? The TestConfiguration class seems to read system properties for framework (embedded or client), hostname and port, but is this code there only to make the tests run under the old harness and intended to be removed when all the tests are converted? Is it likely that all client tests will work with a remote server, or will some tests be written in a way that requires the server(s) to run on the same host as the test framework? Perhaps some tests have to start the networkserver as part of the test, and because of this it has to run on the same host. In this case it would actually be three groups of tests: embedded, local networkserver and remote networkserver. If anyone has given all of this some thought I'd be happy to hear. Vemund
[jira] Commented: (DERBY-2921) Replication: Add a network service that connects the master and slave Derby instances
[ https://issues.apache.org/jira/browse/DERBY-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528060 ] Øystein Grøvlen commented on DERBY-2921: Patch is starting to look very good, Narayanan! Most of my comments are minor nits: 1. The javadoc for public classes and methods should focus on how it is to be used, not on its implementation. Some of the javadoc for fields just says the obvious, instead of what it represents. (E.g., Stores an instance of the SlaveAddress class. If you know Java, you know this. No need to tell people that. Instead, you should tell that slaveAddress contains the address to the slave to replicate to.) 2. In javadoc, I think @throws needs to be repeated for each exception. 3. ReplicationMessageTransmit#sendAndReceiveAck: If an error is returned, why not use ack.getMessage() to get the SQLState? 4. SlaveAddress: I suggest to drop 'Slave' from getSlaveHostAddress() and getSlavePortNumber() since that should be implicit from the name of the class. 5. ReplicationMessageReceive: It seems unecessary to have serverSocket as a member field when it is only used by one method. I think it could be local to initConnection(). 6. SocketConnection: I think you should deal with Objects in this class and let the replication specific casting be done by the ReplicationMessage... classes. 7. SocketConnection#writeMessage: The previous version did reset before writing and flush after. Have you decided that this is not necessary? 8. ReplicationMessage: a) I thought messages of type TYPE_LOG, would contain LogRecord objects, not byte arrays. b) Why not use Integer or Long instead of String for the UID part of TYPE_INITIATE? c) VERSION_MISMATCH does not seem to be used. d) If you are able to cast the UID to int, why not store it as an integer instead of as a long? Replication: Add a network service that connects the master and slave Derby instances - Key: DERBY-2921 URL: https://issues.apache.org/jira/browse/DERBY-2921 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.4.0.0 Reporter: Jørgen Løland Assignee: V.Narayanan Attachments: Replication_Network_expln_v6.txt, Replication_Network_v1.diff, Replication_Network_v1.stat, Replication_Network_v2.diff, Replication_Network_v2.stat, Replication_Network_v3.diff, Replication_Network_v3.stat, Replication_Network_v4.diff, Replication_Network_v4.stat, Replication_Network_v5.diff, Replication_Network_v5.stat, Replication_Network_v6.diff, Replication_Network_v6.stat A network connection is required between the master and slave Derby instances of a replicated database. The connection will be used to send many kinds of messages, including: * log records * the database (when replication is started) * master - slave commands (like stop replication) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2824) Improve error reporting, fix whitespace/formatting issues and replace tabs in UTF8Reader
[ https://issues.apache.org/jira/browse/DERBY-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2824: --- Attachment: derby-2824-4a-javadoc.diff 'derby-2824-4a-javadoc.diff' adds new JavaDoc and changes some of the existing. In addition, it removes an 'throws IOException' from one of the constructors and makes the variable 'buffer' final. suites.All ran without failures (9535 tests, Java SE 6). This is my last patch for this issue. Improve error reporting, fix whitespace/formatting issues and replace tabs in UTF8Reader Key: DERBY-2824 URL: https://issues.apache.org/jira/browse/DERBY-2824 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-2824-1a-tabs_to_spaces.diff, derby-2824-2a-whitespace_changes.diff, derby-2824-3a-improved_error_reporting.diff, derby-2824-3b-improved_error_reporting.diff, derby-2824-4a-javadoc.diff I plan to do the following changes to UTF8Reader: * Improve the error reporting when hitting a UTF8 decoding error (currently an UTFDataFormatException with no message). This might also lead to deleting one helper method for generating an exception (the one with no message). * Improve error reporting for trying to use the reader after it has been closed (currently an IOException with no message). * Remove trailing spaces, and add a few newlines here and there. * Replace tabs in the file with spaces. Now, the last point can be discussed, but here are my arguments for doing it: * The file now has a mix of tabs and spaces (but still more tabs). * Spaces are the preferred/required method of indentation. * I want to get it fixed before the branch is cut, which makes it easier to port fixes from trunk/10.3-NEXT to 10.3. If I don't make it for 10.3, I won't do it. * I don't see it as very likely that we will back-port major fixes to this class on the 10.2 branch. If we have to, I will volunteer :) * Since so much else of the Clob infrastructure has changed recently, this seems like a good time to do the clean-up. Please raise your concern as soon as possible if you want to veto these changes. I do plan to commit them tomorrow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2824) Improve error reporting, fix whitespace/formatting issues and replace tabs in UTF8Reader
[ https://issues.apache.org/jira/browse/DERBY-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-2824: --- Derby Info: [Patch Available] Affects Version/s: 10.4.0.0 Fix Version/s: 10.4.0.0 Improve error reporting, fix whitespace/formatting issues and replace tabs in UTF8Reader Key: DERBY-2824 URL: https://issues.apache.org/jira/browse/DERBY-2824 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.3.1.4, 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-2824-1a-tabs_to_spaces.diff, derby-2824-2a-whitespace_changes.diff, derby-2824-3a-improved_error_reporting.diff, derby-2824-3b-improved_error_reporting.diff, derby-2824-4a-javadoc.diff I plan to do the following changes to UTF8Reader: * Improve the error reporting when hitting a UTF8 decoding error (currently an UTFDataFormatException with no message). This might also lead to deleting one helper method for generating an exception (the one with no message). * Improve error reporting for trying to use the reader after it has been closed (currently an IOException with no message). * Remove trailing spaces, and add a few newlines here and there. * Replace tabs in the file with spaces. Now, the last point can be discussed, but here are my arguments for doing it: * The file now has a mix of tabs and spaces (but still more tabs). * Spaces are the preferred/required method of indentation. * I want to get it fixed before the branch is cut, which makes it easier to port fixes from trunk/10.3-NEXT to 10.3. If I don't make it for 10.3, I won't do it. * I don't see it as very likely that we will back-port major fixes to this class on the 10.2 branch. If we have to, I will volunteer :) * Since so much else of the Clob infrastructure has changed recently, this seems like a good time to do the clean-up. Please raise your concern as soon as possible if you want to veto these changes. I do plan to commit them tomorrow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3072) User documentation for Table Functions
[ https://issues.apache.org/jira/browse/DERBY-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3072: - Attachment: derby-3072-01-basic-aa.tar derby-3072-01-basic-aa.diff Attaching derby-3072-01-basic-aa.diff and the corresponding html output, derby-3072-01-basic-aa.tar. This is a first cut at writing the user documentation for table functions, as laid out in the Documentation section of the functional spec attached to DERBY-716. Touches the following files: M src/tuning/tuningderby.ditamap A src/tuning/ctunperftablefunctions.dita A src/devguide/cdevspecialtfopttune.dita M src/devguide/cdevspecial.dita A src/devguide/cdevspecialtfoptexample.dita M src/devguide/derbydev.ditamap A src/devguide/cdevspecialtabfuncs.dita A src/devguide/cdevspecialtfbasic.dita A src/devguide/cdevspecialtfgetxxx.dita A src/devguide/cdevspecialtfoptimizer.dita A src/devguide/cdevspecialtfexample.dita A src/ref/rrefsqljtfinvoke.dita M src/ref/rreftableexpression.dita M src/ref/rrefsqlj33215.dita M src/ref/refderby.ditamap M src/ref/rrefcreatefunctionstatement.dita User documentation for Table Functions -- Key: DERBY-3072 URL: https://issues.apache.org/jira/browse/DERBY-3072 Project: Derby Issue Type: New Feature Components: Documentation Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-3072-01-basic-aa.diff, derby-3072-01-basic-aa.tar This issue tracks changes to the user guides to describe table functions. This is the work needed for the Documentation section of the functional spec attached to DERBY-716. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3072) User documentation for Table Functions
[ https://issues.apache.org/jira/browse/DERBY-3072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3072: - Derby Info: [Patch Available] User documentation for Table Functions -- Key: DERBY-3072 URL: https://issues.apache.org/jira/browse/DERBY-3072 Project: Derby Issue Type: New Feature Components: Documentation Reporter: Rick Hillegas Assignee: Rick Hillegas Attachments: derby-3072-01-basic-aa.diff, derby-3072-01-basic-aa.tar This issue tracks changes to the user guides to describe table functions. This is the work needed for the Documentation section of the functional spec attached to DERBY-716. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: When is 10.3.1.5 release planned?
Tim Dudgeon wrote: Is there a schedule for a 10.3.1.5 release? The wiki docs don't seem to go beyond 10.3.1.4 and I need a release with a bug fix that has been made since 10.3.1.4. Thanks Tim Thanks for raising the question, Tim. I think the next maintenance release on the 10.3 branch will be called something like 10.3.2.0. I can think of a couple issues which gate the release of 10.3.2.0: 1) Generally, we wait for a big drop of localized error message strings. These are the translations to our supported languages of all of the new error messages introduced by the previous feature release (in this case, 10.3.1.4). Does anyone have a sense of when those translations will turn up? 2) Someone has to volunteer to be release manager for 10.3.2.0. Myrna (with some help from Andrew and myself) cat-herded the last release. This would be a good opportunity for someone else to learn the mechanics of producing a Derby release. Generally, a maintenance release is less work than a feature release so for some intrepid, curious soul this would be a good introduction to the release process. Regards, -Rick
attention documentation experts
I have clipped a docs patch to DERBY-3072. This is a first cut of user documentation for Function Tables. I would appreciate feedback from the experts! Thanks, -Rick
Regression Test Report - Daily 576119 - Sun DBTG
[Auto-generated mail] *Daily* 576119/ Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0288288 073.42% derbyall F:1,E:196529650 0 1212.41% suitesAll sles 0288288 072.53% derbyall F:1,E:096529651 0 688.35% suitesAll sol 0288288 077.06% derbyall NA NA NANA suitesAll solN+1 0288288 084.48% derbyall F:1,E:096529651 0 1248.94% suitesAll sparc 0288288 067.58% derbyall F:1,E:096529651 0 297.08% suitesAll vista 0288288 0 .% derbyall F:2,E:188398836 0 476.89% suitesAll w2003 0288288 0 .% derbyall F:2,E:188398836 0 206.91% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-576119.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/576119_bySig.html *Jvm: 1.5* lin 0289289 073.44% derbyall F:1,E:179507948 0 757.60% suitesAll sles 0289289 072.60% derbyall F:1,E:079507949 0 489.58% suitesAll sol NA NA NANA derbyall NA NA NANA suitesAll solN+1 0289289 088.85% derbyall F:1,E:079507949 0 679.77% suitesAll sparc 1289288 068.08% derbyall F:1,E:079507949 0 574.18% suitesAll vista 0289289 098.99% derbyall F:2,E:171377134 0 408.60% suitesAll w2003 0289289 075.88% derbyall F:2,E:171377134 0 223.05% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-576119.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/576119_bySig.html *Jvm: 1.4* lin 0286286 273.98% derbyall F:1,E:078987897 0 684.42% suitesAll sles 0286286 271.72% derbyall F:1,E:078987897 0 444.94% suitesAll sol NA NA NANA derbyall NA NA NANA suitesAll solN+1 0286286 289.29% derbyall F:1,E:078987897 0 647.91% suitesAll sparc 0286286 268.60% derbyall F:1,E:078987897 0 585.18% suitesAll vista 1286285 2 .% derbyall F:2,E:170857082 0 403.11% suitesAll w2003 0286286 2 .% derbyall F:2,E:170857082 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-576119.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/576119_bySig.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/576119.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Requiring Java 5 compiler
I would like to start writing Derby code which makes use of Java 5 features. More specifically: 1) I would like to take advantage of the Java 5 extensions for ease-of-use and stronger type checking. 2) I would like to be able to write regression tests which verify that user-written Java 5 code runs correctly as Derby functions and procedures. Would anyone object to our requiring that developers use a Java 5 or later compiler to build Derby? I believe that we would still require the presence of the 1.4 libraries and the expectation would continue to be that the compiler must compile down to 1.4 classes. Thanks, -Rick
Re: Roles for Derby - draft spec uploaded
Thanks for looking at this, David! David Van Couvering [EMAIL PROTECTED] writes: Hi, Dag. Thanks for this spec, this looks like a nice addition to Derby. I have a couple of comments: - It would be great to have some examples in addition to showing the changes to the reference manual. Identify some standard use cases (Create Role, Grant Role, Revoke Role, Access Resource) and show what commands are executed and what happens as a result. This is not just for reviewers' sake, but also for doc writers (and blog writers :)) The example you have is useful for understanding the spec, but not necessarily so useful for understanding the common use cases. That's true; the spec could have some more examples, I'll see what I can come up with. - What is the motivation to choose not to support a default role when a user signs in. Alternately, if a user is granted roles A and B, why not given them the union of the two privileges for role A and B. Why does the user have to select the role they want to have for a given session? That seems counter-intuitive. The roles are mutually exclusive; max one role can be set for a session at any one time, according to the standard. This can be worked around by creating a role containing several other roles, if desired. RBAC (http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf) lists the possibility to make roles be mutually exclusive as desirable a feature (separation of duty), see for example the discussion in http://csrc.nist.gov/rbac/RBAC_DBMS_Comparison.pdf. The SQL standard could be said to support dynamic separation of duty since only one role can be set at a time. If this was the design rationale of the standard, though, I don't know.. As for having a default role on connect, that could be added later. This is implementation defined behavior, according to SQL std. It is not my itch right now, since I am trying to limit the work in a first increment, but I can see that it could be useful. If a user has been granted more than one role, we would need to be able to specify somehow which role (or none) to auto-set on connection. As for counter-intuitive, I am not sure that's necessarily the case, running with max privileges isn't always what one wants, cf existence of sudo(1). Thanks, Dag
Re: [jira] Updated: (DERBY-2824) Improve error reporting, fix whitespace/formatting issues and replace tabs in UTF8Reader
Kristian Waagan (JIRA) wrote: Improve error reporting, fix whitespace/formatting issues and replace tabs in UTF8Reader I think ideally it is good to keep whitespace/formatting diffs as a separate checkin. It makes it clearer which are code changes and which are not. Is it possible to have two checkins, one for the format/whitespace changes and another for the actual code changes? Kathey
Re: [jira] Updated: (DERBY-3069) Derby does not resolve functions bound to methods with varargs.
Rick Hillegas updated DERBY-3069: - Derby does not resolve functions bound to methods with varargs. --- Jira's down so sending this comment as e-mail: Is there going to be some write up on exactly how the proposed method resolution will work with varargs, so that people can review it and see if it conflicts with the standard method resolution? Will this be a different PARAMETER STYLE (than JAVA)? If not what does it say about Derby's commitment to standards when a SQL routine resolves to a method in Derby that it would not resolve to on another database that is following the SQL standard? Dan.
Re: When is 10.3.1.5 release planned?
On 9/17/07, Rick Hillegas [EMAIL PROTECTED] wrote: Tim Dudgeon wrote: Is there a schedule for a 10.3.1.5 release? The wiki docs don't seem to go beyond 10.3.1.4 and I need a release with a bug fix that has been made since 10.3.1.4. Thanks Tim Thanks for raising the question, Tim. I think the next maintenance release on the 10.3 branch will be called something like 10.3.2.0. I can think of a couple issues which gate the release of 10.3.2.0: Tim, I believe you are specifically/especially interested in the fix for DERBY-3061, which was backported to the 10.3 branch... I'd like to point out that you are completely free to take the fixes that have gone in to the branch and build your own jars. You can think of that as a patched version. The judgement call is whether you think the (published) ongoing functional testing (see for instance Sun's 'Daily tests' for the 10.3. branch on http://dbtg.thresher.com/derby/test/), and the testing done by the committers before checking in (and of course your own testing), is enough compared to the more involved testing for a 'blessed' release, or whether you can wait until/if someone volunteers to push for a new version off the 10.3 branch. Myrna
[jira] Resolved: (DERBY-3074) Database shutdown exception 08006 throws SQLTransientConnectionException instead of SQLNonTransientConnectionException
[ https://issues.apache.org/jira/browse/DERBY-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3074. --- Resolution: Fixed Fix Version/s: 10.4.0.0 10.3.1.5 checked fix into trunk and 10.3 Database shutdown exception 08006 throws SQLTransientConnectionException instead of SQLNonTransientConnectionException -- Key: DERBY-3074 URL: https://issues.apache.org/jira/browse/DERBY-3074 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.3.1.5, 10.4.0.0 Attachments: derby-3074_3075_diff.txt, derby-3074_3075_stat.txt, DerbyEmbeddedException.java SQLNonTransientConnectionException is described as: The subclass of SQLException thrown for the SQLState class value '08', representing that the connection operation that failed will not succeed when the operation is retried without the cause of the failure being corrected. See repro DerbyEmbeddedException.java Yet, database shutdown which is SQLState 8006 throws an SQLTransientConnectionSQLException 10.4.0.0 alpha - (1) Apache Derby got connection now shutdown 08006:Database 'sampl127' shutdown. Exception in thread main java.sql.SQLTransientConnectionException: Database 'sampl127' shutdown. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:76) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:202) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:391) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1574) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:385) at org.apache.derby.impl.jdbc.EmbedConnection30.init(EmbedConnection30.java:73) at org.apache.derby.impl.jdbc.EmbedConnection40.init(EmbedConnection40.java:54) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:211) at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119) at java.sql.DriverManager.getConnection(DriverManager.java:582) at java.sql.DriverManager.getConnection(DriverManager.java:207) at DerbyEmbeddedException.main(DerbyEmbeddedException.java:29) Caused by: java.sql.SQLException: Database 'sampl127' shutdown. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:13 5) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 13 more Caused by: ERROR 08006: Database 'sampl127' shutdown. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290) at org.apache.derby.impl.jdbc.TransactionResourceImpl.shutdownDatabaseException(TransactionResourceImpl.java:224 ) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:355) ... 8 more [C:/kmarsden/repro/NonTransientException] java or -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Roles for Derby - draft spec uploaded
Hi, Dag. Thanks for working on the examples. You are right, a role that composes multiple roles is a good solution. I can imagine creating a role for myself: FatherHusbandColleagueFriendBrotherUncleSon :) Are you saying that with what you're proposing, if you're granted only one role, then that's the role you would have when you connect a session? If not, shouldn't that be pretty easy to do? I see your point about sudo, but if I have only *one* role then why shouldn't that be the role I get? I can just hear myself cursing every time I have to type in SET ROLE admin before I can get any work done through my admin UI. Thanks, David On 9/17/07, Dag H. Wanvik [EMAIL PROTECTED] wrote: Thanks for looking at this, David! David Van Couvering [EMAIL PROTECTED] writes: Hi, Dag. Thanks for this spec, this looks like a nice addition to Derby. I have a couple of comments: - It would be great to have some examples in addition to showing the changes to the reference manual. Identify some standard use cases (Create Role, Grant Role, Revoke Role, Access Resource) and show what commands are executed and what happens as a result. This is not just for reviewers' sake, but also for doc writers (and blog writers :)) The example you have is useful for understanding the spec, but not necessarily so useful for understanding the common use cases. That's true; the spec could have some more examples, I'll see what I can come up with. - What is the motivation to choose not to support a default role when a user signs in. Alternately, if a user is granted roles A and B, why not given them the union of the two privileges for role A and B. Why does the user have to select the role they want to have for a given session? That seems counter-intuitive. The roles are mutually exclusive; max one role can be set for a session at any one time, according to the standard. This can be worked around by creating a role containing several other roles, if desired. RBAC (http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf) lists the possibility to make roles be mutually exclusive as desirable a feature (separation of duty), see for example the discussion in http://csrc.nist.gov/rbac/RBAC_DBMS_Comparison.pdf. The SQL standard could be said to support dynamic separation of duty since only one role can be set at a time. If this was the design rationale of the standard, though, I don't know.. As for having a default role on connect, that could be added later. This is implementation defined behavior, according to SQL std. It is not my itch right now, since I am trying to limit the work in a first increment, but I can see that it could be useful. If a user has been granted more than one role, we would need to be able to specify somehow which role (or none) to auto-set on connection. As for counter-intuitive, I am not sure that's necessarily the case, running with max privileges isn't always what one wants, cf existence of sudo(1). Thanks, Dag
[jira] Commented: (DERBY-3077) Trying to reconnect with derby client after bringing server down throws SQL Exception 58009 rather than 08XXX exception
[ https://issues.apache.org/jira/browse/DERBY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528122 ] Kathey Marsden commented on DERBY-3077: --- Looking at the 58009 exceptions. I think the first 6 should be 08006: String DRDA_CONNECTION_TERMINATED = 58009.C; // Use this version of SOCKET_EXCEPTION any time *except* when trying to // establish a connection, as the SQLState is different. When trying // to establish a connection, use CONNECT_SOCKET_EXCEPTION. String SOCKET_EXCEPTION = 58009.C.2; String COMMUNICATION_ERROR = 58009.C.3; String CONNECTION_FAILED_ON_DEFERRED_RESET = 58009.C.4; String NET_INSUFFICIENT_DATA= 58009.C.5; String NET_LOB_DATA_TOO_LARGE_FOR_JVM = 58009.C.6; The following would remain 58009 as they are DRDA protocol exceptions: String NET_SQLCDTA_INVALID_FOR_RDBCOLID = 58009.C.7; String NET_SQLCDTA_INVALID_FOR_PKGID= 58009.C.8; String NET_PGNAMCSN_INVALID_AT_SQLAM= 58009.C.9; String NET_VCM_VCS_LENGTHS_INVALID = 58009.C.10; String NET_ENCODING_NOT_SUPPORTED = 58009.C.11; String NET_NOT_EXPECTED_CODEPOINT = 58009.C.12; String NET_DDM_COLLECTION_TOO_SMALL = 58009.C.13; String NET_COLLECTION_STACK_NOT_EMPTY = 58009.C.14; String NET_DSS_NOT_ZERO = 58009.C.15; String NET_DSS_CHAINED_WITH_SAME_ID = 58009.C.16; String NET_PREMATURE_EOS_DISCONNECT = 58009.C.17; String NET_INVALID_FDOCA_ID = 58009.C.18; String NET_SECTKN_NOT_RETURNED = 58009.C.19; String NET_NVCM_NVCS_BOTH_NON_NULL = 58009.C.20; String NET_SQLCDTA_INVALID_FOR_RDBNAM = 58009.C.21; Does that sound correct? Trying to reconnect with derby client after bringing server down throws SQL Exception 58009 rather than 08XXX exception --- Key: DERBY-3077 URL: https://issues.apache.org/jira/browse/DERBY-3077 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.2.2.0 Reporter: Kathey Marsden Assignee: Kathey Marsden This issue was discussed in DERBY-401, because the case where the server is brought down and an application tries to reconnect does not throw a SQLNonTransientException. Discussion is still underway about whether 58XXX exceptions should be SQLNonTransientExceptions, but at least for this case changing the exception to 08006 per Knut's suggestion should correct the problem for this case. See https://issues.apache.org/jira/browse/DERBY-401#action_12527400 Below is current stack and test case. Apache Derby got connection now sleep now try to use the connection after you killed the nS Exception in thread main java.sql.SQLException: A communications error has been detected: Software caused connection abort: recv failed. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source) at org.apache.derby.client.am.LogicalConnection.prepareStatement(Unknown Source) at DerbyClientNonXA.main(DerbyClientNonXA.java:48) Caused by: org.apache.derby.client.am.DisconnectException: A communications error has been detected: Software caused connection abort: recv failed. at org.apache.derby.client.net.NetAgent.throwCommunicationsFailure(Unknown Source) at org.apache.derby.client.net.Reply.fill(Unknown Source) at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown Source) at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source) at org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown Source) at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown Source) at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown Source) at org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInputOutput(Unknown Source) at
[jira] Commented: (DERBY-2967) Single character does not match high value unicode character with collation TERRITORY_BASED
[
https://issues.apache.org/jira/browse/DERBY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528131
]
Kathey Marsden commented on DERBY-2967:
---
Mamta, will running with Sun JVM's cause the existing functionality to regress
in some way or will it just mean that the bug you are fixing won't be fixed
when running with Sun JVM's?
Single character does not match high value unicode character with collation
TERRITORY_BASED
---
Key: DERBY-2967
URL: https://issues.apache.org/jira/browse/DERBY-2967
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.4.0.0
Reporter: Kathey Marsden
Assignee: Mamta A. Satoor
Attachments: step1_iteratorbased_Sep1507_diff.txt,
step1_iteratorbased_Sep1507_stat.txt, temp_diff.txt, temp_stat.txt,
TestFrench.java, TestNorway.java
With TERRITORY_BASED collation '_' does not match the character \uFA2D. It
is the same for english or norwegian. FOR collation UCS_BASIC it matches
fine. Could you tell me if this is a bug?
Here is a program to reproduce.
import java.sql.*;
public class HighCharacter {
public static void main(String args[]) throws Exception
{
System.out.println(\n Territory no_NO);
Class.forName(org.apache.derby.jdbc.EmbeddedDriver);
Connection conn =
DriverManager.getConnection(jdbc:derby:nordb;create=true;territory=no_NO;collation=TERRITORY_BASED);
testLikeWithHighestValidCharacter(conn);
conn.close();
System.out.println(\n Territory en_US);
conn =
DriverManager.getConnection(jdbc:derby:endb;create=true;territory=en_US;collation=TERRITORY_BASED);
testLikeWithHighestValidCharacter(conn);
conn.close();
System.out.println(\n Collation USC_BASIC);
conn = DriverManager.getConnection(jdbc:derby:basicdb;create=true);
testLikeWithHighestValidCharacter(conn);
}
public static void testLikeWithHighestValidCharacter(Connection conn) throws
SQLException {
Statement stmt = conn.createStatement();
try {
stmt.executeUpdate(drop table t1);
}catch (SQLException se)
{// drop failure ok.
}
stmt.executeUpdate(create table t1(c11 int));
stmt.executeUpdate(insert into t1 values 1);
// \uFA2D - the highest valid character according to
// Character.isDefined() of JDK 1.4;
PreparedStatement ps =
conn.prepareStatement(select 1 from t1 where '\uFA2D' like ?);
String[] match = { %, _, \uFA2D };
for (int i = 0; i match.length; i++) {
System.out.println(select 1 from t1 where '\\uFA2D' like + match[i]);
ps.setString(1, match[i]);
ResultSet rs = ps.executeQuery();
if( rs.next() rs.getString(1).equals(1))
System.out.println(PASS);
else System.out.println(FAIL: no match);
rs.close();
}
}
}
Mamta made some comments on this issue in the following thread:
http://www.nabble.com/Single-character-does-not-match-high-value-unicode-character-with-collation-TERRITORY_BASED.-Is-this-a-bug-tf4118767.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Question about next() and previous() on CollationElementIterator.
Mamta Satoor [EMAIL PROTECTED] writes: I did a little more testing with next() and previous() on CollationElementIterator with Sun's jdk 14 and IBM's jdk 14. It appears that the problem happens with Sun's jdk when a character has more than one collation element associated with it. For instance, when I get CollationElementIterator for a(it has only one collation element associated with it) and do next() and previous() on it, it behaves as expected which is next() and previous() both return the same collation element both with Sun's jdk14 and IBM's jdk14. But when I get CollationElementIterator for \uFA2D(it has 2 collation elements associated with it) and do next() and previous() on it, it does not behave correctly under Sun's jdk14. It appears that Sun's jdk treats the previous() as next() when there is more than one collation element associated with a character. IBM's jdk14 returns the same collation element for next() and previous() on CollationElementIterator for \uFA2D Is there a way to followup this problem with Sun's JDK group? Hi Mamta, Seems like they've already been made aware of this thread. Please see http://bugs.sun.com/view_bug.do?bug_id=6603190. Thanks for investigating the issue! -- Knut Anders
Re: Roles for Derby - draft spec uploaded
On 9/17/07, Dag H. Wanvik [EMAIL PROTECTED] wrote: As for having a default role on connect, that could be added later. This is implementation defined behavior, according to SQL std. Where does the standard say that? I see in section 4.37.2 the sentence: An SQL-session initially has no SQL-session role name. David Van Couvering wrote: Are you saying that with what you're proposing, if you're granted only one role, then that's the role you would have when you connect a session? If not, shouldn't that be pretty easy to do? I see your point about sudo, but if I have only *one* role then why shouldn't that be the role I get? According to my [quick] reading of the standard a SQL session initially does not have a role associated with it. I can just hear myself cursing every time I have to type in SET ROLE admin before I can get any work done through my admin UI. There's nothing to stop a tool determining if a user has a single role and then executing a SET ROLE before it opens its admin UI. Dan.
Re: attention documentation experts
Kim Haase wrote: Hi, Rick, I'll be happy to give these a docs-eye once-over. I'll post review comments in a couple days if that's okay. Kim Rick Hillegas wrote: I have clipped a docs patch to DERBY-3072. This is a first cut of user documentation for Function Tables. I would appreciate feedback from the experts! Thanks, -Rick Thanks, Kim!
Re: Question about next() and previous() on CollationElementIterator.
Thanks for the info on bug, Knut and thanks to the person who entered the bug. I updated that bug with brief info on what I found with further testing. Mamta On 9/17/07, Knut Anders Hatlen [EMAIL PROTECTED] wrote: Mamta Satoor [EMAIL PROTECTED] writes: I did a little more testing with next() and previous() on CollationElementIterator with Sun's jdk 14 and IBM's jdk 14. It appears that the problem happens with Sun's jdk when a character has more than one collation element associated with it. For instance, when I get CollationElementIterator for a(it has only one collation element associated with it) and do next() and previous() on it, it behaves as expected which is next() and previous() both return the same collation element both with Sun's jdk14 and IBM's jdk14. But when I get CollationElementIterator for \uFA2D(it has 2 collation elements associated with it) and do next() and previous() on it, it does not behave correctly under Sun's jdk14. It appears that Sun's jdk treats the previous() as next() when there is more than one collation element associated with a character. IBM's jdk14 returns the same collation element for next() and previous() on CollationElementIterator for \uFA2D Is there a way to followup this problem with Sun's JDK group? Hi Mamta, Seems like they've already been made aware of this thread. Please see http://bugs.sun.com/view_bug.do?bug_id=6603190. Thanks for investigating the issue! -- Knut Anders
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Lance J. Andersen wrote: Kathey Marsden wrote: There was a discussion started in DERBY-401 on this but I thought I would submit it as a separate thread. The JDBC 4.0 spec says in section 8.5.1.. A NonTransient SQLException must extend the class SQLNonTransientException. A NonTransient SQLException would be thrown in instances where a retry of the same operation would fail unless the cause of the SQLException is corrected. After a NonTransient SQLException occurs, the application can assume that the connection is still valid. For SQLState class values that indicate non-transient errors but which are not specified in the following table, an implementation may throw an instance of the class SQLNonTransientException. TABLE 8-1 specifies which NonTransientSQLException subclass must be thrown for a a given SQLState class value: TABLE 8-1 NonTransientSQLExeceptions Subclasses SQL State Class SQLNonTransientException Subclass . 08 SQLNonTransientConnectionException . Derby has quite a few exceptions which are SESSION_SEVERITY or greater which are not SQLState Class '08'. These exception cause loss of connection by the application. There is a list at the bottom of this mail. I thought all of these should be SQLNonTransientConnectionExceptions, SQLNonTransientConnectionException aligns with SQL State class value 08 from 23.1, table 32 of the sql2003 spec. Thank you Lance for looking at this. The DRDA Spec section 8.1 defines SQLState mappings to 58XXX which don't fall into table 32 and would seem to conflict with the 08006 exceptions. Any thoughts on what to do with these? Kathey
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Kathey Marsden wrote: Lance J. Andersen wrote: Kathey Marsden wrote: There was a discussion started in DERBY-401 on this but I thought I would submit it as a separate thread. The JDBC 4.0 spec says in section 8.5.1.. A NonTransient SQLException must extend the class SQLNonTransientException. A NonTransient SQLException would be thrown in instances where a retry of the same operation would fail unless the cause of the SQLException is corrected. After a NonTransient SQLException occurs, the application can assume that the connection is still valid. For SQLState class values that indicate non-transient errors but which are not specified in the following table, an implementation may throw an instance of the class SQLNonTransientException. TABLE 8-1 specifies which NonTransientSQLException subclass must be thrown for a a given SQLState class value: TABLE 8-1 NonTransientSQLExeceptions Subclasses SQL State Class SQLNonTransientException Subclass . 08 SQLNonTransientConnectionException . Derby has quite a few exceptions which are SESSION_SEVERITY or greater which are not SQLState Class '08'. These exception cause loss of connection by the application. There is a list at the bottom of this mail. I thought all of these should be SQLNonTransientConnectionExceptions, SQLNonTransientConnectionException aligns with SQL State class value 08 from 23.1, table 32 of the sql2003 spec. Thank you Lance for looking at this. The DRDA Spec section 8.1 defines SQLState mappings to 58XXX which don't fall into table 32 and would seem to conflict with the 08006 exceptions. Any thoughts on what to do with these? I have not looked at the DRDA spec, but i was puzzled by the mapping based on table 32. I really cannot do specific mappings for specs like DRDA in JDBC or I have to do the same for other protocols such as TDS. I just do not see where DRDA came up with 58 as a valid class value? Of course, it could be buried in another chapter of SQL2003 in another document. regards lance Kathey
[jira] Commented: (DERBY-2235) Server doesnt support timestamps with timezone
[ https://issues.apache.org/jira/browse/DERBY-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528119 ] Daniel John Debrunner commented on DERBY-2235: -- If one took the string ''2007-01-03 04:13:43.006 -0800' as equivalent to a TIMESTAMP WITH TIME ZONE value then following the SQL Standard (section 4.6.2) then a conversion to a TIMESTAMP WITHOUT TIME ZONE (which is what Derby supports) will always result in: 2007-01-03 04:13:43.006 regardless of any server time zone. TIMESTAMP WITH TIME ZONE - TIMESTAMP WITHOUT TIME ZONE = SV.UTC + SV.TZ SV is the value to be converted, in this case the string which is broken into two logical parts: SV.UTC = 2007-01-03 12:13:43.006(universal time) SV.TZ = -0800 (offset from universal time) SV.UTC + SV.TZ = 2007-01-03 04:13:43.006 Server doesnt support timestamps with timezone -- Key: DERBY-2235 URL: https://issues.apache.org/jira/browse/DERBY-2235 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.2.2.0 Reporter: Ken Johanson Priority: Minor DML with datetime literals having timzone offset data (ISO-8601): update tbl set dt1 = '2007-01-03 04:13:43.006 -0800' Causes: SQLException: The syntax of the string representation of a datetime value is incorrect. Error: -1 SQLSTATE: 22007 I believe that even if the storage does not (does it?) support timezone storage, the input of a TZ could be normalized (offset applied) to the default TZ. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2998) Add support for ROW_NUMBER() window function
[ https://issues.apache.org/jira/browse/DERBY-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528142 ] Knut Anders Hatlen commented on DERBY-2998: --- Perhaps you need to update ResultSetNode.isOrderedOn() or some of its overrides? Add support for ROW_NUMBER() window function Key: DERBY-2998 URL: https://issues.apache.org/jira/browse/DERBY-2998 Project: Derby Issue Type: Sub-task Components: SQL Reporter: Thomas Nielsen Assignee: Thomas Nielsen Priority: Minor Attachments: row_number_prototype-2.diff, row_number_prototype-2.stat As part of implementing the overall OLAP Operations features of SQL (DERBY-581), implement the ROW_NUMBER() window function. More information about this feature is available at http://wiki.apache.org/db-derby/OLAPRowNumber -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Kathey Marsden wrote: Lance J. Andersen wrote: Kathey Marsden wrote: There was a discussion started in DERBY-401 on this but I thought I would submit it as a separate thread. The JDBC 4.0 spec says in section 8.5.1.. A NonTransient SQLException must extend the class SQLNonTransientException. A NonTransient SQLException would be thrown in instances where a retry of the same operation would fail unless the cause of the SQLException is corrected. After a NonTransient SQLException occurs, the application can assume that the connection is still valid. For SQLState class values that indicate non-transient errors but which are not specified in the following table, an implementation may throw an instance of the class SQLNonTransientException. TABLE 8-1 specifies which NonTransientSQLException subclass must be thrown for a a given SQLState class value: TABLE 8-1 NonTransientSQLExeceptions Subclasses SQL State Class SQLNonTransientException Subclass . 08 SQLNonTransientConnectionException . Derby has quite a few exceptions which are SESSION_SEVERITY or greater which are not SQLState Class '08'. These exception cause loss of connection by the application. There is a list at the bottom of this mail. I thought all of these should be SQLNonTransientConnectionExceptions, SQLNonTransientConnectionException aligns with SQL State class value 08 from 23.1, table 32 of the sql2003 spec. Thank you Lance for looking at this. The DRDA Spec section 8.1 defines SQLState mappings to 58XXX which don't fall into table 32 and would seem to conflict with the 08006 exceptions. Any thoughts on what to do with these? perhaps it is worth going back to DRDA and asking them where/how they came up with that class value? As far as what to do, unless you decide to map the DRDA states to the appropriate SQL Class value, i would return a SQLException. Also, we probably should not be returning this via SQLException.getSQLState() unless we can figure out how/where DRDA is getting the sql class value? Kathey
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Kathey Marsden wrote:
There was a discussion started in DERBY-401 on this but I thought I
would submit it as a separate thread. The JDBC 4.0 spec says in
section 8.5.1..
A NonTransient SQLException must extend the class
SQLNonTransientException. A NonTransient SQLException would be thrown
in instances where a retry of the same operation would fail unless the
cause of the
SQLException is corrected. After a NonTransient SQLException occurs, the
application can assume that the connection is still valid. For
SQLState class values
that indicate non-transient errors but which are not specified in the
following table,
an implementation may throw an instance of the class
SQLNonTransientException.
TABLE 8-1 specifies which NonTransientSQLException subclass must be
thrown
for a a given SQLState class value:
TABLE 8-1 NonTransientSQLExeceptions Subclasses
SQL State Class SQLNonTransientException Subclass
.
08 SQLNonTransientConnectionException
.
Derby has quite a few exceptions which are SESSION_SEVERITY or greater
which are not SQLState Class '08'. These exception cause loss of
connection by the application. There is a list at the bottom of this
mail. I thought all of these should be
SQLNonTransientConnectionExceptions,
SQLNonTransientConnectionException aligns with SQL State class value 08
from 23.1, table 32 of the sql2003 spec.
because the cause loss of the connection, but according to the spec I
suppose they should be just SQLNonTransientExceptions (right now they
are thrown as regular SQLExceptions).
The higher level categories categories are there for grouping and to
allow programmers to just catch the higher level exception if they do
not care about specifics. There are multiple subclasses for Connection
failures defined in table 32, sounds like you might not be reporting the
correct SQLState class and sub class values today.
You need to err on the side of caution if you just start mapping your
errors to non-predefined JDBC SQLException subclasses based on the
class value as you could have to change them later down the road if JDBC
spec add them to a different or new subcategory going forward.
With JDBC 4.0 do you still need to look at error codes to determine if
the connection is lost or is the expectation that users will use
isValid() to determine the status of the connection?
Depends on what you are doing there is no one size fits all answer here.
Kathey
Below is the list:
{{08000,Connection closed by unknown interrupt.,4},
{08001,A connection could not be established because
the security token is larger than the maximum allowed by the network
protocol.,4},
{08001,A connection could not be established because
the user id has a length of zero or is larger than the maximum allowed
by the network protocol.,4},
{08001,A connection could not be established because
the password has a length of zero or is larger than the maximum
allowed by the network protocol.,4},
{08001,Required Derby DataSource property {0} not
set.,4},
{08001,{0} : Error connecting to server {1} on port {2}
with message {3}.,4},
{08001,SocketException: '{0}',4},
{08001,Unable to open stream on socket: '{0}'.,4},
{08001,User id length ({0}) is outside the range of 1
to {1}.,4},
{08001,Password length ({0}) is outside the range of 1
to {1}.,4},
{08001,User id can not be null.,4},
{08001,Password can not be null.,4},
{08001,A connection could not be established because
the database name '{0}' is larger than the maximum length allowed by
the network protocol.,4},
{08003,No current connection.,4},
{08003,getConnection() is not valid on a closed
PooledConnection.,4},
{08003,Lob method called after connection was
closed,4},
{08003,The underlying physical connection is stale or
closed.,4},
{08004,Connection refused : {0},4},
{08004,Connection authentication failure occurred.
Reason: {0}.,4},
{08004,The connection was refused because the database
{0} was not found.,4},
{08004,Database connection refused.,4},
{08004,User '{0}' cannot shut down database '{1}'. Only
the database owner can perform this operation.,4},
{08004,User '{0}' cannot (re)encrypt database '{1}'.
Only the database owner can perform this operation.,4},
{08004,User '{0}' cannot hard upgrade database '{1}'.
Only the database owner can perform this operation.,4},
{08004,Connect refused to database '{0}' because it is
in replication slave mode.,4},
{08006,An error occurred during connect reset and the
connection has been terminated. See chained exceptions for
details.,4},
[jira] Commented: (DERBY-2680) Reference manual section Setting attributes.. lacks upgrade=true attribute
[ https://issues.apache.org/jira/browse/DERBY-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528176 ] Dag H. Wanvik commented on DERBY-2680: -- +1 to commit. Reference manual section Setting attributes.. lacks upgrade=true attribute Key: DERBY-2680 URL: https://issues.apache.org/jira/browse/DERBY-2680 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.2.2.0 Reporter: Dag H. Wanvik Assignee: Kim Haase Priority: Minor Attachments: DERBY-2680-2.diff, DERBY-2680.diff, rrefattribupgrade-2.html, rrefattribupgrade.html The reference manual has a section entitled Setting attributes for the database connection URL (rrefattrib24612.dita). Explanation for the full upgrade (upgrade=true) attribute is missing from this section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: attention documentation experts
Hi, Rick, I'll be happy to give these a docs-eye once-over. I'll post review comments in a couple days if that's okay. Kim Rick Hillegas wrote: I have clipped a docs patch to DERBY-3072. This is a first cut of user documentation for Function Tables. I would appreciate feedback from the experts! Thanks, -Rick
[jira] Updated: (DERBY-2680) Reference manual section Setting attributes.. lacks upgrade=true attribute
[ https://issues.apache.org/jira/browse/DERBY-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-2680: - Attachment: rrefattribupgrade-2.html DERBY-2680-2.diff Attaching revised diff and HTML files. In the source, did some formatting cleanup and removed the question mark and bracketed question from one paragraph. The fixed paragraph is all that shows in the HTML. This means the patch should be ready to commit if it's been sufficiently reviewed (although we don't have an absolutely final answer to the question about using the territory attribute at upgrade). Reference manual section Setting attributes.. lacks upgrade=true attribute Key: DERBY-2680 URL: https://issues.apache.org/jira/browse/DERBY-2680 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6, 10.2.2.0 Reporter: Dag H. Wanvik Assignee: Kim Haase Priority: Minor Attachments: DERBY-2680-2.diff, DERBY-2680.diff, rrefattribupgrade-2.html, rrefattribupgrade.html The reference manual has a section entitled Setting attributes for the database connection URL (rrefattrib24612.dita). Explanation for the full upgrade (upgrade=true) attribute is missing from this section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Lance J. Andersen wrote: perhaps it is worth going back to DRDA and asking them where/how they came up with that class value? I put a query into the one DRDA contact I have but unfortunately he is out for a few weeks. Perhaps Rick knows someone who could answer where class 58 came from. Kathey
[jira] Commented: (DERBY-3033) select query results in nullpointer exception in skipScan()
[ https://issues.apache.org/jira/browse/DERBY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528179 ] Bryan Pendleton commented on DERBY-3033: I removed the mysterious if statement from BaseActivation.getColumnFromRow(), and ran all the regression tests. There were two failures, but I'm not sure if they were due to this change or not. I'll investigate them further. I did *not* get any NullPointerException messages, which is what I was sort of expecting to see. So if removing the if statement from BaseActivation.java fixes this problem, it apparently isn't going to cause a whole lot of other problems. I think the next step is to investigate whether removing the if statement makes the repro script pass. select query results in nullpointer exception in skipScan() --- Key: DERBY-3033 URL: https://issues.apache.org/jira/browse/DERBY-3033 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.2.0 Environment: Windows XP, Java 5.0, JDBC, Derby 10.2.2.0 Reporter: Haolan Qin Attachments: bug4736.sql, d3033-sane-ij-session-10.3.1.5.txt, query_plan.new, query_plan.old, test.rar, test.zip, viewer_10_1.zip The following error was repeatedly thrown when we tried to run a select query via JDBC. Strangely, the exact same select query did not trigger any error when run from the command line console. After we added an index, the error went away completely. java.lang.NullPointerException at org.apache.derby.impl.sql.execute.NoPutResultSetImpl.skipScan(Unknown Source) at org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.JoinResultSet.openRight(Unknown Source) at org.apache.derby.impl.sql.execute.JoinResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown Source) at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.drda.DRDAStatement.execute(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Kathey Marsden wrote: Lance J. Andersen wrote: perhaps it is worth going back to DRDA and asking them where/how they came up with that class value? I put a query into the one DRDA contact I have but unfortunately he is out for a few weeks. Perhaps Rick knows someone who could answer where class 58 came from. 58 is a valid implementation-defined subclass SQLState. All that DRDA has done is defined its own SQL state values that the SQL Standard guarantees it will not use. Dan.
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Daniel John Debrunner wrote: Kathey Marsden wrote: Lance J. Andersen wrote: perhaps it is worth going back to DRDA and asking them where/how they came up with that class value? I put a query into the one DRDA contact I have but unfortunately he is out for a few weeks. Perhaps Rick knows someone who could answer where class 58 came from. 58 is a valid implementation-defined subclass SQLState. All that DRDA has done is defined its own SQL state values that the SQL Standard guarantees it will not use. So then what should the relationship be between the 58 class exceptions and SQLNonTransientConnectionException. Is it wrong for a user to expect a SQLNonTransientConnectionException to be thrown whenever there is a bad connection? Kathey
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
Yes, I see that now on a second pass at section 23. However, to answer Kathy's question, no, the SQL Class Values used for JDBC SQLExceptions were defined around the standard SQL class values, not implementation defined class values. Perhaps we can consider extending this in JDBC 4.1, but for now i would just return a SQLException. Daniel John Debrunner wrote: Kathey Marsden wrote: Lance J. Andersen wrote: perhaps it is worth going back to DRDA and asking them where/how they came up with that class value? I put a query into the one DRDA contact I have but unfortunately he is out for a few weeks. Perhaps Rick knows someone who could answer where class 58 came from. 58 is a valid implementation-defined subclass SQLState. All that DRDA has done is defined its own SQL state values that the SQL Standard guarantees it will not use. Dan.
Re: SQLNonTransientConnectionExceptions and SESSION_SEVERITY exceptions that are not '08XXX' spec clarification
The XS and XB errors come from the old scheme where severity was totally
expected to be handled by the x.SEVERITY system. On quick scan they
are mostly not expected to happen errors marked session level. Can we
just wrap any session level severity error into an 08 number (maybe
chain is the right term - don't want to lose the original error), and
then make it a SQLNonTransientConnectionException.
I assume there is one place in the code as these errors have to already
be wrapped as they start as StandardExceptions internally and have to be
wrapped before they can be sent out over jdbc.
/mikem
Kathey Marsden wrote:
There was a discussion started in DERBY-401 on this but I thought I
would submit it as a separate thread. The JDBC 4.0 spec says in section
8.5.1..
A NonTransient SQLException must extend the class
SQLNonTransientException. A NonTransient SQLException would be thrown
in instances where a retry of the same operation would fail unless the
cause of the
SQLException is corrected. After a NonTransient SQLException occurs, the
application can assume that the connection is still valid. For SQLState
class values
that indicate non-transient errors but which are not specified in the
following table,
an implementation may throw an instance of the class
SQLNonTransientException.
TABLE 8-1 specifies which NonTransientSQLException subclass must be thrown
for a a given SQLState class value:
TABLE 8-1 NonTransientSQLExeceptions Subclasses
SQL State Class SQLNonTransientException Subclass
.
08 SQLNonTransientConnectionException
.
Derby has quite a few exceptions which are SESSION_SEVERITY or greater
which are not SQLState Class '08'. These exception cause loss of
connection by the application. There is a list at the bottom of this
mail. I thought all of these should be
SQLNonTransientConnectionExceptions, because the cause loss of the
connection, but according to the spec I suppose they should be just
SQLNonTransientExceptions (right now they are thrown as regular
SQLExceptions).
With JDBC 4.0 do you still need to look at error codes to determine if
the connection is lost or is the expectation that users will use
isValid() to determine the status of the connection?
Kathey
Below is the list:
{{08000,Connection closed by unknown interrupt.,4},
{08001,A connection could not be established because the
security token is larger than the maximum allowed by the network
protocol.,4},
{08001,A connection could not be established because the
user id has a length of zero or is larger than the maximum allowed by
the network protocol.,4},
{08001,A connection could not be established because the
password has a length of zero or is larger than the maximum allowed by
the network protocol.,4},
{08001,Required Derby DataSource property {0} not
set.,4},
{08001,{0} : Error connecting to server {1} on port {2}
with message {3}.,4},
{08001,SocketException: '{0}',4},
{08001,Unable to open stream on socket: '{0}'.,4},
{08001,User id length ({0}) is outside the range of 1 to
{1}.,4},
{08001,Password length ({0}) is outside the range of 1 to
{1}.,4},
{08001,User id can not be null.,4},
{08001,Password can not be null.,4},
{08001,A connection could not be established because the
database name '{0}' is larger than the maximum length allowed by the
network protocol.,4},
{08003,No current connection.,4},
{08003,getConnection() is not valid on a closed
PooledConnection.,4},
{08003,Lob method called after connection was
closed,4},
{08003,The underlying physical connection is stale or
closed.,4},
{08004,Connection refused : {0},4},
{08004,Connection authentication failure occurred.
Reason: {0}.,4},
{08004,The connection was refused because the database
{0} was not found.,4},
{08004,Database connection refused.,4},
{08004,User '{0}' cannot shut down database '{1}'. Only
the database owner can perform this operation.,4},
{08004,User '{0}' cannot (re)encrypt database '{1}'. Only
the database owner can perform this operation.,4},
{08004,User '{0}' cannot hard upgrade database '{1}'.
Only the database owner can perform this operation.,4},
{08004,Connect refused to database '{0}' because it is in
replication slave mode.,4},
{08006,An error occurred during connect reset and the
connection has been terminated. See chained exceptions for
details.,4},
{08006,Database '{0}' shutdown.,45000},
{0A000,The DRDA command {0} is not currently
implemented. The connection has been terminated.,4},
{57017,There is no available
[jira] Updated: (DERBY-3077) Trying to reconnect with derby client after bringing server down throws SQL Exception 58009 rather than 08XXX exception
[
https://issues.apache.org/jira/browse/DERBY-3077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3077:
--
Attachment: derby-3077_stat.txt
derby-3077_diff.txt
Attached is a patch for this issue. Per Knut's suggestion, it changes
expected client side errors such as SocketExceptions and IOExceptions to throw
08006 exceptions instead of 58 class exceptions.
DRDA_CONNECTION_TERMINATED
SOCKET_EXCEPTION
COMMUNICATION_ERROR
CONNECTION_FAILED_ON_DEFERRED_RESET
NET_INSUFFICIENT_DATA
NET_LOB_DATA_TOO_LARGE_FOR_JVM
This leaves only protocol exceptions in the 58 class.
Please review.
Kathey
Trying to reconnect with derby client after bringing server down throws SQL
Exception 58009 rather than 08XXX exception
---
Key: DERBY-3077
URL: https://issues.apache.org/jira/browse/DERBY-3077
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.2.2.0
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Attachments: derby-3077_diff.txt, derby-3077_stat.txt
This issue was discussed in DERBY-401, because the case where the server is
brought down and an application tries to reconnect does not throw a
SQLNonTransientException. Discussion is still underway about whether 58XXX
exceptions should be SQLNonTransientExceptions, but at least for this case
changing the exception to 08006 per Knut's suggestion should correct the
problem for this case. See
https://issues.apache.org/jira/browse/DERBY-401#action_12527400
Below is current stack and test case.
Apache Derby
got connection now sleep
now try to use the connection after you killed the nS
Exception in thread main java.sql.SQLException: A communications error has
been detected: Software caused connection abort: recv failed.
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.client.am.Connection.prepareStatement(Unknown Source)
at org.apache.derby.client.am.LogicalConnection.prepareStatement(Unknown
Source)
at DerbyClientNonXA.main(DerbyClientNonXA.java:48)
Caused by: org.apache.derby.client.am.DisconnectException: A communications
error has been detected: Software caused connection abort: recv failed.
at org.apache.derby.client.net.NetAgent.throwCommunicationsFailure(Unknown
Source)
at org.apache.derby.client.net.Reply.fill(Unknown Source)
at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Unknown Source)
at org.apache.derby.client.net.Reply.readDssHeader(Unknown Source)
at org.apache.derby.client.net.Reply.startSameIdChainParse(Unknown Source)
at
org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(Unknown
Source)
at
org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(Unknown
Source)
at
org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(Unknown
Source)
at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Unknown
Source)
at
org.apache.derby.client.am.PreparedStatement.readPrepareDescribeInputOutput(Unknown
Source)
at
org.apache.derby.client.am.PreparedStatement.flowPrepareDescribeInputOutput(Unknown
Source)
at org.apache.derby.client.am.PreparedStatement.prepare(Unknown Source)
at org.apache.derby.client.am.Connection.prepareStatementX(Unknown Source)
... 3 more
Caused by: java.net.SocketException: Software caused connection abort: recv
failed
at java.net.SocketInputStream.read(SocketInputStream.java:129)
... 15 more
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.Statement;
import javax.sql.PooledConnection;
public class DerbyClientNonXA
{
public static void main(String args[]) throws Exception
{
org.apache.derby.jdbc.ClientConnectionPoolDataSource40 ds = new
org.apache.derby.jdbc.ClientConnectionPoolDataSource40();
Connection conn = null;
ds.setDatabaseName(e:\\temp\\sampl127;create=true);
PooledConnection pooledCon = ds.getPooledConnection();
conn = pooledCon.getConnection();
DatabaseMetaData md = conn.getMetaData();
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());
System.out.println(got connection now sleep. Bring down network server.);
Statement st = null;
PreparedStatement ps1 = null;
st = conn.createStatement();
try
{
st.executeUpdate(drop table TAB1);
}
catch (SQLException x)
{
System.out.println(no table exists);
}
Thread.sleep(15000);
System.out.println(now try to use the connection after you killed the nS);
ps1 = conn.prepareStatement(CREATE TABLE TAB1(COL1 INT
Re: Requiring Java 5 compiler
What about requiring jdk1.5 or higher for both building and running for the next release made off of trunk? /mikem Rick Hillegas wrote: I would like to start writing Derby code which makes use of Java 5 features. More specifically: 1) I would like to take advantage of the Java 5 extensions for ease-of-use and stronger type checking. 2) I would like to be able to write regression tests which verify that user-written Java 5 code runs correctly as Derby functions and procedures. Would anyone object to our requiring that developers use a Java 5 or later compiler to build Derby? I believe that we would still require the presence of the 1.4 libraries and the expectation would continue to be that the compiler must compile down to 1.4 classes. Thanks, -Rick
[jira] Commented: (DERBY-3033) select query results in nullpointer exception in skipScan()
[
https://issues.apache.org/jira/browse/DERBY-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528197
]
Bryan Pendleton commented on DERBY-3033:
I played around with the skipScan repro case and confirmed Kathey's suspicion
about
BaseActivation.getColumnFromRow, as follows:
- with the current trunk, the repro case gives me the expected NPE in skipScan.
- with the if statement removed from BaseActivation.getColumnFromRow, the
repro case gives me a NPE which matches the NPE that Kathey posted from the
old bug 4736. So this reproduction case definitely takes the code through a
similar code path as that of bug 4736.
Here's the stack trace I get with the current trunk with the if removed from
getColumnFromRow:
2007-09-18 00:18:51.793 GMT Thread[DRDAConnThread_2,5,main] (XID = 352997),
(SESSIONID = 0), (DATABASE = viewer), (DRDAID =
NF01.B54B-810083792898537651{1}), Failed Statement is: select study_id,
number_of_images from (select distinct st.study_id,
st.number_of_images,dsr.priority,
st.creation_datetime from dicom_send_requests dsr, studies st where
dsr.send_date is null and dsr.workstation_id = ? and
dsr.study_id = st.study_id and not exists ( select 1
from dispatcher_locks where dispatcher_locks.study_id =
st.study_id and dispatcher_locks.workstation_id = ?
and dispatcher_locks.dispatcher_id = ? ) ) temp with 3
parameters begin parameter #1: 4 :end parameter begin parameter #2: 4 :end
parameter begin parameter #3: 100 :end parameter
ERROR 38000: The exception 'java.lang.NullPointerException' was thrown while
evaluating an expression.
at
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:294)
at
org.apache.derby.iapi.error.StandardException.unexpectedUserException(StandardException.java:554)
at
org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:164)
at
org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(TableScanResultSet.java:258)
at
org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.openCore(IndexRowToBaseRowResultSet.java:225)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:168)
at
org.apache.derby.impl.sql.execute.JoinResultSet.openRight(JoinResultSet.java:272)
at
org.apache.derby.impl.sql.execute.JoinResultSet.openCore(JoinResultSet.java:151)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:168)
at
org.apache.derby.impl.sql.execute.SortResultSet.openCore(SortResultSet.java:248)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:168)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(BasicNoPutResultSetImpl.java:248)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:370)
at
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1225)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1649)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1304)
at
org.apache.derby.impl.drda.DRDAStatement.execute(DRDAStatement.java:666)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:824)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:275)
Caused by: java.lang.NullPointerException
at
org.apache.derby.impl.sql.execute.BaseActivation.getColumnFromRow(BaseActivation.java:1317)
at
org.apache.derby.exe.ac601a400fx0115x15fbx3163x9ef86e6e1.e7(Unknown Source)
at
org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:153)
... 16 more
= begin nested exception, level (1) ===
java.lang.NullPointerException
at
org.apache.derby.impl.sql.execute.BaseActivation.getColumnFromRow(BaseActivation.java:1317)
at
org.apache.derby.exe.ac601a400fx0115x15fbx3163x9ef86e6e1.e7(Unknown Source)
at
org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:153)
at
org.apache.derby.impl.sql.execute.TableScanResultSet.openCore(TableScanResultSet.java:258)
at
org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.openCore(IndexRowToBaseRowResultSet.java:225)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:168)
at
Re: Roles for Derby - draft spec uploaded
Daniel John Debrunner [EMAIL PROTECTED] writes: On 9/17/07, Dag H. Wanvik [EMAIL PROTECTED] wrote: As for having a default role on connect, that could be added later. This is implementation defined behavior, according to SQL std. Where does the standard say that? I see in section 4.37.2 the sentence: An SQL-session initially has no SQL-session role name. Ah, yes I knew I had seen that somewhere. I was referring to Annex B Implementation-defined elements, clause 69 b: 69) Subclause 17.1, connect statement: : b) The initial value of the current role name is the null value. I can just hear myself cursing every time I have to type in SET ROLE admin before I can get any work done through my admin UI. There's nothing to stop a tool determining if a user has a single role and then executing a SET ROLE before it opens its admin UI. +1 Dag
Re: Requiring Java 5 compiler
Rick Hillegas [EMAIL PROTECTED] writes: Would anyone object to our requiring that developers use a Java 5 or later compiler to build Derby? I believe that we would still require the presence of the 1.4 libraries and the expectation would continue to be that the compiler must compile down to 1.4 classes. AFAIK, that's not possible in the general case, cf tools like Retroweaver http://retroweaver.sourceforge.net/). Dag
Re: Running the junit testsuite with a remote server
On 9/17/07, Vemund Ostgaard [EMAIL PROTECTED] wrote: I'm interested in running the junit tests with a remote server, but as far as I can see there is no easy way to do so yet. I found two relevant jiras: https://issues.apache.org/jira/browse/DERBY-1973 (Support running JUnit tests directly with a remote server) http://issues.apache.org/jira/browse/DERBY-2638 (Create an option for junit tests to run only client tests) As these are currently unassigned I was thinking of taking a closer look myself. A couple of questions: What interface should be used to instruct the test framework that you want to use a network server (probably started manually) running on a given host portnumber, instead of the default localhost location? And along the same lines, what is the best way to instruct the test framework that you want to run only the client tests (or only the embedded tests)? For choosing to run only a subset of tests, like the client tests, I see a few possibilities: * Create some new top level suite, for instance Suites.client that runs only the client tests. * Set a property (on the commandline) when starting Suites.All (or any other subsuite) that instructs the framework to only run the client tests. * Make it possible to do both of the above. For instructing the framework to use a specific hostname and portnumber instead of the defaults I don't have any good ideas except using properties. The DERBY-1973 report says Ideally this would be through a test decorator and not setting properties on the command line., though. Any suggestions on the best way to solve this? The TestConfiguration class seems to read system properties for framework (embedded or client), hostname and port, but is this code there only to make the tests run under the old harness and intended to be removed when all the tests are converted? Is it likely that all client tests will work with a remote server, or will some tests be written in a way that requires the server(s) to run on the same host as the test framework? Perhaps some tests have to start the networkserver as part of the test, and because of this it has to run on the same host. In this case it would actually be three groups of tests: embedded, local networkserver and remote networkserver. If anyone has given all of this some thought I'd be happy to hear. Vemund Coming from attempting to implement remote server testing in the 'old' test harness, I have some limited input, and little to offer in the way of solutions... Starting to reason from the tests, I think part of the issue is that there are tests that test the correct starting and shutting down of the network server; or that need the server to be started with specific properties as opposed to the 'normal' mode. And as far as I know we cannot start and shutdown a server on a remote machine, and thus these tests cannot run with a remote server. Theoretically, all tests that do not need to test starting/shutting down, or that do not test the server with specific properties set, should, be 'runnable' with remote server that is already running. However, is that really necessary? What things could go wrong when connecting to a remote server versus a server on localhost? I would think mostly things to do with connections, permissions, import/export. So, maybe it makes sense after all to have a dedicated set of tests for remote server testing. Note that with remote server testing, trouble brews in the area of cleanup; I believe the current junit framework attempts to delete files that get created by the server; and I think deleting of files on a remote machine should be impossible. I wasted considerable time with the old test harness trying to identify tests that would run cleanly in sequence; only to find that a previously working set was made to fail because a uncooperative test/testcase was added. It may be better to create a suite of tests, normally part of suites.All, which can/should be run against a remote server as well. For the desire to be able to run all client tests; that is more an efficiency issue useful for someone working on client only changes; when one is certain there is no need to run the tests with embedded. I think maybe a class that travels through the test suites and identifies the ones that run with DerbyNetClient would cover that requirement. The converse could also be true (run only embedded tests), but I believe this can be achieved by excluding derbyclient.jar from the classpath. I have a hard time to imagine how to arrange for a configurable port number and host without using properties in some manner. But I imagine some default values, and/or a scheme to identify existing servers running could be devised. Maybe someone else has good suggestions. Myrna
