[jira] Commented: (DERBY-1484) Client and embedded behave differently when the table name is null in DatabaseMetaData methods
[ https://issues.apache.org/jira/browse/DERBY-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493591 ] Jørgen Løland commented on DERBY-1484: -- DERBY- *must* be committed before this patch! > Client and embedded behave differently when the table name is null in > DatabaseMetaData methods > -- > > Key: DERBY-1484 > URL: https://issues.apache.org/jira/browse/DERBY-1484 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.2.1.6 >Reporter: Knut Anders Hatlen > Assigned To: Jørgen Løland >Priority: Minor > Attachments: DERBY-1484-2.diff, DERBY-1484-2.stat, DERBY-1484-3.diff, > DERBY-1484-3.stat, DERBY-1484.diff, DERBY-1484.stat > > > When giving null as table name to getBestRowIdentifier, getColumnPrivileges, > getIndexInfo, getVersionColumns or getPrimaryKeys, the client driver fails > with "SQLException: Table name can not be null". Embedded uses null as a > wildcard and does not fail. Embedded and client should have the same > behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1484) Client and embedded behave differently when the table name is null in DatabaseMetaData methods
[ https://issues.apache.org/jira/browse/DERBY-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-1484: - Derby Info: [Patch Available] Changes undocumented functionality to behave according to specification. Hence, I do not think a release note is required. > Client and embedded behave differently when the table name is null in > DatabaseMetaData methods > -- > > Key: DERBY-1484 > URL: https://issues.apache.org/jira/browse/DERBY-1484 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.2.1.6 >Reporter: Knut Anders Hatlen > Assigned To: Jørgen Løland >Priority: Minor > Attachments: DERBY-1484-2.diff, DERBY-1484-2.stat, DERBY-1484-3.diff, > DERBY-1484-3.stat, DERBY-1484.diff, DERBY-1484.stat > > > When giving null as table name to getBestRowIdentifier, getColumnPrivileges, > getIndexInfo, getVersionColumns or getPrimaryKeys, the client driver fails > with "SQLException: Table name can not be null". Embedded uses null as a > wildcard and does not fail. Embedded and client should have the same > behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1484) Client and embedded behave differently when the table name is null in DatabaseMetaData methods
[ https://issues.apache.org/jira/browse/DERBY-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jørgen Løland updated DERBY-1484: - Attachment: DERBY-1484-3.stat DERBY-1484-3.diff The attached patch (3) includes all the changes in (2), and modifies a few harness tests that previously called getExportedKeys and getImportedKeys with table = null. Since only table == null triggers an exception, it is still possible to call these methods with a tablepattern, e.g. table="?". I will create a new issue for changing the internal query to not accept patterns. Derbyall and allsuites run fine except the following (unrelated) fails: allsuites fails two ProcedureInTriggerTests, but these have already been discussed in DERBY-1585 and should not be related to the patch. derbyall fails bootLock (as always here - maybe because of NFS?) > Client and embedded behave differently when the table name is null in > DatabaseMetaData methods > -- > > Key: DERBY-1484 > URL: https://issues.apache.org/jira/browse/DERBY-1484 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.2.1.6 >Reporter: Knut Anders Hatlen > Assigned To: Jørgen Løland >Priority: Minor > Attachments: DERBY-1484-2.diff, DERBY-1484-2.stat, DERBY-1484-3.diff, > DERBY-1484-3.stat, DERBY-1484.diff, DERBY-1484.stat > > > When giving null as table name to getBestRowIdentifier, getColumnPrivileges, > getIndexInfo, getVersionColumns or getPrimaryKeys, the client driver fails > with "SQLException: Table name can not be null". Embedded uses null as a > wildcard and does not fail. Embedded and client should have the same > behaviour. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-2280) DatabaseMetaData.getTypeInfo() UNSIGNED_ATTRIBUTE and AUTO_INCREMENT column returns incorrect information for BLOB & CLOB data type
Thanks a lot Army for your valuable comments & insights. Well currently
I am on vacation (and will be back on 7th May) so I will look into in
next week.
Apart as I will submit a new patch with correct spacing (consistent with
the existing code) and also I 'll follow DERBY-2307 to see whats need to
be done for NULLABILITY.
Saurabh
A B (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493169 ]
A B commented on DERBY-2280:
Thanks for the updated patch, Saurabh.
I ran jdbcapi/DatabaseMetaDataTest with a clean codeline and it passed for me. But as you say, if
I run it with your changes applied the test fails when checking NULLABILITY. The failure occurs
because the nullability of the UNSIGNED_ATTRIBUTE and AUTO_INCREMENT columns becomes
"false" with your changes, wherease it used to be "true".
Without your patch, at least one row in the VALUES clause (actually, two
rows--the row for BLOB and the row for CLOB) has a NULL value for
UNSIGNED_ATTRIBUTE and AUTO_INCREMENT:
('BLOB',2004,2147483647,CAST (NULL AS CHAR),CAST (NULL AS CHAR),'length', \
1,FALSE,0,CAST (NULL AS BOOLEAN),FALSE,CAST (NULL AS BOOLEAN), \
CAST (NULL AS INTEGER),CAST (NULL AS INTEGER),CAST (NULL AS INTEGER)),\
('CLOB',2005,2147483647,,,'length', \
1,TRUE,1,CAST (NULL AS BOOLEAN),FALSE,CAST (NULL AS BOOLEAN), \
CAST (NULL AS INTEGER),CAST (NULL AS INTEGER),CAST (NULL AS INTEGER)), \
Since there is at least one row which is null, the type definition for the corresponding
columns implicitly becomes nullable, and thus we see (before your changes) a NULLABILITY
of "true".
But with your patch applied, every row in the VALUES clause used for
getTypeInfo() returns a constant value (TRUE or FALSE) for UNSIGNED_ATTRIBUTE
and AUTO_INCREMENT:
('BLOB',2004,2147483647,CAST (NULL AS CHAR),CAST (NULL AS
CHAR),'length', \
-1,FALSE,0,CAST (NULL AS BOOLEAN),FALSE,CAST (NULL AS BOOLEAN), \
+1,FALSE,0,TRUE,FALSE,FALSE, \
CAST (NULL AS INTEGER),CAST (NULL AS INTEGER),CAST (NULL AS
INTEGER)),\
('CLOB',2005,2147483647,,,'length', \
-1,TRUE,1,CAST (NULL AS BOOLEAN),FALSE,CAST (NULL AS BOOLEAN), \
+1,TRUE,1,TRUE,FALSE,FALSE, \
CAST (NULL AS INTEGER),CAST (NULL AS INTEGER),CAST (NULL AS
INTEGER)), \
A constant value that is not null implicitly has a type definition that is not nullable. So since
_all_ rows now have a constant value for the UNSIGNED_ATTRIBUTE and AUTO_INCREMENT columns, the
type definitions for those two columns become "not nullable", which translates into a
"false" NULLABILITY.
Hence the failure in DatabaseMetaDataTest.
This difference in behavior is, I think, related to the discussion for DERBY-2307. That issue talks about how the derived nullability of a column for getTypeInfo() is correct for some columns (ex. DATA_TYPE) but incorrect for others (ex. TYPE_NAME). The difference is that all columns which use an explict CAST operand assume a nullability of "true", while a column that has all constants with no CASTs assumes a nullability of "false".
That said, it's not clear to me what the nullability of the AUTO_INCREMENT and
UNSIGNED_ATTRIBUTE columns should be. I posted a question to DERBY-2307; we'll
have to figure that out before we know how to handle the DatabaseMetaDataTest
failure that you are seeing with your patch...
Minor comment on the _v2 patch:
Spacing for the changes to DatabaseMetaDataTest.java are inconsistent. Some of
the new code uses tabs whereas other pieces use spaces. Since the surrounding
(unchanged) code uses 4-space indentation, I think it'd be best to use that for
the new code, as well...
DatabaseMetaData.getTypeInfo() UNSIGNED_ATTRIBUTE and AUTO_INCREMENT column returns
incorrect information for BLOB & CLOB data type
---
Key: DERBY-2280
URL: https://issues.apache.org/jira/browse/DERBY-2280
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 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.0.0
Reporter: Saurabh Vyas
Assigned To: Saurabh Vyas
Priority: Minor
Attachments: Derby-2280.diff, Derby-2280.stat, Derby-2280_v2.diff
getTypeInfo() method should return FALSE for UNSIGNED_ATTRIBUTE and AUTO_INCREMENT
in case of BLOB & CLOB data type.
Currently it returns NULL value.
[jira] Resolved: (DERBY-2501) Batch scripts in bin\ report extraneous errors when DERBY_HOME is invalid
[ https://issues.apache.org/jira/browse/DERBY-2501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew McIntyre resolved DERBY-2501. Resolution: Fixed Derby Info: (was: [Patch Available]) Thanks for the review, John! Committed -javacmd patch with revision 535039. > Batch scripts in bin\ report extraneous errors when DERBY_HOME is invalid > - > > Key: DERBY-2501 > URL: https://issues.apache.org/jira/browse/DERBY-2501 > Project: Derby > Issue Type: Bug > Components: Demos/Scripts >Affects Versions: 10.2.1.6, 10.2.2.0 > Environment: Windows >Reporter: John H. Embretsen > Assigned To: John H. Embretsen >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: d2501_v1.diff, d2501_v2.diff, > derby-2501-check-javacmd.diff > > > If DERBY_HOME is set to an invalid location (for example a directory that > does not contain lib\derby.jar), most .bat scripts in the bin directory (the > ones that call derby_common.bat) report three distinct error messages, of > which only one is of value to the user. > Reproduction: > C:\Derby_10\db-derby-10.2.2.0-bin>set DERBY_HOME=c:\temp > C:\Derby_10\db-derby-10.2.2.0-bin>echo %DERBY_HOME% > c:\temp > C:\Derby_10\db-derby-10.2.2.0-bin>bin\sysinfo > DERBY_HOME is set incorrectly or derby.jar could not be located. Please set > DERBY_HOME. > The system cannot find the batch label specified - end > '""' is not recognized as an internal or external command, > operable program or batch file. > The distinct error messages are: > 1) DERBY_HOME is set incorrectly or derby.jar could not be located. Please > set DERBY_HOME. > 2) The system cannot find the batch label specified - end > 3) '""' is not recognized as an internal or external command, operable > program or batch file. > Only 1) is relevant for the user, and should ideally be the only one > displayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2496) Implement Blob support for Locators
[ https://issues.apache.org/jira/browse/DERBY-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493554 ] Rick Hillegas commented on DERBY-2496: -- Thanks for the new patch, Øystein. Looks good to me and the tests run cleanly. Committed at subversion revision 535027. > Implement Blob support for Locators > --- > > Key: DERBY-2496 > URL: https://issues.apache.org/jira/browse/DERBY-2496 > Project: Derby > Issue Type: Sub-task >Reporter: Øystein Grøvlen > Assigned To: Øystein Grøvlen > Attachments: blob-followup.diff, blob-followup_v2.diff, > blob-followup_v2.diff, blob.diff, blob_v2.diff > > > DERBY-2347 adds the possibility to send locators between client and server > instead of LOB values. This has not been activated yet, since the client > implementation does not currently support locators. This report is for > supporting the locators for Blob objects. Another JIRA issue will be made > for Clob. > This work will be made in several steps: >1. Blob methods and ResultSet.getXXX methods >2. PreparedStatement and CallableStatement methods >3. ResultSet.updateXXX methods >4. Connection.createBlob() > There is dependencies between these steps and it might be that the Locator > implementation cannot be exposed until everything has been done. At least, > doing just step 1, gives testing errors because tests use Blobs fetched from > DB as parameters to prepared statements. I would guess tests for updatable > result sets, needs the combination of 1. and 3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-716) Re-enable VTIs
Rick Hillegas (JIRA) wrote: [ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493550 ] Rick Hillegas commented on DERBY-716: - I searched the Derby codeline for all of the method names in VTIEnvironment. They do not appear to be invoked ... because they would be invoked by an implementation of a virtual table, not the engine itself. Dan.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493553 ] Rick Hillegas commented on DERBY-716: - Maybe the VTICosting instantiator could have a signature like this and it would be up to the implementation to throw a SQLException if there isn't enough information to cost the VTI: public static VTICosting getVTICosting ( String schemaName, // table function's schema as declared at CREATE FUNCTION time String tableFunctionName, // table function's name as declared at CREATE FUNCTION time HashMap functionArguments // key = arg name from CREATE FUNCTION, value = bind() time value, possibly null if bind() can't figure it out ) throws SQLException; > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493551 ] A B commented on DERBY-716: --- Dan> Maybe checking the java types would lead to the same answer, but logically it's a check of Dan> SQL types only. Table functions should follow the same logic as regular functions. Okay. Rick> I hope we are not talking past one another. Oops, I think we were. Thank you both for clarifying... > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493550 ] Rick Hillegas commented on DERBY-716: - I searched the Derby codeline for all of the method names in VTIEnvironment. They do not appear to be invoked anywhere although they are declared in the VTIEnvironment interface itself and in FromVTI and in VTIResultSet. There may be some value in exposing a vacuous VTIEnvironment interface, which has no methods in it but which would be a placeholder for future expansion. I don't see the value in retaining the existing, unused methods. The unused getSharedState() and setSharedState() methods suggest that the whole thing might be replaced with a Hashtable. > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2606) Derby should print the parameters to failed statements to the derby.log when it logs the error
[ https://issues.apache.org/jira/browse/DERBY-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-2606: -- I would like to see this change for as much default behavior as possible. I find trying to support cases I often get a database or derby.log and need to help the user from the data there. Having the parameters can help me help the user a lot. For instance in a recent case posted the user is getting the following error in derby.log: Database Class Loader started - derby.database.classpath='' 2007-05-02 17:41:59.626 GMT Thread [DefaultQuartzScheduler_Worker-1,5,main] (XID = 28872), (SESSIONID = 0), (DATABASE = /opt/jcr/repository/workspaces/default/db), (DRDAID = null), Cleanup action starting 2007-05-02 17:41:59.626 GMT Thread [DefaultQuartzScheduler_Worker-1,5,main] (XID = 28872), (SESSIONID = 0), (DATABASE = /opt/jcr/repository/workspaces/default/db), (DRDAID = null), Failed Statement is: select NODE_DATA from DEFAULT_NODE where NODE_ID = ? What I would like to say to the user is to make a copy of the db, and run this exact query to determine if the error is persistent or runtime, but without the parameter there is no way to know which row is the problem. I am not even sure if check table will find this kind of error. Also note that if params were not being used then the data would have shown up in the log, so if we are concerned about data showing up in derby.log then I believe there is an existing problem. I think that if derby is allowed to print statements it should print the params also. Maybe we need some other option whether it is allowed to print statements at all. > Derby should print the parameters to failed statements to the derby.log when > it logs the error > --- > > Key: DERBY-2606 > URL: https://issues.apache.org/jira/browse/DERBY-2606 > Project: Derby > Issue Type: Improvement > Components: Services >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden > Assigned To: Kathey Marsden >Priority: Minor > > It would be good if when derby dumped an error to derby.log it printed the > parameters for the failed statement. Currently the default behaviour is that > only the statement text will print. Users have to set > derby.language.logStatementText=true if they want to see the parameters. It > would be useful if any errors included the parameters as well as the > statement text. > To reproduce > put derby.stream.error.logSeverityLevel=0 in your derby.properties and run > this script: > connect 'jdbc:derby:wombat;create=true'; > create table t (i int); > prepare p as 'insert into t values(?)'; > execute p using 'values(1)'; > execute p using 'values(1000)'; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493538 ] Daniel John Debrunner commented on DERBY-716: - VTIEnvironment was (is?) meant to be a general purpose class that provides some control over & information for virtual tables, it was meant to be applicable to more than costing, despite it's class javadoc. see how it is used on the other interfaces that are applicable to virtual tables. Keeping the class may allow future expansion, removing it would hinder future expansion. isCompileTime() may provide useful state information if use of this class is expanded in the future, though it may be ok to remove the method, since it could be added back to the class at any time. Removing the class from the methods passed to VTICosting would make it harder to add back in the future. > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2606) Derby should print the parameters to failed statements to the derby.log when it logs the error
[ https://issues.apache.org/jira/browse/DERBY-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493534 ] Daniel John Debrunner commented on DERBY-2606: -- For encrypted databases this would be an issue because the error log is not encrypted, so having user values appear in the log in clear could be undesirable. > Derby should print the parameters to failed statements to the derby.log when > it logs the error > --- > > Key: DERBY-2606 > URL: https://issues.apache.org/jira/browse/DERBY-2606 > Project: Derby > Issue Type: Improvement > Components: Services >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden > Assigned To: Kathey Marsden >Priority: Minor > > It would be good if when derby dumped an error to derby.log it printed the > parameters for the failed statement. Currently the default behaviour is that > only the statement text will print. Users have to set > derby.language.logStatementText=true if they want to see the parameters. It > would be useful if any errors included the parameters as well as the > statement text. > To reproduce > put derby.stream.error.logSeverityLevel=0 in your derby.properties and run > this script: > connect 'jdbc:derby:wombat;create=true'; > create table t (i int); > prepare p as 'insert into t values(?)'; > execute p using 'values(1)'; > execute p using 'values(1000)'; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493533 ] Rick Hillegas commented on DERBY-2605: -- That sounds like a reasonable approach to me. It may turn out that the checks are in the parser right now. What you're proposing may have to happen at bind() time. > You can create BOOLEAN columns in 10.3 > -- > > Key: DERBY-2605 > URL: https://issues.apache.org/jira/browse/DERBY-2605 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.0.0 >Reporter: Rick Hillegas > > The work on DERBY-64 seems to have opened up a wormhole by which you can > create user tables with BOOLEAN columns. The following script shows how to do > this: > drop table foo; > create table foo > as select systemalias from sys.sysaliases with no data; > rename column foo.systemalias to boolcol; > alter table foo > alter column boolcol null; > select c.columndatatype > from sys.syscolumns c, sys.systables t > where t.tableid=c.referenceid > and t.tablename='FOO'; > insert into foo( boolcol ) > values > ( 0 ), > ( 1 ), > ( cast (null as int) ) > ; > select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2508) Implement the XA transaction timeout support for embedded driver.
[ https://issues.apache.org/jira/browse/DERBY-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493531 ] Julius Stroffek commented on DERBY-2508: suites.All and derbyall finished without errors or failures. > Implement the XA transaction timeout support for embedded driver. > - > > Key: DERBY-2508 > URL: https://issues.apache.org/jira/browse/DERBY-2508 > Project: Derby > Issue Type: Sub-task >Affects Versions: 10.2.2.0 >Reporter: Julius Stroffek > Assigned To: Julius Stroffek > Fix For: 10.3.0.0 > > Attachments: d2432_beta1.diff, d2432_beta1.stat, d2508.diff, > d2508.stat, d2508_try2.diff, d2508_try2.stat > > > Implement the XA transaction support for embedded driver in EmbedXAResource. > Implement functions XAResource.setTransactionTimeout and > XAResource.getTransactionTimeout and add the code to cancel the transaction > after the specified period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2606) Derby should print the parameters to failed statements to the derby.log when it logs the error
Derby should print the parameters to failed statements to the derby.log when it logs the error --- Key: DERBY-2606 URL: https://issues.apache.org/jira/browse/DERBY-2606 Project: Derby Issue Type: Improvement Components: Services Affects Versions: 10.3.0.0 Reporter: Kathey Marsden Assigned To: Kathey Marsden Priority: Minor It would be good if when derby dumped an error to derby.log it printed the parameters for the failed statement. Currently the default behaviour is that only the statement text will print. Users have to set derby.language.logStatementText=true if they want to see the parameters. It would be useful if any errors included the parameters as well as the statement text. To reproduce put derby.stream.error.logSeverityLevel=0 in your derby.properties and run this script: connect 'jdbc:derby:wombat;create=true'; create table t (i int); prepare p as 'insert into t values(?)'; execute p using 'values(1)'; execute p using 'values(1000)'; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2603) Minor erratum in page of VARCHAR in Derby Reference manual
[ https://issues.apache.org/jira/browse/DERBY-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493530 ] Kim Haase commented on DERBY-2603: -- There are references to these operators as binary on the following pages: http://db.apache.org/derby/docs/dev/ref/rrefsqlj13733.html (CHAR data type): same sentence as in http://db.apache.org/derby/docs/dev/ref/rrefsqlj41207.html (VARCHAR data type) http://db.apache.org/derby/docs/dev/ref/rrefsqlj1083019.html (Where dynamic parameters are allowed): "5. For the binary operators +, -, *, /, AND, OR, <, >, =, <>, <=, and >=, use of a dynamic parameter as one operand but not both is permitted. Its type is taken from the other side." So the use of "binary" to mean "having two operands" is intentional. But perhaps the word "binary" can simply be removed from rrefsqlj13733 and rrefsqlj41207 -- don't all comparison operators have two operands? If so, "binary" is not necessary to the meaning here. > Minor erratum in page of VARCHAR in Derby Reference manual > -- > > Key: DERBY-2603 > URL: https://issues.apache.org/jira/browse/DERBY-2603 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefsqlj41207.html >Reporter: Tomohito Nakayama >Priority: Minor > > I found next statement in the page through translation into Japanese. > > When binary comparison operators are applied to VARCHARs, the lengths of > > the operands are not altered, and spaces at the end of the values are > > ignored. > I think "binary" should be replaced as "boolean". > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493529 ] Rick Hillegas commented on DERBY-716: - Thanks, Dan and Army, for the continued discussion of the parameters to Function Tables. Army and I seem to be concerned about different issues here. I am not concerned about the type resolution of arguments to the Function Tables. This seems to me to be exactly the same resolution logic which applies to existing (non-table) functions. I am not proposing to change that logic. If the user guides don't adequately describe the type resolution of function arguments, then that is another issue and it is someone else's itch. I am concerned about the fact that certain expressions can appear in the arguments to non-table functions but those expressions can not appear in the arguments to Function Tables. For instance, select * from T, TABLE( foo( T.a ) ) where bar( T.a ) = 3; Here the expression T.a is a legal argument to bar() but not to foo(). I hope we are not talking past one another. > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493525 ] Rick Hillegas commented on DERBY-716: - Thanks for the continued feedback, Dan. > Why is the VTIEnvironment class being removed from the VTICosting interface? > Does it cause issues in some way? I had a couple issues with this class: 1) I don't know what to tell users who want to exploit this argument in their costing logic. The javadoc is not very helpful. In addition I couldn't find any explanation of this class in the Cloudscape 3.5 documentation which I consulted: There the class is mentioned as having been added for future expansion, but the methods are not explained. I could not find any examples of its actually being used by our diagnostic VTIs. 2) One of the methods in this class, isCompileTime(), seems geared toward the old Cloudscape VTIs, which were instantiated twice: at compile-time in order to bind() against the signature of the ResultSet, and at run-time in order to actually loop through the rows. This doesn't fit the ANSI scheme in which the bind() time information is declared when you CREATE the Function Table. > The separation of the creation of the VTICosting object from the creation of > the VTI class means that the costing cannot take into > account the parameters being passed to the table function. Thus it might be > hard for an application developer to have any meaningful > costing information, defeating the whole purpose of the interface. > > It also limits the any class to supporting just one static method that > returns a ResultSet, unless they can all share the same exact costing > information. I'm not happy with the flexibility of VTICosting and I welcome brainstorming on this topic. The signature of the VTICosting instantiator is a tricky issue. Consider the example in my reply to Army above. Here the arguments to the VTI are not known until run time. In fact, they change as the query runs and the VTI is re-instantiated for each row in the outer query block. In this case, what would be the signature of the VTICosting instantiator? For the moment, let's not worry about where we find the VTICosting instantiator. This could be a constructor in the Function Table's class, a distinctively named static method in that class, some other class or method bound to the Function Table via a system procedure, etc.. Instead, let's focus on the signature of the VTICosting instantiator. Here are some possibilities: A) A 0-arg signature. This is essentially what the current spec proposes. B) Some Derby interface like VTIEnvironment. The interface would have to be documented extensively. C) The same signature as the Function Table itself. We would substitute conventional defaults for arguments which could not be computed at bind() time--like ? parameters and correlated column references from outer query blocks. D) A leading prefix of the Function Table's signature. Here we would raise an exception if one of the leading arguments could not be computed at bind() time. What are your thoughts? > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (DERBY-1533) ArrayIndexOutOfBoundsException in DDMReader, on a specific data size
Kathey Marsden closed DERBY-1533. - Thanks Kathey for porting this back! bryan
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493517 ] Daniel John Debrunner commented on DERBY-716: - Still not sure "Java type" is correct. Is that really the rule for deciding if the arguments can be mapped to the parameter type? For regular (non-table) functions and procedures the check is made to see if type of the SQL argument can be stored in the type of the SQL parameter (defined in the routine's CREATE statement). Maybe checking the java types would lead to the same answer, but logically it's a check of SQL types only. Table functions should follow the same logic as regular functions. See this check in StaticMethodCallNode.java if (! getTypeCompiler(parameterTypeId).storable(argumentTypeId, getClassFactory())) throw StandardException.newException(SQLState.LANG_NOT_STORABLE, parameterTypeId.getSQLTypeName(), argumentTypeId.getSQLTypeName() ); > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2333) Convert parameterMapping to JUnit
[ https://issues.apache.org/jira/browse/DERBY-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-2333. --- Resolution: Fixed Test enabled for client with DERBY-2381 checkin. > Convert parameterMapping to JUnit > - > > Key: DERBY-2333 > URL: https://issues.apache.org/jira/browse/DERBY-2333 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden > Assigned To: Kathey Marsden > Fix For: 10.3.0.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2381) ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a procedure
[ https://issues.apache.org/jira/browse/DERBY-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-2381. --- Resolution: Fixed Fix Version/s: 10.3.0.0 Committed revision 534985 > ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a > procedure > --- > > Key: DERBY-2381 > URL: https://issues.apache.org/jira/browse/DERBY-2381 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden > Assigned To: Kathey Marsden > Fix For: 10.3.0.0 > > Attachments: d2381.java, DERBY-2381_diff.txt, DERBY-2381_stat.txt > > > The test ParameterMappingTest fails due to a connection reset error during > tearDown. Commenting out the teardown actions I see that the real cause of > the connection reset is an ArrayIndexOutOfBoundsException executing a > callable statement. I have not narrowed it down more than this. Currently > the test runs only for embedded. It should be reenabled for client once this > bug is fixed. Below is the stack trace: > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107) > at > org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153) > at org.apache.derby.client.net.Reply.fill(Reply.java:165) > at > org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java(Compiled > Code)) > at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) > at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2151) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1571) > at > org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1556) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:487) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.j
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493506 ] A B commented on DERBY-716: --- Oops, thanks. Meant "Java type" in all of these cases, not "JDBC type". > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493503 ] Daniel John Debrunner commented on DERBY-716: - > A table function argument A[i] can be any expression whose corresponding JDBC > type is the same > as the JDBC type which corresponds to the SQL type of the function's declared > parameter P[i]. Why is JDBC being mentioned here? Parameters for table functions are declared as SQL types and table functions are executed in SQL statements. There is no relationship to JDBC. JDBC only defines the mapping of the declared parameter type to the Java type, it does not affect the SQL compilation/binding. > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2602) TIMESTAMP value is truncated when return to client
[
https://issues.apache.org/jira/browse/DERBY-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493502
]
A B commented on DERBY-2602:
Okay, thanks Dan. I couldn't tell from the summary if "getTimestamp()" or
something else was being used. Sorry for the red herring.
> TIMESTAMP value is truncated when return to client
> ---
>
> Key: DERBY-2602
> URL: https://issues.apache.org/jira/browse/DERBY-2602
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.3.0.0
>Reporter: Kathey Marsden
>Priority: Minor
> Attachments: d2602.java
>
>
> In ParameterMappingTest I see the following differences between embedded
> and client. Client is truncating the TIMESTAMP value. Look for this bug
> number in the test for reproduction.
> case java.sql.Types.TIMESTAMP:
> if (param == 2)
> if (usingEmbedded())
> assertEquals("2004-03-12 21:14:24.938222433",
> val.toString());
> else
> assertEquals("2004-03-12 21:14:24.938222",
> val.toString());
> else if (param == 3)
> if (usingEmbedded())
> assertEquals("2004-04-12 04:25:26.462983731",
> val.toString());
> else
> assertEquals("2004-04-12 04:25:26.462983",
> val.toString());
> break;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2602) TIMESTAMP value is truncated when return to client
[
https://issues.apache.org/jira/browse/DERBY-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493500
]
Daniel John Debrunner commented on DERBY-2602:
--
I don't think DERBY-2602 and DERBY-1816 are the same issue.
DERBY-1816 - SQL TIMESTAMP column to java.sql.Time object via RS.getTime() has
a zero milli-seconds value.
DERBY-2602 - SQL TIMESTAMP column to java.sql.Timestamp object via
RS.getTimestamp() has a truncated, but non-zero, nano-seconds value.
If they were the same I would expect 2602 to show a zero value for the
factional second part.
> TIMESTAMP value is truncated when return to client
> ---
>
> Key: DERBY-2602
> URL: https://issues.apache.org/jira/browse/DERBY-2602
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.3.0.0
>Reporter: Kathey Marsden
>Priority: Minor
> Attachments: d2602.java
>
>
> In ParameterMappingTest I see the following differences between embedded
> and client. Client is truncating the TIMESTAMP value. Look for this bug
> number in the test for reproduction.
> case java.sql.Types.TIMESTAMP:
> if (param == 2)
> if (usingEmbedded())
> assertEquals("2004-03-12 21:14:24.938222433",
> val.toString());
> else
> assertEquals("2004-03-12 21:14:24.938222",
> val.toString());
> else if (param == 3)
> if (usingEmbedded())
> assertEquals("2004-04-12 04:25:26.462983731",
> val.toString());
> else
> assertEquals("2004-04-12 04:25:26.462983",
> val.toString());
> break;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493498 ] A B commented on DERBY-716: --- > To me, the wording that you suggest doesn't cover the following case: Can you explain more about why the example is not covered? Is it because of my use of the term "single value"? If so, we could take that part out: Let P[i] be the i-th declared parameter for some table function. Let A[i] be the i-th argument passed to the table function when it is called. A table function argument A[i] can be any expression whose corresponding JDBC type is the same as the JDBC type which corresponds to the SQL type of the function's declared parameter P[i]. In the example you give, "s.schemaName" and "t.tableName" are simply expressions (in this case, column references) whose corresponding JDBC type is String, hence they are fine (because the JDBC type of the SPACE_TABLE parameters is String, too). > What do you think of something like the following: "Table Function > arguments must resolve to expressions which are evaluated once in the > context of their query block. This includes literals and ? parameters > but may also include the return values of function calls as well as > correlated references to columns in outer query blocks. This seems too concentrated on the idea of "evaluated once". The important thing here isn't how many times the expression is evaluated for a given query; it's that the expression's datatype match the datatype of the declared function parameter. Sorry if my previous suggestion made it seem otherwise... > I will add some words to note that I'm waving my hands here. On the one hand I agree, having a solid example is not the goal of the spec. On the other hand, if we can't come up with a solid example, I wonder how complete/appropriate any proposed solution will end up being? If we cannot get a good use case of how this feature might be used, it makes it hard to know whether or not the design is going to be a good one. An example doesn't have to do anything complex like reference an external database. It could just be something really simple that, for example, creates a 2-d array of strings and returns that as a ResultSet. Proof of concept is what I'm hoping for. As it is, I can't get a good feel for how the proposed VTIs are actually supposed to be created work from a user perspective... > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-1533) ArrayIndexOutOfBoundsException in DDMReader, on a specific data size
[ https://issues.apache.org/jira/browse/DERBY-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden closed DERBY-1533. - > ArrayIndexOutOfBoundsException in DDMReader, on a specific data size > > > Key: DERBY-1533 > URL: https://issues.apache.org/jira/browse/DERBY-1533 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.1.2.1, 10.1.3.1 > Environment: - Derby Network Server Information > Version: CSS10011/10.1.3.1 Build: 417277 DRDA Product Id: CSS10011 > -- listing properties -- > derby.drda.maxThreads=0 > derby.drda.keepAlive=true > derby.drda.minThreads=0 > derby.drda.portNumber=1527 > derby.drda.logConnections=false > derby.drda.timeSlice=0 > derby.drda.startNetworkServer=false > derby.drda.host=localhost > derby.drda.traceAll=false > -- Java Information -- > Java Version:1.4.2_08 > Java Vendor: Sun Microsystems Inc. > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\dev\derby\lib\derby.jar] 10.1.3.1 - (417277) > [C:\dev\derby\lib\derbytools.jar] 10.1.3.1 - (417277) > [C:\dev\derby\lib\derbynet.jar] 10.1.3.1 - (417277) > -- >Reporter: Wiktor Lisowicz > Assigned To: Bryan Pendleton > Fix For: 10.1.3.2, 10.2.1.6 > > Attachments: ddmreader1.diff, DerbyTest.java, DerbyTest2.java, > notes.html, withTests.diff > > > As far as I know, this bug is not related to DERBY-428 bug. > I got this bug both on 10.1.3.1 and 10.1.2.1 - an > ArrayIndexOutOfBoundsException in DDMReader (in Network Server). > To reproduce the bug: > 1. Compile the attached DerbyTest.java > 2. Start the Network Server (startNetworkServer.bat under Windows) > 3. Run: java DerbyTest > On client side you get: > org.apache.derby.client.am.DisconnectException: The DDM object is not > supported. Unsupported DDM object code point: 0x0 > at > org.apache.derby.client.net.NetConnectionReply.doObjnsprmSemantics(Unknown > Source) > at > org.apache.derby.client.net.NetConnectionReply.parseCommonError(Unknown > Source) > at > org.apache.derby.client.net.NetStatementReply.parseExecuteError(Unknown > Source) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown > Source) > at org.apache.derby.client.net.NetStatementReply.readExecute(Unknown > Source) > at org.apache.derby.client.net.StatementReply.readExecute(Unknown > Source) > at > org.apache.derby.client.net.NetPreparedStatement.readExecute_(Unknown Source) > at org.apache.derby.client.am.PreparedStatement.readExecute(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.executeX(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.execute(Unknown > Source) > at DerbyTest.main(DerbyTest.java:479) > On server side you get: > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.impl.drda.DDMReader.compressBLayerData(Unknown > Source) > at > org.apache.derby.impl.drda.DDMReader.ensureBLayerDataInBuffer(Unknown Source) > at org.apache.derby.impl.drda.DDMReader.readNetworkShort(Unknown > Source) > at org.apache.derby.impl.drda.DDMReader.readLDStringData(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.readAndSetParams(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA(Unknown > Source) > at > org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) > agentThread[DRDAConnThread_11,5,main] > null > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.impl.drda.DDMReader.compressBLayerData(Unknown > Source) > at > org.apache.derby.impl.drda.DDMReader.ensureBLayerDataInBuffer(Unknown Source) > at org.apache.derby.impl.drda.DDMReader.readNetworkShort(Unknown > Source) > at org.apache.derby.impl.drda.DDMReader.readLDStringData(Unknown > Source) >
[jira] Resolved: (DERBY-1533) ArrayIndexOutOfBoundsException in DDMReader, on a specific data size
[ https://issues.apache.org/jira/browse/DERBY-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-1533. --- Resolution: Fixed Fix Version/s: 10.1.3.2 Assignee: Bryan Pendleton (was: Kathey Marsden) > ArrayIndexOutOfBoundsException in DDMReader, on a specific data size > > > Key: DERBY-1533 > URL: https://issues.apache.org/jira/browse/DERBY-1533 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.1.2.1, 10.1.3.1 > Environment: - Derby Network Server Information > Version: CSS10011/10.1.3.1 Build: 417277 DRDA Product Id: CSS10011 > -- listing properties -- > derby.drda.maxThreads=0 > derby.drda.keepAlive=true > derby.drda.minThreads=0 > derby.drda.portNumber=1527 > derby.drda.logConnections=false > derby.drda.timeSlice=0 > derby.drda.startNetworkServer=false > derby.drda.host=localhost > derby.drda.traceAll=false > -- Java Information -- > Java Version:1.4.2_08 > Java Vendor: Sun Microsystems Inc. > OS name: Windows XP > OS architecture: x86 > OS version: 5.1 > java.specification.name: Java Platform API Specification > java.specification.version: 1.4 > - Derby Information > JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 > [C:\dev\derby\lib\derby.jar] 10.1.3.1 - (417277) > [C:\dev\derby\lib\derbytools.jar] 10.1.3.1 - (417277) > [C:\dev\derby\lib\derbynet.jar] 10.1.3.1 - (417277) > -- >Reporter: Wiktor Lisowicz > Assigned To: Bryan Pendleton > Fix For: 10.1.3.2, 10.2.1.6 > > Attachments: ddmreader1.diff, DerbyTest.java, DerbyTest2.java, > notes.html, withTests.diff > > > As far as I know, this bug is not related to DERBY-428 bug. > I got this bug both on 10.1.3.1 and 10.1.2.1 - an > ArrayIndexOutOfBoundsException in DDMReader (in Network Server). > To reproduce the bug: > 1. Compile the attached DerbyTest.java > 2. Start the Network Server (startNetworkServer.bat under Windows) > 3. Run: java DerbyTest > On client side you get: > org.apache.derby.client.am.DisconnectException: The DDM object is not > supported. Unsupported DDM object code point: 0x0 > at > org.apache.derby.client.net.NetConnectionReply.doObjnsprmSemantics(Unknown > Source) > at > org.apache.derby.client.net.NetConnectionReply.parseCommonError(Unknown > Source) > at > org.apache.derby.client.net.NetStatementReply.parseExecuteError(Unknown > Source) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown > Source) > at org.apache.derby.client.net.NetStatementReply.readExecute(Unknown > Source) > at org.apache.derby.client.net.StatementReply.readExecute(Unknown > Source) > at > org.apache.derby.client.net.NetPreparedStatement.readExecute_(Unknown Source) > at org.apache.derby.client.am.PreparedStatement.readExecute(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.executeX(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.execute(Unknown > Source) > at DerbyTest.main(DerbyTest.java:479) > On server side you get: > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.impl.drda.DDMReader.compressBLayerData(Unknown > Source) > at > org.apache.derby.impl.drda.DDMReader.ensureBLayerDataInBuffer(Unknown Source) > at org.apache.derby.impl.drda.DDMReader.readNetworkShort(Unknown > Source) > at org.apache.derby.impl.drda.DDMReader.readLDStringData(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.readAndSetParams(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA_work(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.parseSQLDTA(Unknown > Source) > at > org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown > Source) > at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) > agentThread[DRDAConnThread_11,5,main] > null > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.impl.drda.DDMReader.compressBLayerData(Unknown > Source) > at > org.apache.derby.impl.drda.DDMReader.ensureBLayerDataInBuffer(Unknown Source) > at org.apache.derby.impl.drda.DDMReader.readNetwor
[jira] Commented: (DERBY-2381) ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a procedure
[ https://issues.apache.org/jira/browse/DERBY-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493493 ] Kathey Marsden commented on DERBY-2381: --- The problem running ParameterMappingTest was an issue with my environment. It passes now. I will rerun tests and check in. > ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a > procedure > --- > > Key: DERBY-2381 > URL: https://issues.apache.org/jira/browse/DERBY-2381 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden > Assigned To: Kathey Marsden > Attachments: d2381.java, DERBY-2381_diff.txt, DERBY-2381_stat.txt > > > The test ParameterMappingTest fails due to a connection reset error during > tearDown. Commenting out the teardown actions I see that the real cause of > the connection reset is an ArrayIndexOutOfBoundsException executing a > callable statement. I have not narrowed it down more than this. Currently > the test runs only for embedded. It should be reenabled for client once this > bug is fixed. Below is the stack trace: > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107) > at > org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153) > at org.apache.derby.client.net.Reply.fill(Reply.java:165) > at > org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java(Compiled > Code)) > at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) > at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2151) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1571) > at > org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1556) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:487) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.R
[jira] Updated: (DERBY-2602) TIMESTAMP value is truncated when return to client
[
https://issues.apache.org/jira/browse/DERBY-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-2602:
--
Attachment: d2602.java
The issue is with java.sql.Timestamp object as well
Attached is a reproduction which shows the following behavior.
Embedded Timestamp
getHours:17
getMinutes:14
getSeconds:24
getNanos:97625551
Network Timestamp
getHours:17
getMinutes:14
getSeconds:24
getNanos:97625000
> TIMESTAMP value is truncated when return to client
> ---
>
> Key: DERBY-2602
> URL: https://issues.apache.org/jira/browse/DERBY-2602
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.3.0.0
>Reporter: Kathey Marsden
>Priority: Minor
> Attachments: d2602.java
>
>
> In ParameterMappingTest I see the following differences between embedded
> and client. Client is truncating the TIMESTAMP value. Look for this bug
> number in the test for reproduction.
> case java.sql.Types.TIMESTAMP:
> if (param == 2)
> if (usingEmbedded())
> assertEquals("2004-03-12 21:14:24.938222433",
> val.toString());
> else
> assertEquals("2004-03-12 21:14:24.938222",
> val.toString());
> else if (param == 3)
> if (usingEmbedded())
> assertEquals("2004-04-12 04:25:26.462983731",
> val.toString());
> else
> assertEquals("2004-04-12 04:25:26.462983",
> val.toString());
> break;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2587) Connection.createClob() and Connection.createBlob() need to return locator support enabled LOB objects in the NetworkClient
[ https://issues.apache.org/jira/browse/DERBY-2587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493471 ] Rick Hillegas commented on DERBY-2587: -- The patch looks good to me now but I'm afraid that it breaks the JUnit tests. I have run the full JUnit tests twice against this patch and seen the following error both times. As a reference, I ran the tests against a clean client without the patch and I did not see this error: There was 1 error: 1) testTriggerNegative(org.apache.derbyTesting.functionTests.tests.lang.ProcedureInTriggerTest)java.sql.SQLException: Operation 'CREATE TRIGGER' cannot be performed on object 'T1' because there is an open ResultSet dependent on that object. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:346) at org.apache.derby.client.am.Statement.execute(Statement.java:824) at org.apache.derbyTesting.functionTests.tests.lang.ProcedureInTriggerTest.testTriggerNegative(ProcedureInTriggerTest.java:406) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Caused by: org.apache.derby.client.am.SqlException: Operation 'CREATE TRIGGER' cannot be performed on object 'T1' because there is an open ResultSet dependent on that object. at org.apache.derby.client.am.Statement.completeSqlca(Statement.java:1713) at org.apache.derby.client.am.Statement.completeExecuteImmediate(Statement.java:1322) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLIMMreply(NetStatementReply.java:207) at org.apache.derby.client.net.NetStatementReply.readExecuteImmediate(NetStatementReply.java:58) at org.apache.derby.client.net.StatementReply.readExecuteImmediate(StatementReply.java:45) at org.apache.derby.client.net.NetStatement.readExecuteImmediate_(NetStatement.java:125) at org.apache.derby.client.am.Statement.readExecuteImmediate(Statement.java:1318) at org.apache.derby.client.am.Statement.flowExecute(Statement.java:2014) at org.apache.derby.client.am.Statement.executeX(Statement.java:829) at org.apache.derby.client.am.Statement.execute(Statement.java:815) ... 37 more FAILURES!!! Tests run: 7521, Failures: 0, Errors: 1 > Connection.createClob() and Connection.createBlob() need to return locator > support enabled LOB objects in the NetworkClient > --- > > Key: DERBY-2587 > URL: https://issues.apache.org/jira/browse/DERBY-2587 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan > Assigned To: V.Narayanan > Attachments: ConnectionLocatorWork_v1.diff, > ConnectionLocatorWork_v1.stat, ConnectionLocatorWork_v2.diff, > ConnectionLocatorWork_v2.stat, ConnectionLocatorWork_v3.diff, > ConnectionLocatorWork_v3.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493469 ] Rick Hillegas commented on DERBY-716: - Thanks for the continued feedback, Army. > 1) Under "Additional SELECT Syntax" I welcome additional ideas about how to wordsmith this. I'm trying to accomplish the following: a) Indicate that I'm not planning to support any syntax that doesn't currently work for the diagnostic vtis--at the same time, I'm not planning to disable anything that is useful and already implemented. b) Sketch what can be said about this in the user manuals. I think I have accomplished (a) but I agree that (b) is a bit fuzzy. To me, the wording that you suggest doesn't cover the following case: select s.schemaName, t.tableName from sys.sysschemas s, sys.systables t where t.schemaid=s.schemaid and exists ( select vti.* from table ( syscs_diag.space_table( s.schemaName, t.tableName ) ) as vti where vti.numfreepages > 100 ); Here the arguments to the VTI constructor are variables in the context of the outer query block but constants in the context of the inner block. What do you think of something like the following: "Table Function arguments must resolve to expressions which are evaluated once in the context of their query block. This includes literals and ? parameters but may also include the return values of function calls as well as correlated references to columns in outer query blocks." > 2) Under "Appendix E: Sample VTI" I am sorry that this is so confusing. In my example, I am admitedly waving my hands over the complexity of managing connections to an external database. This is not how someone would really write this VTI. In additon to the awkwardness of closing down the whole VTI, this example is simply not re-entrant: If two different connections tried to use this VTI, they would trip over one another. Writing a bullet-proof VTI like this requires some work, which I think someone will want to do (and hopefully donate to the community). I'm not taking on that task as part of writing this functional spec. I will add some words to note that I'm waving my hands here. > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
it would be nice if junit tests did not drop databases when test got errors.
I don't know how many of the junit test do this, but it would be nice if tests kept around as much information as possible when they fail. IT is great if they clean up everything if they succeed, but having complete derby.log and as much of the database as possible when the error occurred can be helpful in debugging the problem after the fact. This is especially helpful if the problem is intermittent and/or environment specific. I am trying to debug the upgrade tests and those tests seem to drop the database always, where I really want it to leave the db around so I can look at it by hand. It doesn't look too hard to hack the junit support routines to leave the db around while I am debugging, but would be nice if it just left it around automatically or if there were some test flag I could set.
Re: limit # rows
Paulo Jesus wrote: I´m new here and i don´t know this channels very well. If i need to do something like that, where can i do it? I was requested to implement a new interface over derby so i will need it. Instructions on how to do this are at: http://db.apache.org/derby/DerbyBugGuidelines.html I was thinking not so much a new interface as a performance improvement for setMaxRows with client, something like. Improve client setMaxRows performance by sending setMaxRows setting to the server. Kathey
Re: limit # rows
Executing a select i get a number of lines.I pretend the firs line returned. No matter if sorted or not. My question come to developers because looks like that the functionality isn't implemented. As the most strait implementation would be by SQL syntax. Or i´m wrong? PJ 2007/5/3, Bryan Pendleton <[EMAIL PROTECTED]>: > I have a query "SELECT o_id-1 FROM orders" that returns 129600 > lines. But i only need one line. I'm confused by your statement of the problem. For which row in your orders table do you want to find the value of the o_id column minus 1? In other words, you say you only need one line, but which line? thanks, bryan P.S. This sort of question goes better on derby-user, not derby-dev
[jira] Commented: (DERBY-2603) Minor erratum in page of VARCHAR in Derby Reference manual
[ https://issues.apache.org/jira/browse/DERBY-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493434 ] Bryan Pendleton commented on DERBY-2603: Thanks for the clarification; your explanation makes complete sense to me. I see that there is the following page in the docs, which defines "SQL Boolean Operators": http://db.apache.org/derby/docs/dev/ref/rrefsqlj23075.html#rrefsqlj23075__sqlj34517 Are these the same operators that are being referred to by the words "binary comparison operators" in the varchar page for this issue? http://db.apache.org/derby/docs/dev/ref/rrefsqlj41207.html If so, then I think it would be completely appropriate to make the change you suggest, and perhaps also to include a cross-referencing link to the other page. > Minor erratum in page of VARCHAR in Derby Reference manual > -- > > Key: DERBY-2603 > URL: https://issues.apache.org/jira/browse/DERBY-2603 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefsqlj41207.html >Reporter: Tomohito Nakayama >Priority: Minor > > I found next statement in the page through translation into Japanese. > > When binary comparison operators are applied to VARCHARs, the lengths of > > the operands are not altered, and spaces at the end of the values are > > ignored. > I think "binary" should be replaced as "boolean". > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: limit # rows
I´m new here and i don´t know this channels very well. If i need to do something like that, where can i do it? I was requested to implement a new interface over derby so i will need it. PJ 2007/5/3, Kathey Marsden <[EMAIL PROTECTED]>: Paulo Jesus wrote: > stmt.setMaxRows(1); > at the application i can get one row, but i would need to make some > effect on server. > I have tested with and without setMaxRows() function but the results i > got make understand that limit is make by the driver after the > query execution. > This can make a big difference on execution performance, but i didn't > find references on it. > > Is this implemented? How can i improve this type of query? This is a > simple query, without any 'order by'. > I think you would have to file this as an enhancement request. It could potentially be implemented using the same strategy as DERBY-506, setQueryTimeout. Kathey
[jira] Commented: (DERBY-2603) Minor erratum in page of VARCHAR in Derby Reference manual
[ https://issues.apache.org/jira/browse/DERBY-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493432 ] Tomohito Nakayama commented on DERBY-2603: -- I think the word "binary" in this statement is mistaken of "boolean". // Both types concern to concept of 0 and 1. // Then I think person who is familiar with computer may misuse them. As you wrote, we can recognize "binary" stands for number of argument here. But I think it is not good usage of word here and could not believe it is intense of the original writer. At first, I misunderstood that the two values are compared as binary value ! Again, I can't believe that writer use the word "binary" for that meaning , the number of arguments > Minor erratum in page of VARCHAR in Derby Reference manual > -- > > Key: DERBY-2603 > URL: https://issues.apache.org/jira/browse/DERBY-2603 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefsqlj41207.html >Reporter: Tomohito Nakayama >Priority: Minor > > I found next statement in the page through translation into Japanese. > > When binary comparison operators are applied to VARCHARs, the lengths of > > the operands are not altered, and spaces at the end of the values are > > ignored. > I think "binary" should be replaced as "boolean". > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2381) ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a procedure
[ https://issues.apache.org/jira/browse/DERBY-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493430 ] Kathey Marsden commented on DERBY-2381: --- After syncing up with DERBY-2506 ( PreparedCallable_DRDA_v5.diff, adding some BLOB locator support.) the test case attached to this issue and ParameterMappingTest no longer pass with network server. The new trace is below. There is no exception on the server. Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107) at org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153) at org.apache.derby.client.net.Reply.fill(Reply.java:165) at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java:215) at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324) at org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105) at org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) at org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176) at org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2157) at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1577) at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1562) at d2381.main(D2381.java:39) > ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a > procedure > --- > > Key: DERBY-2381 > URL: https://issues.apache.org/jira/browse/DERBY-2381 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden > Assigned To: Kathey Marsden > Attachments: d2381.java, DERBY-2381_diff.txt, DERBY-2381_stat.txt > > > The test ParameterMappingTest fails due to a connection reset error during > tearDown. Commenting out the teardown actions I see that the real cause of > the connection reset is an ArrayIndexOutOfBoundsException executing a > callable statement. I have not narrowed it down more than this. Currently > the test runs only for embedded. It should be reenabled for client once this > bug is fixed. Below is the stack trace: > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107) > at > org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153) > at org.apache.derby.client.net.Reply.fill(Reply.java:165) > at > org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java(Compiled > Code)) > at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) > at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2151) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1571) > at > org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1556) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:487) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runB
[jira] Updated: (DERBY-2381) ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a procedure
[ https://issues.apache.org/jira/browse/DERBY-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2381: -- Comment: was deleted > ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a > procedure > --- > > Key: DERBY-2381 > URL: https://issues.apache.org/jira/browse/DERBY-2381 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden > Assigned To: Kathey Marsden > Attachments: d2381.java, DERBY-2381_diff.txt, DERBY-2381_stat.txt > > > The test ParameterMappingTest fails due to a connection reset error during > tearDown. Commenting out the teardown actions I see that the real cause of > the connection reset is an ArrayIndexOutOfBoundsException executing a > callable statement. I have not narrowed it down more than this. Currently > the test runs only for embedded. It should be reenabled for client once this > bug is fixed. Below is the stack trace: > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107) > at > org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153) > at org.apache.derby.client.net.Reply.fill(Reply.java:165) > at > org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java(Compiled > Code)) > at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) > at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2151) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1571) > at > org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1556) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:487) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) > at junit.extensions.TestSetup$1.protect(TestSetup.java:19) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.extensions.TestSetup.run(TestSetup.java:23) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) -- This message is automatically generated by JIRA. - You can reply to this email
Re: limit # rows
Paulo Jesus wrote: stmt.setMaxRows(1); at the application i can get one row, but i would need to make some effect on server. I have tested with and without setMaxRows() function but the results i got make understand that limit is make by the driver after the query execution. This can make a big difference on execution performance, but i didn't find references on it. Is this implemented? How can i improve this type of query? This is a simple query, without any 'order by'. I think you would have to file this as an enhancement request. It could potentially be implemented using the same strategy as DERBY-506, setQueryTimeout. Kathey
Re: limit # rows
I have a query "SELECT o_id-1 FROM orders" that returns 129600 lines. But i only need one line. I'm confused by your statement of the problem. For which row in your orders table do you want to find the value of the o_id column minus 1? In other words, you say you only need one line, but which line? thanks, bryan P.S. This sort of question goes better on derby-user, not derby-dev
[jira] Updated: (DERBY-2508) Implement the XA transaction timeout support for embedded driver.
[ https://issues.apache.org/jira/browse/DERBY-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julius Stroffek updated DERBY-2508: --- Attachment: d2508_try2.stat d2508_try2.diff I found a bug in a patch - there should be a condition tested (timoutTask != null) in XATransactionState.xa_commit/rollback before executing a code to cancel that timeoutTask. I also changed a value of default xa transaction timeout to 0 to disable the timeout by default. I am attaching a patch with a fix. Currently, I am running the tests. > Implement the XA transaction timeout support for embedded driver. > - > > Key: DERBY-2508 > URL: https://issues.apache.org/jira/browse/DERBY-2508 > Project: Derby > Issue Type: Sub-task >Affects Versions: 10.2.2.0 >Reporter: Julius Stroffek > Assigned To: Julius Stroffek > Fix For: 10.3.0.0 > > Attachments: d2432_beta1.diff, d2432_beta1.stat, d2508.diff, > d2508.stat, d2508_try2.diff, d2508_try2.stat > > > Implement the XA transaction support for embedded driver in EmbedXAResource. > Implement functions XAResource.setTransactionTimeout and > XAResource.getTransactionTimeout and add the code to cancel the transaction > after the specified period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
limit # rows
I´m making some testes on derby ver 10.2.2.0, Network Server framework, with a tpc-w client software. I have a query "SELECT o_id-1 FROM orders" that returns 129600 lines. But i only need one line. I can make Statement stmt = con.createStatement(); stmt.setMaxRows(1); at the application i can get one row, but i would need to make some effect on server. I have tested with and without setMaxRows() function but the results i got make understand that limit is make by the driver after the query execution. This can make a big difference on execution performance, but i didn't find references on it. Is this implemented? How can i improve this type of query? This is a simple query, without any 'order by'. Sorry to be asking again, every posts i saw didn't answer to this problem. PJ
[jira] Commented: (DERBY-2381) ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a procedure
[ https://issues.apache.org/jira/browse/DERBY-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493425 ] Kathey Marsden commented on DERBY-2381: --- After syncing up with DERBY-2604, the test case attached to this issue and ParameterMappingTest no longer pass. The new trace is below. There is no exception on the server. Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107) at org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153) at org.apache.derby.client.net.Reply.fill(Reply.java:165) at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java:215) at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324) at org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105) at org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) at org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176) at org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2157) at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1577) at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1562) at d2381.main(D2381.java:39) > ParameterMappingTest fails due to ArrayIndexOutOfBoundsException executing a > procedure > --- > > Key: DERBY-2381 > URL: https://issues.apache.org/jira/browse/DERBY-2381 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.3.0.0 >Reporter: Kathey Marsden > Assigned To: Kathey Marsden > Attachments: d2381.java, DERBY-2381_diff.txt, DERBY-2381_stat.txt > > > The test ParameterMappingTest fails due to a connection reset error during > tearDown. Commenting out the teardown actions I see that the real cause of > the connection reset is an ArrayIndexOutOfBoundsException executing a > callable statement. I have not narrowed it down more than this. Currently > the test runs only for embedded. It should be reenabled for client once this > bug is fixed. Below is the stack trace: > java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107) > at > org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153) > at org.apache.derby.client.net.Reply.fill(Reply.java:165) > at > org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java(Compiled > Code)) > at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317) > at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2151) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1571) > at > org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1556) > at > org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:487) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.framework.TestResult$1.protect(TestResult.ja
[jira] Commented: (DERBY-2508) Implement the XA transaction timeout support for embedded driver.
[ https://issues.apache.org/jira/browse/DERBY-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493422 ] Julius Stroffek commented on DERBY-2508: > Does this mean just XAResource.start(TMNOFLAGS) or is the timer reset on each > call to start? Just the first call, so only for XAResource.start(TMNOFLAGS). > Implement the XA transaction timeout support for embedded driver. > - > > Key: DERBY-2508 > URL: https://issues.apache.org/jira/browse/DERBY-2508 > Project: Derby > Issue Type: Sub-task >Affects Versions: 10.2.2.0 >Reporter: Julius Stroffek > Assigned To: Julius Stroffek > Fix For: 10.3.0.0 > > Attachments: d2432_beta1.diff, d2432_beta1.stat, d2508.diff, > d2508.stat > > > Implement the XA transaction support for embedded driver in EmbedXAResource. > Implement functions XAResource.setTransactionTimeout and > XAResource.getTransactionTimeout and add the code to cancel the transaction > after the specified period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2508) Implement the XA transaction timeout support for embedded driver.
[ https://issues.apache.org/jira/browse/DERBY-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493421 ] Julius Stroffek commented on DERBY-2508: XAResource.setTransactionTimeout says something about the resource manager's default timeout. This should than have some fixed value (or 0 to be disabled). If derby is used as an embedded database the feature is probably of a limited value and using XAResource.setTransactionTimeout might be sufficient. I thought that the database administrator might want to change this if derby will run as a network server. It might help in case of a network server - the db administrator do not have to be able to control the application code and even he do not have to know every application connecting to the database. If the application connecting to derby server will not use setTransactionTimeout itself and it will crash when there is some global transaction not commited/rolled back which is also not associated to any connection, that global transaction will keep holding the locks. DB administrator is than able to setup the derby.jdbc.xaTransactionTimeout property and the locks would be released after the specified time. And I thought that it would be a good idea that the behavior of derby network client end embedded client would be the same. > Implement the XA transaction timeout support for embedded driver. > - > > Key: DERBY-2508 > URL: https://issues.apache.org/jira/browse/DERBY-2508 > Project: Derby > Issue Type: Sub-task >Affects Versions: 10.2.2.0 >Reporter: Julius Stroffek > Assigned To: Julius Stroffek > Fix For: 10.3.0.0 > > Attachments: d2432_beta1.diff, d2432_beta1.stat, d2508.diff, > d2508.stat > > > Implement the XA transaction support for embedded driver in EmbedXAResource. > Implement functions XAResource.setTransactionTimeout and > XAResource.getTransactionTimeout and add the code to cancel the transaction > after the specified period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[ https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493419 ] Daniel John Debrunner commented on DERBY-716: - Why is the VTIEnvironment class being removed from the VTICosting interface? Does it cause issues in some way? The separation of the creation of the VTICosting object from the creation of the VTI class means that the costing cannot take into account the parameters being passed to the table function. Thus it might be hard for an application developer to have any meaningful costing information, defeating the whole purpose of the interface. It also limits the any class to supporting just one static method that returns a ResultSet, unless they can all share the same exact costing information. > Re-enable VTIs > -- > > Key: DERBY-716 > URL: https://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL >Reporter: Rick Hillegas > Attachments: functionTables.html, functionTables.html > > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2508) Implement the XA transaction timeout support for embedded driver.
[ https://issues.apache.org/jira/browse/DERBY-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493417 ] Daniel John Debrunner commented on DERBY-2508: -- > The timeout is measured since the application calls the XAResource.start Does this mean just XAResource.start(TMNOFLAGS) or is the timer reset on each call to start? > Implement the XA transaction timeout support for embedded driver. > - > > Key: DERBY-2508 > URL: https://issues.apache.org/jira/browse/DERBY-2508 > Project: Derby > Issue Type: Sub-task >Affects Versions: 10.2.2.0 >Reporter: Julius Stroffek > Assigned To: Julius Stroffek > Fix For: 10.3.0.0 > > Attachments: d2432_beta1.diff, d2432_beta1.stat, d2508.diff, > d2508.stat > > > Implement the XA transaction support for embedded driver in EmbedXAResource. > Implement functions XAResource.setTransactionTimeout and > XAResource.getTransactionTimeout and add the code to cancel the transaction > after the specified period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2508) Implement the XA transaction timeout support for embedded driver.
[ https://issues.apache.org/jira/browse/DERBY-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493409 ] Daniel John Debrunner commented on DERBY-2508: -- Thanks for the explantion. One intial thought is why have the property? There exists a standard api for setting the transaction timeout, why add another non-standard mechanism? > Implement the XA transaction timeout support for embedded driver. > - > > Key: DERBY-2508 > URL: https://issues.apache.org/jira/browse/DERBY-2508 > Project: Derby > Issue Type: Sub-task >Affects Versions: 10.2.2.0 >Reporter: Julius Stroffek > Assigned To: Julius Stroffek > Fix For: 10.3.0.0 > > Attachments: d2432_beta1.diff, d2432_beta1.stat, d2508.diff, > d2508.stat > > > Implement the XA transaction support for embedded driver in EmbedXAResource. > Implement functions XAResource.setTransactionTimeout and > XAResource.getTransactionTimeout and add the code to cancel the transaction > after the specified period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-716) Re-enable VTIs
[
https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493405
]
A B commented on DERBY-716:
---
Thank you for answering my previous questions, Rick, and for incorporating my
feedback into the second version of the spec. I took a look at the latest spec
and I have the following questions...
1) Under "Additional SELECT Syntax"
"Value - A Value is an expression which could appear as an argument in the
invocation
of one of the diagnostic VTI functions. This includes literals and '?'
parameters."
I wonder if it wouldn't be better to just explicitly state what is allowed
here, instead of referencing the diagnostic VTIs? I.e. "Value" can be any
expression which evaluates to a single value whose corresponding JDBC type
equals the JDBC equivalent of the relevant function parameter's declared SQL
type.
That's a mouthful (you'll probably want to wordsmith it a bit), but as an
example:
CREATE FUNCTION externalEmployees (LAST_NAME VARCHAR(50))
RETURNS TABLE ...
The function parameter "LAST_NAME" has a declared SQL type of VARCHAR. The
JDBC equivalent to this type is String. Call this PARAM_JDBC_TYPE. Then when
calling the function:
SELECT * FROM TABLE (externalEmployees( )) as EMP
can be any expression that evaluates to a type whose JDBC equivalent is
PARAM_JDBC_TYPE. One exception here may be LOBs; I don't think Derby allows
passing of LOBs as function parameters?
In this case PARAM_JDBC_TYPE is "String", so can be any character
expression. And yes, this includes literals and '?' parameters.
Note that something like:
SELECT * FROM TABLE (externalEmployees(SELECT DISTINCT 'hi' FROM
SYS.SYSTABLES)) as EMP
would not work because the subquery returns "a result set with a single row",
which is not the same as "a single value".
2) Under "Appendix E: Sample VTI"
It's great to have an example, so thank you for putting this together. Some
initial comments...
A -- The javadoc for the class includes:
* 3) When you are done siphoning out the rows you need, release the
* connection to the external database:
*
*EmployeeTable.close();
I don't quite understand who the "you" is in this sentence? It sounds like
it's referring to the user, but it seems odd to me to expect that the user is
responsible for explicitly calling "close" on the VTI class.
Is the assumption here that an application will typically execute code such as:
ResultSet rs = conn.createStatement().executeQuery(
"select * from TABLE (employeeTable()) emps");
while (rs.next())
{
...
}
rs.close();
EmployeeTable.close();
If this is not what you had in mind, can you perhaps include an example
program that would call the EmployeeTable VTI, process results, and then clean
up?
Intuitively I would expect that a call to "rs.close()" internally leads Derby
to call "close()" on the VTI class, sparing the user the need to do so. Which
brings me to my next question...
B -- What is "rs" in the following:
ResultSet rs = conn.createStatement().executeQuery(
"select * from TABLE (employeeTable()) emps");
Is it:
a) The exact same ResultSet object that is returned from EmployeeTable.read()
b) A Derby ResultSet that somehow wraps the the EmployeeTable VTI
c) A Derby ResultSet that somehow wraps the ResultSet returned from
EmployeeTable.read()
d) Something else entirely?
If it's "a" then the user/app would indeed be responsible for calling
EmployeeTable.close() explicitly, which seems odd. If it's "b" then Derby can
internally propagate "rs.close()" to EmployeeTable.close(), but would not have
direct access to the underlying result set (or would it?). If it's "c" then
Derby has more control over the behavior of the result set and can propagate
calls on "rs" to the underlying (user-defined) ResultSet--but Derby would not
be able to call methods on the VTI itself (such as EmployeeTable.close()). Can
you say which of these, if any, correlates to your plans for VTIs?
Thanks for your patience as I try to wrap my head around this...
> Re-enable VTIs
> --
>
> Key: DERBY-716
> URL: https://issues.apache.org/jira/browse/DERBY-716
> Project: Derby
> Issue Type: New Feature
> Components: SQL
>Reporter: Rick Hillegas
> Attachments: functionTables.html, functionTables.html
>
>
> Cloudscape used to expose Virtual Table Interfaces, by which any class which
> implemented ResultSet could be included in a query's FROM list. Derby still
> exposes a number of these VTIs as diagnostic tools. However, Derby now
> prevents customers from declaring their own VTIs. The parser raises an error
> if a VTI's package isn't one of the Derby diagnostic packages.
> This is a very powerful feature which customers can use to solve many
>
Regression Test Report - Daily 534524 - Sun DBTG
[Auto-generated mail] *Daily* 534524/2007-05-02 18:00:12 CEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 0318318 075.08% derbyall 074727472 0 616.07% suitesAll sles 0318318 074.40% derbyall 074727472 0 336.53% suitesAll sol 0318318 080.20% derbyall 074727472 0 523.64% suitesAll solN+1 0318318 089.63% derbyall 074727472 0 539.39% suitesAll sparc 0318318 073.08% derbyall UNKOWNUNKOWNUNKOWN UNKOWN 0.00% suitesAll vista 0318318 0 .% derbyall F:1,E:074727471 0 323.94% suitesAll w2003 NA NA NANA derbyall F:1,E:074727471 0 170.04% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-534524.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/534524.html *Jvm: 1.5* lin 0312312 274.62% derbyall 058275827 0 392.39% suitesAll sles 0312312 274.08% derbyall 058275827 0 248.72% suitesAll sol 0312312 282.57% derbyall 058275827 0 327.71% suitesAll solN+1 0312312 293.45% derbyall UNKOWNUNKOWNUNKOWN UNKOWN 0.00% suitesAll sparc 0312312 273.19% derbyall 058275827 0 321.28% suitesAll vista 0312312 275.18% derbyall F:1,E:058275826 0 203.20% suitesAll w2003 0312312 279.40% derbyall F:1,E:058275826 0 136.86% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-534524.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/534524.html *Jvm: 1.4* lin 0308308 475.16% derbyall 058235823 0 352.78% suitesAll sles 0308308 474.06% derbyall 058235823 0 234.28% suitesAll sol 0308308 481.63% derbyall 058235823 0 265.32% suitesAll solN+1 0308308 495.08% derbyall NA NA NANA suitesAll sparc NA NA NANA derbyall NA NA NANA suitesAll vista 1308307 4 .% derbyall F:2,E:058235821 0 239.94% suitesAll w2003 0308308 4 .% derbyall F:1,E:058235822 0 .% suitesAll Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-534524.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/534524.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/534524.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Commented: (DERBY-2605) You can create BOOLEAN columns in 10.3
[ https://issues.apache.org/jira/browse/DERBY-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493402 ] A B commented on DERBY-2605: Last week I sent an email to derby-dev about the ability to create a decimal column with precision greater than 31: http://article.gmane.org/gmane.comp.apache.db.derby.devel/40881 I wonder if that issue and this one are related? Ex. Should the CREATE TABLE AS functionality be performing checks on the column types that it creates? > You can create BOOLEAN columns in 10.3 > -- > > Key: DERBY-2605 > URL: https://issues.apache.org/jira/browse/DERBY-2605 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.3.0.0 >Reporter: Rick Hillegas > > The work on DERBY-64 seems to have opened up a wormhole by which you can > create user tables with BOOLEAN columns. The following script shows how to do > this: > drop table foo; > create table foo > as select systemalias from sys.sysaliases with no data; > rename column foo.systemalias to boolcol; > alter table foo > alter column boolcol null; > select c.columndatatype > from sys.syscolumns c, sys.systables t > where t.tableid=c.referenceid > and t.tablename='FOO'; > insert into foo( boolcol ) > values > ( 0 ), > ( 1 ), > ( cast (null as int) ) > ; > select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (21 issues) Subscriber: derby-dev Key Summary DERBY-2508 Implement the XA transaction timeout support for embedded driver. https://issues.apache.org/jira/browse/DERBY-2508 DERBY-2600 Remove temporary code added to enable testing of CLOB locator related stored procedures. https://issues.apache.org/jira/browse/DERBY-2600 DERBY-2496 Implement Blob support for Locators https://issues.apache.org/jira/browse/DERBY-2496 DERBY-2327 Reduce monitor contention in LockSet https://issues.apache.org/jira/browse/DERBY-2327 DERBY-2506 Adding the locator information to FD:OCA descriptor (FDODSC) andFD:OCA data (FDODTA) of the SQLDTA objects https://issues.apache.org/jira/browse/DERBY-2506 DERBY-2280 DatabaseMetaData.getTypeInfo() UNSIGNED_ATTRIBUTE and AUTO_INCREMENT column returns incorrect information for BLOB & CLOB data type https://issues.apache.org/jira/browse/DERBY-2280 DERBY-2594 Revoking a privilege from an SQL Object should invalidate statements dependent on that object https://issues.apache.org/jira/browse/DERBY-2594 DERBY-1001 Rewrite 'store/encryptionKey.sql' to a JUnit test https://issues.apache.org/jira/browse/DERBY-1001 DERBY-2385 create the stored procedures called by LOB related JDBC methods during upgrade https://issues.apache.org/jira/browse/DERBY-2385 DERBY-2501 Batch scripts in bin\ report extraneous errors when DERBY_HOME is invalid https://issues.apache.org/jira/browse/DERBY-2501 DERBY-2565 BrokeredConnection needs to forward implementations of locator related methods in EngineConnection to the underlying physical connection https://issues.apache.org/jira/browse/DERBY-2565 DERBY-2519 Clean-up in BlobClob4BlobTest https://issues.apache.org/jira/browse/DERBY-2519 DERBY-2597 Language result sets should not reuse current isolation level across executions https://issues.apache.org/jira/browse/DERBY-2597 DERBY-1054 Starting Derby with the NetServlet inside of tomcat does not allow binding to non localhost interface. https://issues.apache.org/jira/browse/DERBY-1054 DERBY-2462 org.apache.derby.impl.store.access.BackingStoreHashTableFromScan does not honor ResultSet holdability https://issues.apache.org/jira/browse/DERBY-2462 DERBY-2020 Change file option for syncing log file to disk from rws to rwd https://issues.apache.org/jira/browse/DERBY-2020 DERBY- 'show indexes in SCHEMANAME' does not work with the client driver https://issues.apache.org/jira/browse/DERBY- DERBY-2569 The check to see if two DataTypeDescriptors(DTDs) are comparable or not needs to consider collation into decision. https://issues.apache.org/jira/browse/DERBY-2569 DERBY-2230 AssertFailure: ByteCode Conditional then/else stack mismatch https://issues.apache.org/jira/browse/DERBY-2230 DERBY-2416 Provide collation sensitive subclasses for SQLChar, SQLVarchar, SQLLongvarchar and SQLClob which will use the passed Collator to do the collation rather than the default collation of UCS_BASIC https://issues.apache.org/jira/browse/DERBY-2416 DERBY-2255 ij should indicate that it is waiting for more input in a multi-line interactive statement. https://issues.apache.org/jira/browse/DERBY-2255
[jira] Created: (DERBY-2605) You can create BOOLEAN columns in 10.3
You can create BOOLEAN columns in 10.3 -- Key: DERBY-2605 URL: https://issues.apache.org/jira/browse/DERBY-2605 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.3.0.0 Reporter: Rick Hillegas The work on DERBY-64 seems to have opened up a wormhole by which you can create user tables with BOOLEAN columns. The following script shows how to do this: drop table foo; create table foo as select systemalias from sys.sysaliases with no data; rename column foo.systemalias to boolcol; alter table foo alter column boolcol null; select c.columndatatype from sys.syscolumns c, sys.systables t where t.tableid=c.referenceid and t.tablename='FOO'; insert into foo( boolcol ) values ( 0 ), ( 1 ), ( cast (null as int) ) ; select * from foo; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2603) Minor erratum in page of VARCHAR in Derby Reference manual
[ https://issues.apache.org/jira/browse/DERBY-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493380 ] Bryan Pendleton commented on DERBY-2603: Could you expand on why you think that "binary" should be replaced by "boolean"? I understand "binary" to describe the number of *arguments* that the operator has. I understand "boolean" to describe the *result* of the operator. Thus, to me, the two words are not easily interchangeable, so I'm interested to understand more about the issue as you see it. Thanks! > Minor erratum in page of VARCHAR in Derby Reference manual > -- > > Key: DERBY-2603 > URL: https://issues.apache.org/jira/browse/DERBY-2603 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefsqlj41207.html >Reporter: Tomohito Nakayama >Priority: Minor > > I found next statement in the page through translation into Japanese. > > When binary comparison operators are applied to VARCHARs, the lengths of > > the operands are not altered, and spaces at the end of the values are > > ignored. > I think "binary" should be replaced as "boolean". > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2604) Implement Clob support for locators
[ https://issues.apache.org/jira/browse/DERBY-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-2604: --- Attachment: ClobLocatorWork_v1.stat ClobLocatorWork_v1.diff The attached patch, ClobLocatorWork_v1.diff, adds support for locators for Clob methods. Note that the use of locators for Clob is still not enabled. This as mentioned will be done as a seperate JIRA issue. The changes to the various files and their purport are as following M java/client/org/apache/derby/client/net/NetCursor.java Create locator based Clob object if locator is sent. A java/client/org/apache/derby/client/am/ClobLocatorWriter.java Writer for locator based Clob. M java/client/org/apache/derby/client/am/Clob.java Add constructor for locator based Clob objects. Make all Clob operations support locators. Operations are performed by calling stored procedures through the framework implemented by CallableLocatorProcedures class. Create locator based versions of streams for locator based Clob objects A java/client/org/apache/derby/client/am/ClobLocatorInputStream.java InputStream for locator based Clob. A java/client/org/apache/derby/client/am/ClobLocatorOutputStream.java OutputStream for locator based Clob. A java/client/org/apache/derby/client/am/ClobLocatorReader.java Reader for locator based Clob. I have run tests(junit All) on this patch and there were no failures. > Implement Clob support for locators > --- > > Key: DERBY-2604 > URL: https://issues.apache.org/jira/browse/DERBY-2604 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan > Assigned To: V.Narayanan > Attachments: ClobLocatorWork_v1.diff, ClobLocatorWork_v1.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Debug tracing
Hi Dyre, I think this is a very good idea. I can see some stuff related to SanityManager calls (mostly DEBUG) all over the code but do not know how to get some benefit from that. Thanks Julo [EMAIL PROTECTED] wrote: During my dives into the Derby source I have stumbled across SanityManager.DEBUG_ON() which allows you to turn on specific behavior in a sane Derby through the properties derby.debug.true and derby.debug.false. Or rather, that is my understanding after reading the code. Is this stuff expained anywhere? I tried searching db.apache.org with google, but I didn't find anything. There is the Javadoc for SanityManager, but does not explain which property to set, and the values to use. There also appears to be possible to use different logging streams. Assuming such a document doesn't exist: Would it be good to collect some "best practices" for this, say on the Wiki? Stuff like: - When to use logging streams, and when is System.out System.err is OK? - Which stream to use, and how to obtain it - Threading implications - Performance considerations - Guidelines for making new debug flags. Should there be some kind of convention to avoid name clashes? I can volunteer to create such a Wiki page. Just wanted to know if there is an an "oral tradition" for this.
[jira] Commented: (DERBY-2508) Implement the XA transaction timeout support for embedded driver.
[ https://issues.apache.org/jira/browse/DERBY-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493367 ] Julius Stroffek commented on DERBY-2508: Dan, I am sorry, I forgot to explain that. I was also not able to find anything in JDBC/JTA spec except a small piece in XAResource.get/setTransactionTimeout javadoc. --- The xa transaction timeout can by set up by calling XAResource.setTransactionTimeout, if the value 0 is specified (or the setTransactionTimout function was not called for the XAResource instance) the value of transaction timeout is the database default. The database default value of xa transaction timeout can be specified in derby.jdbc.xaTransactionTimeout system property. The value of timeout is in seconds and if it is equal to 0 the transaction timeout feature is disabled.The default value of default xa transaction timeout is currently 300 seconds. I think that this might/should be changed to 0 because this would be consistent with a previous behavior (no xa transaction timeout). The timeout is measured since the application calls the XAResource.start method until XAResource.commit/rollback is called. It does not matter whether the transaction is later associated or not associated with any XAResource. Once a transaction is rolled back due to timing out all the knowledge of the global transaction is discarded. If it was associated with some XAResource instance, it would be disassociated. If there was a running statement it would be canceled and the exception (SQLState.LANG_STATEMENT_CANCELLED_OR_TIMED_OUT) would be thrown to the application. An option would be to roll back the transaction when it times out and remember that transaction for a while and throw the timeout related exceptions to the client and do the final cleanup after some time. This might help when identifying a timeout related issues on a client. Please, feel free to give any comments or suggestions to the behavior or implementation. > Implement the XA transaction timeout support for embedded driver. > - > > Key: DERBY-2508 > URL: https://issues.apache.org/jira/browse/DERBY-2508 > Project: Derby > Issue Type: Sub-task >Affects Versions: 10.2.2.0 >Reporter: Julius Stroffek > Assigned To: Julius Stroffek > Fix For: 10.3.0.0 > > Attachments: d2432_beta1.diff, d2432_beta1.stat, d2508.diff, > d2508.stat > > > Implement the XA transaction support for embedded driver in EmbedXAResource. > Implement functions XAResource.setTransactionTimeout and > XAResource.getTransactionTimeout and add the code to cancel the transaction > after the specified period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2600) Remove temporary code added to enable testing of CLOB locator related stored procedures.
[ https://issues.apache.org/jira/browse/DERBY-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493360 ] V.Narayanan commented on DERBY-2600: Thanks a ton for the commit Rick. Many thanks for the reviews and comments and the final commit for the patch. Narayanan > Remove temporary code added to enable testing of CLOB locator related stored > procedures. > > > Key: DERBY-2600 > URL: https://issues.apache.org/jira/browse/DERBY-2600 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan > Assigned To: V.Narayanan > Attachments: RemoveTemporaryCode_v1.diff, RemoveTemporaryCode_v1.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2604) Implement Clob support for locators
[ https://issues.apache.org/jira/browse/DERBY-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan reassigned DERBY-2604: -- Assignee: V.Narayanan > Implement Clob support for locators > --- > > Key: DERBY-2604 > URL: https://issues.apache.org/jira/browse/DERBY-2604 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan > Assigned To: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2604) Implement Clob support for locators
[ https://issues.apache.org/jira/browse/DERBY-2604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493359 ] V.Narayanan commented on DERBY-2604: DERBY-2347 adds the possibility to send locators between client and server instead of LOB values. DERBY-2496 adds locator support to Blobs On the same lines we need to add locator support for Clobs also. The changes that will be done as part of this issue will cover most of the locator work that would need be done with respect to Clobs. As already discussed in the JIRA issue that was raised for PreparedStatements and CallableStatements(https://issues.apache.org/jira/browse/DERBY-2529) there are no changes needed here related to Clob also. A similar case would exist for ResultSets also since the LOB in this case is also B-Layer streamed and there would be no significant improvement with using locators. Connection.createClob() will use the constructor that would be introduced in this patch which accepts a locator as a parameter to return an empty Clob. The locators will not be enabled with this patch. A seperate issue will be raised to enable locators and handle test failures that might result because of that. > Implement Clob support for locators > --- > > Key: DERBY-2604 > URL: https://issues.apache.org/jira/browse/DERBY-2604 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r531491 - /db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java
Hi,
Can't see why the method getLastSQLException was moved as part of commit
530868, as I made that change as part of my (incomplete) patch for
DERBY-1001.
As far as I can see, no other code is using this method besides the one
occurrence in PreparedStatementTest and my (uncommitted) EncryptionKeyTest.
If anyone want to comment on the usage of this method, please do so in
DERBY-1001.
--
Kristian
[EMAIL PROTECTED] wrote:
Author: kmarsden
Date: Mon Apr 23 08:08:20 2007
New Revision: 531491
URL: http://svn.apache.org/viewvc?view=rev&rev=531491
Log:
fix javadoc warning
Modified:
db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java
Modified:
db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java
URL:
http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java?view=diff&rev=531491&r1=531490&r2=531491
==
---
db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java
(original)
+++
db/derby/code/trunk/java/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java
Mon Apr 23 08:08:20 2007
@@ -860,7 +860,7 @@
/**
* Get the last SQLException in chain.
- * @param a SQLException
+ * @param sqle SQLException
* @return the last exception in the chain.
*/
public SQLException getLastSQLException(SQLException sqle) {
[jira] Commented: (DERBY-2600) Remove temporary code added to enable testing of CLOB locator related stored procedures.
[ https://issues.apache.org/jira/browse/DERBY-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493357 ] Rick Hillegas commented on DERBY-2600: -- Thanks for the patch, Narayanan. Looks non-controversial to me. Tests ran cleanly for me. Committed at subversion revision 534824. > Remove temporary code added to enable testing of CLOB locator related stored > procedures. > > > Key: DERBY-2600 > URL: https://issues.apache.org/jira/browse/DERBY-2600 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan > Assigned To: V.Narayanan > Attachments: RemoveTemporaryCode_v1.diff, RemoveTemporaryCode_v1.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2604) Implement Clob support for locators
Implement Clob support for locators --- Key: DERBY-2604 URL: https://issues.apache.org/jira/browse/DERBY-2604 Project: Derby Issue Type: Sub-task Reporter: V.Narayanan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2587) Connection.createClob() and Connection.createBlob() need to return locator support enabled LOB objects in the NetworkClient
[ https://issues.apache.org/jira/browse/DERBY-2587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493355 ] V.Narayanan commented on DERBY-2587: I see these errors on a run with a fresh workspace also. Confirms that these errors are not due to my patch. I request for v3 to be considered for reviews and comments and if everything is OK a commit too. > Connection.createClob() and Connection.createBlob() need to return locator > support enabled LOB objects in the NetworkClient > --- > > Key: DERBY-2587 > URL: https://issues.apache.org/jira/browse/DERBY-2587 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan > Assigned To: V.Narayanan > Attachments: ConnectionLocatorWork_v1.diff, > ConnectionLocatorWork_v1.stat, ConnectionLocatorWork_v2.diff, > ConnectionLocatorWork_v2.stat, ConnectionLocatorWork_v3.diff, > ConnectionLocatorWork_v3.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2496) Implement Blob support for Locators
[ https://issues.apache.org/jira/browse/DERBY-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Øystein Grøvlen updated DERBY-2496: --- Attachment: blob-followup_v2.diff Reattaching the patch since I forgot to grant license. > Implement Blob support for Locators > --- > > Key: DERBY-2496 > URL: https://issues.apache.org/jira/browse/DERBY-2496 > Project: Derby > Issue Type: Sub-task >Reporter: Øystein Grøvlen > Assigned To: Øystein Grøvlen > Attachments: blob-followup.diff, blob-followup_v2.diff, > blob-followup_v2.diff, blob.diff, blob_v2.diff > > > DERBY-2347 adds the possibility to send locators between client and server > instead of LOB values. This has not been activated yet, since the client > implementation does not currently support locators. This report is for > supporting the locators for Blob objects. Another JIRA issue will be made > for Clob. > This work will be made in several steps: >1. Blob methods and ResultSet.getXXX methods >2. PreparedStatement and CallableStatement methods >3. ResultSet.updateXXX methods >4. Connection.createBlob() > There is dependencies between these steps and it might be that the Locator > implementation cannot be exposed until everything has been done. At least, > doing just step 1, gives testing errors because tests use Blobs fetched from > DB as parameters to prepared statements. I would guess tests for updatable > result sets, needs the combination of 1. and 3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2496) Implement Blob support for Locators
[ https://issues.apache.org/jira/browse/DERBY-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Øystein Grøvlen updated DERBY-2496: --- Attachment: blob-followup_v2.diff > Rick Hillegas commented on DERBY-2496: > -- > > Thanks for the changes, Øystein. I am afraid I'm having some > trouble applying blob-followup.diff. My patch tool could not apply > the changes in BlobLocatorInputStream. So I tried applying them by > hand. I ended up with compile errors in Blob.java because: Sorry about that. I do not understand how I got that to compile. I have attached a new version of the patch, blob-followup_v2.diff where I make sure to catch the SqlException. I also updated my sandbox, so hopefully you will be able to apply this version. > Implement Blob support for Locators > --- > > Key: DERBY-2496 > URL: https://issues.apache.org/jira/browse/DERBY-2496 > Project: Derby > Issue Type: Sub-task >Reporter: Øystein Grøvlen > Assigned To: Øystein Grøvlen > Attachments: blob-followup.diff, blob-followup_v2.diff, blob.diff, > blob_v2.diff > > > DERBY-2347 adds the possibility to send locators between client and server > instead of LOB values. This has not been activated yet, since the client > implementation does not currently support locators. This report is for > supporting the locators for Blob objects. Another JIRA issue will be made > for Clob. > This work will be made in several steps: >1. Blob methods and ResultSet.getXXX methods >2. PreparedStatement and CallableStatement methods >3. ResultSet.updateXXX methods >4. Connection.createBlob() > There is dependencies between these steps and it might be that the Locator > implementation cannot be exposed until everything has been done. At least, > doing just step 1, gives testing errors because tests use Blobs fetched from > DB as parameters to prepared statements. I would guess tests for updatable > result sets, needs the combination of 1. and 3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-513) Add information on how to change the jdk version a test will be compiled with in testing/readme.htm.
[ https://issues.apache.org/jira/browse/DERBY-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-513. - > Add information on how to change the jdk version a test will be compiled with > in testing/readme.htm. > > > Key: DERBY-513 > URL: https://issues.apache.org/jira/browse/DERBY-513 > Project: Derby > Issue Type: Improvement > Components: Documentation >Reporter: Fernanda Pizzorno > Assigned To: Fernanda Pizzorno >Priority: Minor > Attachments: DERBY-513.diff > > > Add the following item to section 4.7 Adding a new test: > * If the test file must be compiled using jdk1.4 instead of jdk1.3, > * edit the build.xml file located in the same directory as the test > * exclude the new test file under compilet1 > > * include it under compilet2. > . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Debug tracing
V Narayanan <[EMAIL PROTECTED]> writes: > Hi Dyre, > > Does this link http://wiki.apache.org/db-derby/ProtocolDebuggingTips > seem to be of relevance here? Thanks for the link. My proxy-server seems to be down, so I can't read it right now, but I'll look at it when it comes back up... -- dt
[jira] Updated: (DERBY-2587) Connection.createClob() and Connection.createBlob() need to return locator support enabled LOB objects in the NetworkClient
[ https://issues.apache.org/jira/browse/DERBY-2587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] V.Narayanan updated DERBY-2587: --- Attachment: ConnectionLocatorWork_v3.stat ConnectionLocatorWork_v3.diff Thanks again for the review of the patch Rick. I have attached a patch with all the issues pointed out by you addressed. I saw a couple of errors which I have not seen before during test runs. I have pasted a snippet of the error output below. I seem to get such errors sporadically in my laptop. I am sure this error is not due to the using ExceptionUtil. But just to confirm I will run the tests again in another machine and I will run the tests on a fresh workspace in the laptop and revert back with the results. I request for this patch to be considered for reviews and comments. FormatableError:read error: java.io.EOFException FormatableError:class written : class org.apache.derby.impl.store.access.heap.Heap FormatableError:read back as null FormatableError:write id : 467 java.io.EOFException at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:273) at org.apache.derby.iapi.services.io.CompressedNumber.readInt(CompressedNumber.java:127) at org.apache.derby.impl.store.access.conglomerate.ConglomerateUtil.readCollationIdArray(ConglomerateUtil.java:328) at org.apache.derby.impl.store.access.heap.Heap.localReadExternal(Heap.java:1219) at org.apache.derby.impl.store.access.heap.Heap.readExternal(Heap.java:1238) at org.apache.derby.iapi.services.io.FormatIdInputStream.readObject(FormatIdInputStream.java:126) at org.apache.derby.iapi.services.io.DebugByteTeeOutputStream.checkObject(DebugByteTeeOutputStream.java:59) at org.apache.derby.iapi.services.io.FormatIdOutputStream.writeObject(FormatIdOutputStream.java:151) at org.apache.derby.iapi.services.io.ArrayUtil.writeArrayItems(ArrayUtil.java:75) at org.apache.derby.impl.sql.GenericStorablePreparedStatement.writeExternal(GenericStorablePreparedStatement.java:197) at org.apache.derby.iapi.services.io.FormatIdOutputStream.writeObject(FormatIdOutputStream.java:165) at org.apache.derby.iapi.types.UserType.writeExternal(UserType.java:286) at org.apache.derby.impl.store.raw.data.StoredPage.logColumn(StoredPage.java:6233) at org.apache.derby.impl.store.raw.data.StoredPage.logRow(StoredPage.java:3953) at org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDataToBuffer(UpdateOperation.java:255) at org.apache.derby.impl.store.raw.data.UpdateOperation.(UpdateOperation.java:106) at org.apache.derby.impl.store.raw.data.LoggableActions.actionUpdate(LoggableActions.java:80) at org.apache.derby.impl.store.raw.data.StoredPage.doUpdateAtSlot(StoredPage.java:8521) at org.apache.derby.impl.store.raw.data.BasePage.updateAtSlot(BasePage.java:983) at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:468) at org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:523) at org.apache.derby.impl.sql.catalog.TabInfoImpl.updateRow(TabInfoImpl.java:1100) at org.apache.derby.impl.sql.catalog.TabInfoImpl.updateRow(TabInfoImpl.java:975) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.updateSPS(DataDictionaryImpl.java:3491) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.updateSYSSTATEMENTS(SPSDescriptor.java:1097) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(SPSDescriptor.java:706) at org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(SPSDescriptor.java:642) at org.apache.derby.impl.sql.compile.ExecSPSNode.generate(ExecSPSNode.java:177) > Connection.createClob() and Connection.createBlob() need to return locator > support enabled LOB objects in the NetworkClient > --- > > Key: DERBY-2587 > URL: https://issues.apache.org/jira/browse/DERBY-2587 > Project: Derby > Issue Type: Sub-task >Reporter: V.Narayanan > Assigned To: V.Narayanan > Attachments: ConnectionLocatorWork_v1.diff, > ConnectionLocatorWork_v1.stat, ConnectionLocatorWork_v2.diff, > ConnectionLocatorWork_v2.stat, ConnectionLocatorWork_v3.diff, > ConnectionLocatorWork_v3.stat > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Debug tracing
Hi Dyre, Does this link http://wiki.apache.org/db-derby/ProtocolDebuggingTips seem to be of relevance here? Narayanan [EMAIL PROTECTED] wrote On 05/03/07 15:24,: During my dives into the Derby source I have stumbled across SanityManager.DEBUG_ON() which allows you to turn on specific behavior in a sane Derby through the properties derby.debug.true and derby.debug.false. Or rather, that is my understanding after reading the code. Is this stuff expained anywhere? I tried searching db.apache.org with google, but I didn't find anything. There is the Javadoc for SanityManager, but does not explain which property to set, and the values to use. There also appears to be possible to use different logging streams. Assuming such a document doesn't exist: Would it be good to collect some "best practices" for this, say on the Wiki? Stuff like: - When to use logging streams, and when is System.out System.err is OK? - Which stream to use, and how to obtain it - Threading implications - Performance considerations - Guidelines for making new debug flags. Should there be some kind of convention to avoid name clashes? I can volunteer to create such a Wiki page. Just wanted to know if there is an an "oral tradition" for this.
Debug tracing
During my dives into the Derby source I have stumbled across SanityManager.DEBUG_ON() which allows you to turn on specific behavior in a sane Derby through the properties derby.debug.true and derby.debug.false. Or rather, that is my understanding after reading the code. Is this stuff expained anywhere? I tried searching db.apache.org with google, but I didn't find anything. There is the Javadoc for SanityManager, but does not explain which property to set, and the values to use. There also appears to be possible to use different logging streams. Assuming such a document doesn't exist: Would it be good to collect some "best practices" for this, say on the Wiki? Stuff like: - When to use logging streams, and when is System.out System.err is OK? - Which stream to use, and how to obtain it - Threading implications - Performance considerations - Guidelines for making new debug flags. Should there be some kind of convention to avoid name clashes? I can volunteer to create such a Wiki page. Just wanted to know if there is an an "oral tradition" for this. -- dt
Re: opinions please on possible existing app impact of DERBY-1828
Daniel John Debrunner wrote (2007-05-02 10:06:42): > Myrna van Lunteren wrote: > >Hi, > > > >In DERBY-1828, Jørgen proposes to adjust some SQLStates in the > >authorization area. > >I'd like the community's input on the release-related question: > > > >Jørgen asks: > >"Q1) I need your opinion on whether or not this issue can be fixed > >before the next major release. I.e., may new error codes cause > >problems for existing applications?" > > I say it's fine to make the change, it's very unlikely existing Derby > applications are dependent on the SQL state for a authorization > failure. +1 Also, it's better to change it now than at an later stage when there (hopefully) will be a significant codebase out there dependant on these SQLStates. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: Digital signature
[jira] Updated: (DERBY-2603) Minor erratum in page of VARCHAR in Derby Reference manual
[ https://issues.apache.org/jira/browse/DERBY-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomohito Nakayama updated DERBY-2603: - Component/s: Documentation > Minor erratum in page of VARCHAR in Derby Reference manual > -- > > Key: DERBY-2603 > URL: https://issues.apache.org/jira/browse/DERBY-2603 > Project: Derby > Issue Type: Bug > Components: Documentation > Environment: > http://db.apache.org/derby/docs/dev/ref/rrefsqlj41207.html >Reporter: Tomohito Nakayama >Priority: Minor > > I found next statement in the page through translation into Japanese. > > When binary comparison operators are applied to VARCHARs, the lengths of > > the operands are not altered, and spaces at the end of the values are > > ignored. > I think "binary" should be replaced as "boolean". > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DERBY-2603) Minor erratum in page of VARCHAR in Derby Reference manual
Minor erratum in page of VARCHAR in Derby Reference manual -- Key: DERBY-2603 URL: https://issues.apache.org/jira/browse/DERBY-2603 Project: Derby Issue Type: Bug Environment: http://db.apache.org/derby/docs/dev/ref/rrefsqlj41207.html Reporter: Tomohito Nakayama Priority: Minor I found next statement in the page through translation into Japanese. > When binary comparison operators are applied to VARCHARs, the lengths of the > operands are not altered, and spaces at the end of the values are ignored. I think "binary" should be replaced as "boolean". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
