[jira] [Commented] (DERBY-6975) ERROR 40XL1: A lock could not be obtained within the time requested
[
https://issues.apache.org/jira/browse/DERBY-6975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16232597#comment-16232597
]
Rick Hillegas commented on DERBY-6975:
--
Thanks for describing your experience, David. A couple questions:
1) Have you tried adjusting the value of derby.language.sequence.preallocator?
2) How many sessions are accessing this sequence generator concurrently?
3) Does the sequence generator correspond to a named sequence or to an identity
column?
4) Does any session call Statement.getGeneratedKeys()?
3) Does any session read from SYS.SYSSEQUENCES?
Thanks,
-Rick
> ERROR 40XL1: A lock could not be obtained within the time requested
>
>
> Key: DERBY-6975
> URL: https://issues.apache.org/jira/browse/DERBY-6975
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.1.0
>Reporter: David Sitsky
>Priority: Major
>
> I have an application that when run on a certain dataset, every 5 runs I
> might see this error happening. The code is creating a lot of rows using a
> sequence generator.
> {noformat}
> Caused by: ERROR 40XL1: A lock could not be obtained within the time
> requested
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
>
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
>
> at
> org.apache.derby.impl.sql.catalog.SequenceUpdater.tooMuchContentionException(SequenceUpdater.java)
>
> at
> org.apache.derby.impl.sql.catalog.SequenceUpdater.getCurrentValueAndAdvance(SequenceUpdater.java)
>
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getCurrentValueAndAdvance(DataDictionaryImpl.java)
>
> at
> org.apache.derby.impl.sql.execute.BaseActivation.getCurrentValueAndAdvance(BaseActivation.java)
>
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.getSetAutoincrementValue(InsertResultSet.java)
>
> at
> org.apache.derby.impl.sql.execute.BaseActivation.getSetAutoincrementValue(BaseActivation.java)
>
> at
> org.apache.derby.exe.ac560740aax015fx6bc1x68cax02339e626a.e0(ac560740aax015fx6bc1x68cax02339e626a.java)
>
> at
> org.apache.derby.impl.services.reflect.DirectCall.invoke(DirectCall.java)
> at
> org.apache.derby.impl.sql.execute.RowResultSet.getNextRowCore(RowResultSet.java)
>
> at
> org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java)
>
> at
> org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java)
>
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.getNextRowCore(InsertResultSet.java)
>
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java)
>
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java)
>
> ... 25 more
> {noformat}
> It is not clear to me why when looking at the code this should be happening.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-5543) include debug info in derby builds uploaded to maven
[ https://issues.apache.org/jira/browse/DERBY-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-5543: - Urgency: Urgent (was: Low) > include debug info in derby builds uploaded to maven > > > Key: DERBY-5543 > URL: https://issues.apache.org/jira/browse/DERBY-5543 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.8.2.2 >Reporter: Sean Bridges >Assignee: Rick Hillegas >Priority: Minor > > Looking at a strack trace from derby retrieved through maven, I see that > derby is compiled without debug information, this means line numbers are not > available in stack traces, > Caused by: java.lang.NullPointerException > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openDroppedContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.xact.Xact.openDroppedContainer(Unknown Source) > at > org.apache.derby.impl.store.raw.data.PageBasicOperation.findpage(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.PageBasicOperation.needsRedo(Unknown > Source) > and it is harder to debug code by setting breakpoints within derby. Derby > deployed to maven should have debug information included. > I'm not sure how this is controlled, but looking at pom.xml I see, > > insane > The default should be sane. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-5543) include debug info in derby builds uploaded to maven
[ https://issues.apache.org/jira/browse/DERBY-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16226739#comment-16226739 ] Rick Hillegas commented on DERBY-5543: -- I have assigned this bug to myself. I think that line numbers by themselves (without the extra debug information) will only marginally increase the size of the Derby artifacts. The advocates for super-slim artifacts no longer actively contribute to Derby. I do not expect further resistance to this change. > include debug info in derby builds uploaded to maven > > > Key: DERBY-5543 > URL: https://issues.apache.org/jira/browse/DERBY-5543 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.8.2.2 >Reporter: Sean Bridges >Assignee: Rick Hillegas >Priority: Minor > > Looking at a strack trace from derby retrieved through maven, I see that > derby is compiled without debug information, this means line numbers are not > available in stack traces, > Caused by: java.lang.NullPointerException > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openDroppedContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.xact.Xact.openDroppedContainer(Unknown Source) > at > org.apache.derby.impl.store.raw.data.PageBasicOperation.findpage(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.PageBasicOperation.needsRedo(Unknown > Source) > and it is harder to debug code by setting breakpoints within derby. Derby > deployed to maven should have debug information included. > I'm not sure how this is controlled, but looking at pom.xml I see, > > insane > The default should be sane. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (DERBY-5543) include debug info in derby builds uploaded to maven
[ https://issues.apache.org/jira/browse/DERBY-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas reassigned DERBY-5543: Assignee: Rick Hillegas > include debug info in derby builds uploaded to maven > > > Key: DERBY-5543 > URL: https://issues.apache.org/jira/browse/DERBY-5543 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.8.2.2 >Reporter: Sean Bridges >Assignee: Rick Hillegas >Priority: Minor > > Looking at a strack trace from derby retrieved through maven, I see that > derby is compiled without debug information, this means line numbers are not > available in stack traces, > Caused by: java.lang.NullPointerException > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openDroppedContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.xact.Xact.openDroppedContainer(Unknown Source) > at > org.apache.derby.impl.store.raw.data.PageBasicOperation.findpage(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.PageBasicOperation.needsRedo(Unknown > Source) > and it is harder to debug code by setting breakpoints within derby. Derby > deployed to maven should have debug information included. > I'm not sure how this is controlled, but looking at pom.xml I see, > > insane > The default should be sane. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6974) Deprecate support for building Derby under JDK 8
[ https://issues.apache.org/jira/browse/DERBY-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16224203#comment-16224203 ] Rick Hillegas commented on DERBY-6974: -- Tests ran cleanly on derby-6974-01-ab-deprecateJDK8.diff. Tests were run on sane and insane jars. Tests included full upgrade tests, starting at every previous release of Derby. Verified that javadoc builds cleanly. I believe that this patch is ready to be committed. > Deprecate support for building Derby under JDK 8 > > > Key: DERBY-6974 > URL: https://issues.apache.org/jira/browse/DERBY-6974 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.15.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6974-01-aa-deprecateJDK8.diff, > derby-6974-01-ab-deprecateJDK8.diff > > > In July, the Derby community voted to deprecate support for JDK 8 and move > development on the 10.15 trunk to JDK 9. See > http://apache-database.10148.n7.nabble.com/RESULT-VOTE-Sunsetting-support-for-Java-8-td147735.html > This issue tracks the work of converting the Derby build from JDK 8 to JDK 9 > and higher. This effort relies on the work already done on DERBY-6856. > Platform-specific distributions of Oracle JDK 9 can be found here: > http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6974) Deprecate support for building Derby under JDK 8
[ https://issues.apache.org/jira/browse/DERBY-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6974: - Attachment: derby-6974-01-ab-deprecateJDK8.diff Attaching derby-6974-01-ab-deprecateJDK8.diff. This corrects a bug in the previous patch: the client jar file did not include the JCBC 4.2 support. I will continue running tests. > Deprecate support for building Derby under JDK 8 > > > Key: DERBY-6974 > URL: https://issues.apache.org/jira/browse/DERBY-6974 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.15.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6974-01-aa-deprecateJDK8.diff, > derby-6974-01-ab-deprecateJDK8.diff > > > In July, the Derby community voted to deprecate support for JDK 8 and move > development on the 10.15 trunk to JDK 9. See > http://apache-database.10148.n7.nabble.com/RESULT-VOTE-Sunsetting-support-for-Java-8-td147735.html > This issue tracks the work of converting the Derby build from JDK 8 to JDK 9 > and higher. This effort relies on the work already done on DERBY-6856. > Platform-specific distributions of Oracle JDK 9 can be found here: > http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6974) Deprecate support for building Derby under JDK 8
[ https://issues.apache.org/jira/browse/DERBY-6974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6974: - Attachment: derby-6974-01-aa-deprecateJDK8.diff Attaching derby-6974-01-aa-deprecateJDK8.diff. This patch converts the build to JDK 9. I will run tests. This patch makes the following changes: 1) Applies derby-6856-XX-ae-base.diff so that Derby will build cleanly with JDK9. 2) Adjusts the build so that it will fail fast if the JDK level is not at least JDK 9. Removes remaining references to jdk8-specific build variables. 3) Simplifies the instructions for building Derby. Touches the following files: M java/build/org/apache/derbyBuild/javadoc/DiskLayoutTaglet.java M java/build/org/apache/derbyBuild/javadoc/EndFormatTaglet.java M java/build/org/apache/derbyBuild/javadoc/FormatIdTaglet.java M java/build/org/apache/derbyBuild/javadoc/PurposeTaglet.java M java/build/org/apache/derbyBuild/javadoc/UpgradeTaglet.java M java/client/org/apache/derby/jdbc/BasicClientXADataSource40.java M java/client/org/apache/derby/jdbc/ClientXADataSource.java M java/client/org/apache/derby/jdbc/ClientXADataSource40.java M java/client/org/apache/derby/jdbc/ClientXADataSourceInterface.java M java/engine/org/apache/derby/jdbc/EmbeddedXADataSourceInterface.java 1) Applies derby-6856-XX-ae-base.diff so that Derby will build cleanly with JDK9. M build.xml M java/client/build.xml M java/engine/org/apache/derby/iapi/jdbc/build.xml M java/engine/org/apache/derby/impl/jdbc/build.xml M java/engine/org/apache/derby/jdbc/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/build.xml 2) Adjusts the build so that it will fail fast if the JDK level is not at least JDK 9. Removed remaining references to jdk8-specific build variables. M BUILDING.html 3) Simplifies the instructions for building Derby. > Deprecate support for building Derby under JDK 8 > > > Key: DERBY-6974 > URL: https://issues.apache.org/jira/browse/DERBY-6974 > Project: Derby > Issue Type: Task > Components: Build tools >Affects Versions: 10.15.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6974-01-aa-deprecateJDK8.diff > > > In July, the Derby community voted to deprecate support for JDK 8 and move > development on the 10.15 trunk to JDK 9. See > http://apache-database.10148.n7.nabble.com/RESULT-VOTE-Sunsetting-support-for-Java-8-td147735.html > This issue tracks the work of converting the Derby build from JDK 8 to JDK 9 > and higher. This effort relies on the work already done on DERBY-6856. > Platform-specific distributions of Oracle JDK 9 can be found here: > http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DERBY-6974) Deprecate support for building Derby under JDK 8
Rick Hillegas created DERBY-6974: Summary: Deprecate support for building Derby under JDK 8 Key: DERBY-6974 URL: https://issues.apache.org/jira/browse/DERBY-6974 Project: Derby Issue Type: Task Components: Build tools Affects Versions: 10.15.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas In July, the Derby community voted to deprecate support for JDK 8 and move development on the 10.15 trunk to JDK 9. See http://apache-database.10148.n7.nabble.com/RESULT-VOTE-Sunsetting-support-for-Java-8-td147735.html This issue tracks the work of converting the Derby build from JDK 8 to JDK 9 and higher. This effort relies on the work already done on DERBY-6856. Platform-specific distributions of Oracle JDK 9 can be found here: http://www.oracle.com/technetwork/java/javase/downloads/jdk9-downloads-3848520.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6972) Delay for getting derby connection (Connection Reset and Waiting for a connection)
[ https://issues.apache.org/jira/browse/DERBY-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216176#comment-16216176 ] Rick Hillegas commented on DERBY-6972: -- The server raises this error when it receives a garbled DRDA Data Stream Structure header. The error message suggests that the client and server sides of the connection may not agree on whether the connection is SSL protected. Is that a possibility? > Delay for getting derby connection (Connection Reset and Waiting for a > connection) > -- > > Key: DERBY-6972 > URL: https://issues.apache.org/jira/browse/DERBY-6972 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.11.1.1 >Reporter: Sridhar Jena >Priority: Critical > > Hi Team, > This is regarding a derby connection issue in network mode. > We are using Apache derby in network mode. Below are the version we are using > for client server communication, > Client Jar Version : *derbyclient-10.13.1.1.jar* > Server Version : * Apache Derby Network Server - 10.11.1.1* > We are facing three types of connection issue while getting database > connection from our java application. > 1. A communications error has been detected: Connection reset > 2. Waiting for a connection with a long period of time. > 3. Error connecting to server 127.0.0.1 on port 1,527 with message connect > timed out. > At the same time if we are checking the derby.log in derby server, we found > below exceptions, > *Fri Oct 20 17:19:30 EDT 2017* Thread[DRDAConnThread_107,5,main] (DATABASE = > null), (DRDAID = null), Execution failed because of a Distributed Protocol > Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 3. Plaintext > connection attempt from an SSL enabled client? > *Fri Oct 20 17:19:30 EDT 2017* : Execution failed because of a Distributed > Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 3. > Plaintext connection attempt from an SSL enabled client? > org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of > a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error > Code Value = 3. Plaintext connection attempt from an SSL enabled client? > at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(Unknown > Source) > at org.apache.derby.impl.drda.DDMReader.readDssHeader(Unknown Source) > at > org.apache.derby.impl.drda.DRDAConnThread.exchangeServerAttributes(Unknown > Source) > at > org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(Unknown Source) > at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) > We have no idea about the above Exceptions why it is coming while getting > connection in java client application. > Could you please help us to identify the exact reason for the above problem. > Thanks & Regards, > Sridhar Jena -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6973) Provide SHA-512 checksums on future releases
[ https://issues.apache.org/jira/browse/DERBY-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216166#comment-16216166 ] Rick Hillegas commented on DERBY-6973: -- I have left this issue as Urgent and added 10.15.0.0 to the list of affected issues. That should remind us to address this issue when we release 10.15.1. > Provide SHA-512 checksums on future releases > > > Key: DERBY-6973 > URL: https://issues.apache.org/jira/browse/DERBY-6973 > Project: Derby > Issue Type: Bug > Components: Web Site >Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, > 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0, > 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, > 10.8.2.2, 10.8.3.0, 10.9.1.0, 10.10.1.1, 10.10.2.0, 10.11.1.1, 10.12.1.1, > 10.13.1.1, 10.14.1.0, 10.15.0.0 >Reporter: Warren MacEvoy > > Releases have md5 sum for signatures, and nothing modern. How is this even > possible? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6973) Provide SHA-512 checksums on future releases
[ https://issues.apache.org/jira/browse/DERBY-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6973: - Affects Version/s: 10.15.0.0 > Provide SHA-512 checksums on future releases > > > Key: DERBY-6973 > URL: https://issues.apache.org/jira/browse/DERBY-6973 > Project: Derby > Issue Type: Bug > Components: Web Site >Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, > 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0, > 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, > 10.8.2.2, 10.8.3.0, 10.9.1.0, 10.10.1.1, 10.10.2.0, 10.11.1.1, 10.12.1.1, > 10.13.1.1, 10.14.1.0, 10.15.0.0 >Reporter: Warren MacEvoy > > Releases have md5 sum for signatures, and nothing modern. How is this even > possible? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6973) Provide SHA-512 checksums on future releases
[ https://issues.apache.org/jira/browse/DERBY-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216164#comment-16216164 ] Rick Hillegas commented on DERBY-6973: -- MD5 is a checksum type used by the following other popular Apache projects. However, Webserver also offers SHA256. Apache Webserver: https://httpd.apache.org/download.cgi Apache Spark: https://www.apache.org/dist/spark/spark-2.2.0/ Apache Kafka: https://kafka.apache.org/downloads Managers of future releases should consider using SHA-512 checksums in order to reduce the possibility of collisions. It is more a question of optics than real danger, I think. The probability of a collision is vanishingly small, particularly for scrupulous downloaders who also verify the PGP signature. The other projects cited above provide multiple checksum alternatives. Thanks for the nudge. > Provide SHA-512 checksums on future releases > > > Key: DERBY-6973 > URL: https://issues.apache.org/jira/browse/DERBY-6973 > Project: Derby > Issue Type: Bug > Components: Web Site >Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, > 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0, > 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, > 10.8.2.2, 10.8.3.0, 10.9.1.0, 10.10.1.1, 10.10.2.0, 10.11.1.1, 10.12.1.1, > 10.13.1.1, 10.14.1.0 >Reporter: Warren MacEvoy > > Releases have md5 sum for signatures, and nothing modern. How is this even > possible? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6973) Provide SHA-512 checksums on future releases
[ https://issues.apache.org/jira/browse/DERBY-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6973: - Summary: Provide SHA-512 checksums on future releases (was: md5 given in dowload artifacts) > Provide SHA-512 checksums on future releases > > > Key: DERBY-6973 > URL: https://issues.apache.org/jira/browse/DERBY-6973 > Project: Derby > Issue Type: Bug > Components: Web Site >Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, > 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0, > 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, > 10.8.2.2, 10.8.3.0, 10.9.1.0, 10.10.1.1, 10.10.2.0, 10.11.1.1, 10.12.1.1, > 10.13.1.1, 10.14.1.0 >Reporter: Warren MacEvoy > > Releases have md5 sum for signatures, and nothing modern. How is this even > possible? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6970) No support for setting connection timeout for a connection
[ https://issues.apache.org/jira/browse/DERBY-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6970: - Attachment: DERBY_6970.java The Derby DataSource implementations conform to the JDBC standard. The default login timeout is 0 (wait forever) as specified by the javadoc for javax.sql.CommonDataSource.setLoginTimeout(). Some other logic in your application stack is forcing the timeout to be 5 seconds. I am attaching a revised version of the test program, which demonstrates that Derby is behaving correctly. I instrumented the Derby engine to wait 20 seconds before returning a connection. Then I ran the test program. Here is the output from the program: Leaving login timeout untouched. Successfully got connection...after 20 seconds. Setting login timeout to 5 seconds. Login timeout exceededafter 5 seconds. Setting login timeout to 10 seconds. Login timeout exceededafter 10 seconds. Setting login timeout to 20 seconds. Login timeout exceededafter 20 seconds. Setting login timeout to 30 seconds. Successfully got connection...after 20 seconds. Setting login timeout to 0 seconds. Successfully got connection...after 20 seconds. I tried this experiment using Derby jar files built from the head of the development trunk. This code has not changed for several releases. > No support for setting connection timeout for a connection > -- > > Key: DERBY-6970 > URL: https://issues.apache.org/jira/browse/DERBY-6970 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.13.1.1 > Environment: Linux Operating system Resin App server >Reporter: Satyabrata Mohanty > Attachments: DERBY_6970.java, DERBY_6970.java > > > https://stackoverflow.com/questions/44722659/providing-connection-time-out-in-derby-client-driver > This is the link where i have put the details of my requirement. Basically my > question is, how we can provide a timeout to connection, if connection object > not established within that specific time it must get out from infinite > waiting and resulting any exception or null, but seems to be there is no such > functionality in derby till now. Request you to kindly look-into this and > provide your inputs like if there is a way to achieve this then mention it > with clear steps or else if its not implemented then when we can get this > must have required feature in derby. Its really affecting our performance > request you to kindly respond quickly. > Thanks! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (DERBY-6971) Grant permission based on Schema
[
https://issues.apache.org/jira/browse/DERBY-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208692#comment-16208692
]
Rick Hillegas edited comment on DERBY-6971 at 10/18/17 1:40 AM:
Thanks for those pointers. The following MySQL-inspired syntax makes sense to
me:
{noformat}
GRANT ON .* TO
and
REVOKE ON .* FROM RESTRICT
where
::=
| | |
| | |
::= EXECUTE
::=
::=
::=
::= USAGE
::= ALL PRIVILEGES
::= DELETE | INSERT | REFERENCES | SELECT | TRIGGER | UPDATE
::= TABLE | FUNCTION | PROCEDURE | SEQUENCE | TYPE | DERBY
AGGREGATE | ALL
{noformat}
A more detailed functional spec would be need to be written. But the following
examples suggest how this feature would behave:
{noformat}
1) Grant read access to all tables in a schema to all users:
GRANT SELECT ON TABLE mySchema.* TO PUBLIC
2) Grant all privileges on all objects in a schema to the userAdmin role:
GRANT ALL PRIVILEGES ON ALL mySchema.* TO userAdmin
{noformat}
Would this satisfy your needs?
was (Author: rhillegas):
Thanks for those pointers. The following MySQL-inspired syntax makes sense to
me:
GRANT ON .* TO
and
REVOKE ON .* FROM RESTRICT
where
::=
| | |
| | |
::= EXECUTE
::=
::=
::=
::= USAGE
::= ALL PRIVILEGES
::= DELETE | INSERT | REFERENCES | SELECT | TRIGGER | UPDATE
::= TABLE | FUNCTION | PROCEDURE | SEQUENCE | TYPE | DERBY
AGGREGATE | ALL
A more detailed functional spec would be need to be written. But the following
examples suggest how this feature would behave:
1) Grant read access to all tables in a schema to all users:
GRANT SELECT ON TABLE mySchema.* TO PUBLIC
2) Grant all privileges on all objects in a schema to the userAdmin role:
GRANT ALL PRIVILEGES ON ALL mySchema.* TO userAdmin
Would this satisfy your needs?
> Grant permission based on Schema
>
>
> Key: DERBY-6971
> URL: https://issues.apache.org/jira/browse/DERBY-6971
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Reporter: haojie ma
>
> Right now, Derby doesn't support grant permission based on schema, it only
> support on the table level. It is easier for the users if derby can have this
> feature.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6971) Grant permission based on Schema
[ https://issues.apache.org/jira/browse/DERBY-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16208692#comment-16208692 ] Rick Hillegas commented on DERBY-6971: -- Thanks for those pointers. The following MySQL-inspired syntax makes sense to me: GRANT ON .* TO and REVOKE ON .* FROM RESTRICT where ::= | | | | | | ::= EXECUTE ::= ::= ::= ::= USAGE ::= ALL PRIVILEGES ::= DELETE | INSERT | REFERENCES | SELECT | TRIGGER | UPDATE ::= TABLE | FUNCTION | PROCEDURE | SEQUENCE | TYPE | DERBY AGGREGATE | ALL A more detailed functional spec would be need to be written. But the following examples suggest how this feature would behave: 1) Grant read access to all tables in a schema to all users: GRANT SELECT ON TABLE mySchema.* TO PUBLIC 2) Grant all privileges on all objects in a schema to the userAdmin role: GRANT ALL PRIVILEGES ON ALL mySchema.* TO userAdmin Would this satisfy your needs? > Grant permission based on Schema > > > Key: DERBY-6971 > URL: https://issues.apache.org/jira/browse/DERBY-6971 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: haojie ma > > Right now, Derby doesn't support grant permission based on schema, it only > support on the table level. It is easier for the users if derby can have this > feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6970) No support for setting connection timeout for a connection
[ https://issues.apache.org/jira/browse/DERBY-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16206918#comment-16206918 ] Rick Hillegas commented on DERBY-6970: -- See the attached DERBY_6970 program for an example of how to set a login timeout on a Derby DataSource. If this example does not work for you, then please post the error message you are seeing along with the contents of derby.log. Thanks, -Rick > No support for setting connection timeout for a connection > -- > > Key: DERBY-6970 > URL: https://issues.apache.org/jira/browse/DERBY-6970 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.13.1.1 > Environment: Linux Operating system Resin App server >Reporter: Satyabrata Mohanty > Attachments: DERBY_6970.java > > > https://stackoverflow.com/questions/44722659/providing-connection-time-out-in-derby-client-driver > This is the link where i have put the details of my requirement. Basically my > question is, how we can provide a timeout to connection, if connection object > not established within that specific time it must get out from infinite > waiting and resulting any exception or null, but seems to be there is no such > functionality in derby till now. Request you to kindly look-into this and > provide your inputs like if there is a way to achieve this then mention it > with clear steps or else if its not implemented then when we can get this > must have required feature in derby. Its really affecting our performance > request you to kindly respond quickly. > Thanks! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6970) No support for setting connection timeout for a connection
[ https://issues.apache.org/jira/browse/DERBY-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6970: - Attachment: DERBY_6970.java Attaching DERBY_6970.java. This is a test program which demonstrates that ClientDataSource.setLoginTimeout() works correctly. The program sets a 5 second login timeout on the data source. I tested the program by compiling the Derby engine with a 10 second delay added to the creation of an EmbedConnection. Then I brought up a network server and ran the program. As expected, the program printed: Login timeout exceeded. This functionality is tested by LoginTimeoutTest every time that someone runs the full regression tests. > No support for setting connection timeout for a connection > -- > > Key: DERBY-6970 > URL: https://issues.apache.org/jira/browse/DERBY-6970 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.13.1.1 > Environment: Linux Operating system Resin App server >Reporter: Satyabrata Mohanty > Attachments: DERBY_6970.java > > > https://stackoverflow.com/questions/44722659/providing-connection-time-out-in-derby-client-driver > This is the link where i have put the details of my requirement. Basically my > question is, how we can provide a timeout to connection, if connection object > not established within that specific time it must get out from infinite > waiting and resulting any exception or null, but seems to be there is no such > functionality in derby till now. Request you to kindly look-into this and > provide your inputs like if there is a way to achieve this then mention it > with clear steps or else if its not implemented then when we can get this > must have required feature in derby. Its really affecting our performance > request you to kindly respond quickly. > Thanks! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6970) No support for setting connection timeout for a connection
[ https://issues.apache.org/jira/browse/DERBY-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6970: - Urgency: Low (was: Urgent) > No support for setting connection timeout for a connection > -- > > Key: DERBY-6970 > URL: https://issues.apache.org/jira/browse/DERBY-6970 > Project: Derby > Issue Type: Improvement > Components: JDBC >Affects Versions: 10.13.1.1 > Environment: Linux Operating system Resin App server >Reporter: Satyabrata Mohanty > > https://stackoverflow.com/questions/44722659/providing-connection-time-out-in-derby-client-driver > This is the link where i have put the details of my requirement. Basically my > question is, how we can provide a timeout to connection, if connection object > not established within that specific time it must get out from infinite > waiting and resulting any exception or null, but seems to be there is no such > functionality in derby till now. Request you to kindly look-into this and > provide your inputs like if there is a way to achieve this then mention it > with clear steps or else if its not implemented then when we can get this > must have required feature in derby. Its really affecting our performance > request you to kindly respond quickly. > Thanks! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6971) Grant permission based on Schema
[ https://issues.apache.org/jira/browse/DERBY-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16206879#comment-16206879 ] Rick Hillegas commented on DERBY-6971: -- Can you elaborate? This topic was raised on the developer's list recently, but the conversation shut down immediately after I pointed out that there is no language for this in the 2016 SQL Standard. Can you point us to a product which supplies this functionality? That would help us understand the scope of this proposal and the utility provided to users. Thanks, -Rick > Grant permission based on Schema > > > Key: DERBY-6971 > URL: https://issues.apache.org/jira/browse/DERBY-6971 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: haojie ma > > Right now, Derby doesn't support grant permission based on schema, it only > support on the table level. It is easier for the users if derby can have this > feature. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6945) Re-package Derby as a collection of jigsaw modules
[ https://issues.apache.org/jira/browse/DERBY-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202854#comment-16202854 ] Rick Hillegas commented on DERBY-6945: -- I see the following major steps to this effort. 1) Deprecate support for building Derby with pre-Java9 JDKs. 2) Agree on a package structure for Derby much as the Java team did for the core JDK. 3) Convert the build script to generate those package artifacts. 4) Convert the release machinery to generate corresponding release artifacts. > Re-package Derby as a collection of jigsaw modules > -- > > Key: DERBY-6945 > URL: https://issues.apache.org/jira/browse/DERBY-6945 > Project: Derby > Issue Type: Improvement >Affects Versions: 10.13.1.2 >Reporter: Rick Hillegas > > Once we commit to building with Java 9 (see DERBY-6856), we should consider > re-packaging Derby as a set of jigsaw modules. This would result in a > different set of release artifacts. This might be a good opportunity to > address the Tomcat artifactory issues raised by issue DERBY-6944. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DERBY-6969) Results from DatabaseMetaData.getBestRowIdentifier() need to be sorted
Rick Hillegas created DERBY-6969: Summary: Results from DatabaseMetaData.getBestRowIdentifier() need to be sorted Key: DERBY-6969 URL: https://issues.apache.org/jira/browse/DERBY-6969 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.14.1.0 Reporter: Rick Hillegas According to the javadoc, the results should be sorted by the SCOPE column. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
[ https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196344#comment-16196344 ] Rick Hillegas commented on DERBY-6968: -- Thanks for the quick review, Bryan. Tests passed cleanly for me on derby-6968-01-aa-assertUnorderedResultSet.diff. > Instability in DatabaseMetaDataTest.testGetBestRowIdentifier > > > Key: DERBY-6968 > URL: https://issues.apache.org/jira/browse/DERBY-6968 > Project: Derby > Issue Type: Bug > Components: JDBC, Test >Affects Versions: 10.14.1.0 >Reporter: Rick Hillegas > Attachments: 10.14.1.testResults.0-failures, > derby-6968-01-aa-assertUnorderedResultSet.diff > > > Ingo reports instabilities in his platform tests of the 10.14.1.0 release > candidate. He sees intermittent failures in > DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures > due to poor test case isolation in that test. The test case fails because > DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different > order than the test expects. > The JDBC contract for that method does not specify an order for the returned > rows. ORDER BY clauses appear on some but not all the catalog queries in > metadata.properties which define the Derby result. > I see two ways to address this issue: > 1) The test could be fixed so that it hand-sorts the returned rows in order > to guarantee deterministic results. > 2) ORDER BY clauses could be added to all the implicated metadata queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
[ https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6968: - Attachment: derby-6968-01-aa-assertUnorderedResultSet.diff Attaching derby-6968-01-aa-assertUnorderedResultSet.diff. This patch changes the result set verifiers in DatabaseMetaDataTest.getBestRowIdentifier() to call JDBC.assertUnorderedResultSet(). The test runs cleanly for me--but then it ran cleanly for me without the patch too. The upgrade tests also ran cleanly, using 10.14.1.0 as the starting point. I will run full regression tests. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/DatabaseMetaDataTest.java > Instability in DatabaseMetaDataTest.testGetBestRowIdentifier > > > Key: DERBY-6968 > URL: https://issues.apache.org/jira/browse/DERBY-6968 > Project: Derby > Issue Type: Bug > Components: JDBC, Test >Affects Versions: 10.14.1.0 >Reporter: Rick Hillegas > Attachments: 10.14.1.testResults.0-failures, > derby-6968-01-aa-assertUnorderedResultSet.diff > > > Ingo reports instabilities in his platform tests of the 10.14.1.0 release > candidate. He sees intermittent failures in > DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures > due to poor test case isolation in that test. The test case fails because > DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different > order than the test expects. > The JDBC contract for that method does not specify an order for the returned > rows. ORDER BY clauses appear on some but not all the catalog queries in > metadata.properties which define the Derby result. > I see two ways to address this issue: > 1) The test could be fixed so that it hand-sorts the returned rows in order > to guarantee deterministic results. > 2) ORDER BY clauses could be added to all the implicated metadata queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
[ https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196273#comment-16196273 ] Rick Hillegas commented on DERBY-6968: -- Hey Bryan, Thanks for pointing out the ordering on the SCOPE column. The queries are not ordered by returned column name, which is what the test needs. They are not ordered by SCOPE either. I can only guess at the purpose served by getBestRowIdentifier(). Maybe object-relational-mappers use the method in order to dream up object identifiers for updating/deleting rows in databases which don't have a system-supplied ROWID pseudo column. The following link was slightly useful: http://media.datadirect.com/download/docs/jdbc/alljdbc/index.html#page/jdbcconnect/using-getbestrowidentifier.html Adding an ordering by SCOPE to DatabaseMetaData.getBestRowIdentifier() is probably warranted since it would bring us into better compliance with the JDBC contract. I don't think that it will improve the behavior of this test, though. I do see that similar problems were addressed by DERBY-6623. For those problems, Dag had another solution, a variation on (1): 3) Use JDBC.assertUnorderedResultSet() Changing the order of the results returned by DatabaseMetaData.getBestRowIdentifier() would probably break the upgrade tests. That is because they end up running the current DatabaseMetaDataTest against old engines, and the old engines would still be returning results in the old order. We would still need to do (1) or (3) I think. > Instability in DatabaseMetaDataTest.testGetBestRowIdentifier > > > Key: DERBY-6968 > URL: https://issues.apache.org/jira/browse/DERBY-6968 > Project: Derby > Issue Type: Bug > Components: JDBC, Test >Affects Versions: 10.14.1.0 >Reporter: Rick Hillegas > Attachments: 10.14.1.testResults.0-failures > > > Ingo reports instabilities in his platform tests of the 10.14.1.0 release > candidate. He sees intermittent failures in > DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures > due to poor test case isolation in that test. The test case fails because > DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different > order than the test expects. > The JDBC contract for that method does not specify an order for the returned > rows. ORDER BY clauses appear on some but not all the catalog queries in > metadata.properties which define the Derby result. > I see two ways to address this issue: > 1) The test could be fixed so that it hand-sorts the returned rows in order > to guarantee deterministic results. > 2) ORDER BY clauses could be added to all the implicated metadata queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
[ https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6968: - Attachment: 10.14.1.testResults.0-failures Attaching 10.14.1.testResults.0-failures, a survey of the errors which Ingo saw. > Instability in DatabaseMetaDataTest.testGetBestRowIdentifier > > > Key: DERBY-6968 > URL: https://issues.apache.org/jira/browse/DERBY-6968 > Project: Derby > Issue Type: Bug > Components: JDBC, Test >Affects Versions: 10.14.1.0 >Reporter: Rick Hillegas > Attachments: 10.14.1.testResults.0-failures > > > Ingo reports instabilities in his platform tests of the 10.14.1.0 release > candidate. He sees intermittent failures in > DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures > due to poor test case isolation in that test. The test case fails because > DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different > order than the test expects. > The JDBC contract for that method does not specify an order for the returned > rows. ORDER BY clauses appear on some but not all the catalog queries in > metadata.properties which define the Derby result. > I see two ways to address this issue: > 1) The test could be fixed so that it hand-sorts the returned rows in order > to guarantee deterministic results. > 2) ORDER BY clauses could be added to all the implicated metadata queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
[ https://issues.apache.org/jira/browse/DERBY-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6968: - Affects Version/s: 10.14.1.0 > Instability in DatabaseMetaDataTest.testGetBestRowIdentifier > > > Key: DERBY-6968 > URL: https://issues.apache.org/jira/browse/DERBY-6968 > Project: Derby > Issue Type: Bug > Components: JDBC, Test >Affects Versions: 10.14.1.0 >Reporter: Rick Hillegas > > Ingo reports instabilities in his platform tests of the 10.14.1.0 release > candidate. He sees intermittent failures in > DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures > due to poor test case isolation in that test. The test case fails because > DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different > order than the test expects. > The JDBC contract for that method does not specify an order for the returned > rows. ORDER BY clauses appear on some but not all the catalog queries in > metadata.properties which define the Derby result. > I see two ways to address this issue: > 1) The test could be fixed so that it hand-sorts the returned rows in order > to guarantee deterministic results. > 2) ORDER BY clauses could be added to all the implicated metadata queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DERBY-6968) Instability in DatabaseMetaDataTest.testGetBestRowIdentifier
Rick Hillegas created DERBY-6968: Summary: Instability in DatabaseMetaDataTest.testGetBestRowIdentifier Key: DERBY-6968 URL: https://issues.apache.org/jira/browse/DERBY-6968 Project: Derby Issue Type: Bug Components: JDBC, Test Reporter: Rick Hillegas Ingo reports instabilities in his platform tests of the 10.14.1.0 release candidate. He sees intermittent failures in DatabaseMetaDataTest.testGetBestRowIdentifier and then subsequent failures due to poor test case isolation in that test. The test case fails because DatabaseMetaData.getBestRowIdentifier() sometimes returns rows in a different order than the test expects. The JDBC contract for that method does not specify an order for the returned rows. ORDER BY clauses appear on some but not all the catalog queries in metadata.properties which define the Derby result. I see two ways to address this issue: 1) The test could be fixed so that it hand-sorts the returned rows in order to guarantee deterministic results. 2) ORDER BY clauses could be added to all the implicated metadata queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6928) The ODBCMetadataGenerator_getCastInfoForCol method hardcodes some string values
[ https://issues.apache.org/jira/browse/DERBY-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192345#comment-16192345 ] Rick Hillegas commented on DERBY-6928: -- Thank you for your interest in contributing code to Derby. The Derby community maintains its code via subversion, not git. The process for contributing code to Derby is to prepare a subversion patch as described here: http://db.apache.org/derby/derby_comm.html. > The ODBCMetadataGenerator_getCastInfoForCol method hardcodes some string > values > --- > > Key: DERBY-6928 > URL: https://issues.apache.org/jira/browse/DERBY-6928 > Project: Derby > Issue Type: Improvement > Components: Build tools >Reporter: Hao Zhong >Assignee: Indumini Ayomi >Priority: Minor > > As some values are defined in org.apache.derby.iapi.types.TypeId, it is > easier to maintain the code, if we replace them accordingly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6966) API changes report for Derby
[ https://issues.apache.org/jira/browse/DERBY-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16190617#comment-16190617 ] Rick Hillegas commented on DERBY-6966: -- Thanks for this analysis. Without more context, it is hard to know how to interpret these results. Do you have any conclusions which you want to share? Thanks. > API changes report for Derby > > > Key: DERBY-6966 > URL: https://issues.apache.org/jira/browse/DERBY-6966 > Project: Derby > Issue Type: Improvement >Reporter: Andrey Ponomarenko > Attachments: derby-1.png, derby-2.png > > > The review of API changes for the Derby library since 10.1.1.0 version: > https://abi-laboratory.pro/java/tracker/timeline/derby/ > Hope it will be helpful for users and maintainers of the library. > The report is generated by the https://github.com/lvc/japi-tracker tool for > jars found at http://central.maven.org/maven2/org/apache/derby/derby/ > according to https://wiki.eclipse.org/Evolving_Java-based_APIs_2. > Thank you. > !derby-2.png|API symbols timeline! > !derby-1.png|API changes review! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DERBY-6964) Removing references to Java 6, 7 and 8 in the docs
Rick Hillegas created DERBY-6964: Summary: Removing references to Java 6, 7 and 8 in the docs Key: DERBY-6964 URL: https://issues.apache.org/jira/browse/DERBY-6964 Project: Derby Issue Type: Bug Components: Documentation Reporter: Rick Hillegas We should clean these up since from 10.5 onward we will only support Java 9+. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6910) Add Option for column names in first line of export file when using CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE
[ https://issues.apache.org/jira/browse/DERBY-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16185163#comment-16185163 ] Rick Hillegas commented on DERBY-6910: -- I am a bit worried about the proliferation of export procedures. They have gradually accreted over time, one by one, without much thought for future expansion. I am ok with a new procedure, but I think that it must cover the following cases: 1) Export from query. The query can be a select from a table but it can be more elaborate than that. 2) Allow for a separate file for LOB columns. Maybe one file per LOB column. 3) Support CSV with or without header. But also support other formats like JSON. We wouldn't have to implement all of them up front, but we should leave ourselves room for expansion. This issue deserves some thought and design. What do people think? > Add Option for column names in first line of export file when using CALL > SYSCS_UTIL.SYSCS_EXPORT_TABLE > -- > > Key: DERBY-6910 > URL: https://issues.apache.org/jira/browse/DERBY-6910 > Project: Derby > Issue Type: Improvement > Components: Tools >Affects Versions: 10.12.1.1 >Reporter: Christian Eugster >Assignee: Lashan Faliq >Priority: Trivial > Attachments: DERBY-6910Enhancement.diff > > > It would be fine if there was the Option for adding the columnnames in the > first line of an Export file in CALL SYSCS_UTIL.SYSCS_EXPORT_TABLE -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6902) Value out of range error (22003) on DELETE with expression in WHERE clause
[
https://issues.apache.org/jira/browse/DERBY-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183379#comment-16183379
]
Rick Hillegas commented on DERBY-6902:
--
Derby doesn't have enough information to promote the expression. CASTing is an
adequate workaround in my opinion.
> Value out of range error (22003) on DELETE with expression in WHERE clause
> --
>
> Key: DERBY-6902
> URL: https://issues.apache.org/jira/browse/DERBY-6902
> Project: Derby
> Issue Type: Bug
>Affects Versions: 10.12.1.1
>Reporter: Vedran Pavic
>Assignee: Kasuni Hemasika
> Attachments: anotherTestCast.diff, moreTestCases.diff,
> newTestCase.diff, repro.java
>
>
> Hi,
> I've ran into the problem from the subject, which appears to be a bug, using
> the latest 10.12.1.1 release.
> Given the table:
> {code:sql}
> create table test (
> id bigint primary key,
> big_number bigint not null,
> small_number int not null
> )
> {code}
> The following DELETE statement will fail with _The resulting value is outside
> the range for the data type INTEGER_ (22003):
> {code:sql}
> delete from test
> where big_number < ? - small_number * 1000
> {code}
> {code:java}
> java.sql.SQLDataException: The resulting value is outside the range for the
> data type INTEGER.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedResultSet.noStateChangeException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setLong(Unknown
> Source)
> at sample.PlainJdbcTest.delete(PlainJdbcTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at
[jira] [Updated] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6941: - Attachment: derby-6941-08-aa-updateCopyrightYearInDocs.diff Attaching derby-6941-08-aa-updateCopyrightYearInDocs.diff. This updates the copyright year in the docs from 2015 to 2017. The actual docs which were generated for the 10.14.1 release have 2017 as the copyright year, but if you generate the docs outside the release machinery, then you get a copyright year of 2015. This patch corrects that. Touches the following file: M docs.properties > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff, > derby-6941-02-aa-organizeDownloadsByJavaVersion.diff, > derby-6941-03-aa-updateSTATUSfile.diff, > derby-6941-04-aa-createBranchWithoutRevisionSpec.diff, > derby-6941-05-aa-bumpTrunkDDto10_15.diff, > derby-6941-06-aa-updateVersionListOnWebsite.diff, > derby-6941-07-aa-updateReleaseNotes.diff, > derby-6941-08-aa-updateCopyrightYearInDocs.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6941: - Attachment: derby-6941-07-aa-updateReleaseNotes.diff Attaching derby-6941-07-aa-updateReleaseNotes.diff. This patch updates the version number on the release notes and adds some more bug fixes to the list of issues addressed. Touches the following file: M RELEASE-NOTES.html > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff, > derby-6941-02-aa-organizeDownloadsByJavaVersion.diff, > derby-6941-03-aa-updateSTATUSfile.diff, > derby-6941-04-aa-createBranchWithoutRevisionSpec.diff, > derby-6941-05-aa-bumpTrunkDDto10_15.diff, > derby-6941-06-aa-updateVersionListOnWebsite.diff, > derby-6941-07-aa-updateReleaseNotes.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6941: - Attachment: derby-6941-06-aa-updateVersionListOnWebsite.diff Attaching derby-6941-06-aa-updateVersionListOnWebsite.diff. This patch adds 10.14 to the website's list of Derby branches. I also removed a stale section on how to build Derby. Touches the following files: X build/site M src/documentation/content/xdocs/dev/derby_source.xml Performing status on external item at 'build/site': M build/site/dev/derby_source.html > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff, > derby-6941-02-aa-organizeDownloadsByJavaVersion.diff, > derby-6941-03-aa-updateSTATUSfile.diff, > derby-6941-04-aa-createBranchWithoutRevisionSpec.diff, > derby-6941-05-aa-bumpTrunkDDto10_15.diff, > derby-6941-06-aa-updateVersionListOnWebsite.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6941: - Attachment: derby-6941-05-aa-bumpTrunkDDto10_15.diff Attaching derby-6941-05-aa-bumpTrunkDDto10_15.diff. Bump the release number on the trunk to 10.15. Touches the following files: M java/engine/org/apache/derby/iapi/sql/dictionary/DataDictionary.java M java/engine/org/apache/derby/impl/sql/catalog/DD_Version.java M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java M tools/ant/properties/release.properties > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff, > derby-6941-02-aa-organizeDownloadsByJavaVersion.diff, > derby-6941-03-aa-updateSTATUSfile.diff, > derby-6941-04-aa-createBranchWithoutRevisionSpec.diff, > derby-6941-05-aa-bumpTrunkDDto10_15.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6941: - Attachment: derby-6941-04-aa-createBranchWithoutRevisionSpec.diff Attaching derby-6941-04-aa-createBranchWithoutRevisionSpec.diff. This is an attempt to fix the branchRepository target. The current version of svn complains that a revision spec is not wanted. Removes the revision spec from the svn command. Touches the following file: M build.xml > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff, > derby-6941-02-aa-organizeDownloadsByJavaVersion.diff, > derby-6941-03-aa-updateSTATUSfile.diff, > derby-6941-04-aa-createBranchWithoutRevisionSpec.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6941: - Attachment: derby-6941-03-aa-updateSTATUSfile.diff Attaching derby-6941-03-aa-updateSTATUSfile.diff. This patch updates the STATUS file prior to generating the first release candidate. Touches the following file: M STATUS > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff, > derby-6941-02-aa-organizeDownloadsByJavaVersion.diff, > derby-6941-03-aa-updateSTATUSfile.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6957) ERROR 40XL1: A lock could not be obtained within the time requested for alter or truncate table
[ https://issues.apache.org/jira/browse/DERBY-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169503#comment-16169503 ] Rick Hillegas commented on DERBY-6957: -- Reducing the urgency to normal. The urgency field is owned by the release manager. It is used to flag issues which block a release from being produced. > ERROR 40XL1: A lock could not be obtained within the time requested for alter > or truncate table > --- > > Key: DERBY-6957 > URL: https://issues.apache.org/jira/browse/DERBY-6957 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.13.1.1 > Environment: production >Reporter: SUNEEL KUMAR OLETI > > hi, > for all my Drop table, alter table, truncate table i am getting below error. > ERROR 40XL1: A lock could not be obtained within the time requested > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown > Source) > at org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown > Source) > at > org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(Unknown Source) > at > org.apache.derby.impl.store.raw.xact.ContainerLocking3.lockContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown > Source) > at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown > Source) > at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(Unknown > Source) > at org.apache.derby.impl.store.access.heap.Heap.open(Unknown Source) > at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown > Source) > at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown > Source) > at > org.apache.derby.impl.sql.execute.DDLConstantAction.lockTableForDDL(Unknown > Source) > at > org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantActionBody(Unknown > Source) > at > org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(Unknown > Source) > at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source) > at > org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown > Source) > at com.db.UpdateTables.alterDataTable(UpdateTables.java:1833) > at > com.he.webApiLayer.ResponseBuilder.insertDataInDB(ResponseBuilder.java:2910) > at com.he.webApiLayer.InputAPI.lambda$1(InputAPI.java:127) > at spark.RouteImpl$1.handle(RouteImpl.java:61) > at spark.http.matching.Routes.execute(Routes.java:61) > at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:128) > at > spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119) > at org.eclipse.jetty.server.Server.handle(Server.java:517) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:261) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) > at > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:75) > at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213) > at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:147) >
[jira] [Updated] (DERBY-6957) ERROR 40XL1: A lock could not be obtained within the time requested for alter or truncate table
[ https://issues.apache.org/jira/browse/DERBY-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6957: - Urgency: Normal (was: Blocker) > ERROR 40XL1: A lock could not be obtained within the time requested for alter > or truncate table > --- > > Key: DERBY-6957 > URL: https://issues.apache.org/jira/browse/DERBY-6957 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.13.1.1 > Environment: production >Reporter: SUNEEL KUMAR OLETI > > hi, > for all my Drop table, alter table, truncate table i am getting below error. > ERROR 40XL1: A lock could not be obtained within the time requested > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at org.apache.derby.iapi.error.StandardException.newException(Unknown > Source) > at > org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown > Source) > at org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown > Source) > at > org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(Unknown Source) > at > org.apache.derby.impl.store.raw.xact.ContainerLocking3.lockContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseContainerHandle.useContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown > Source) > at > org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown > Source) > at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown > Source) > at > org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(Unknown > Source) > at org.apache.derby.impl.store.access.heap.Heap.open(Unknown Source) > at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown > Source) > at > org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(Unknown > Source) > at > org.apache.derby.impl.sql.execute.DDLConstantAction.lockTableForDDL(Unknown > Source) > at > org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantActionBody(Unknown > Source) > at > org.apache.derby.impl.sql.execute.AlterTableConstantAction.executeConstantAction(Unknown > Source) > at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source) > at > org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(Unknown > Source) > at > org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown > Source) > at com.db.UpdateTables.alterDataTable(UpdateTables.java:1833) > at > com.he.webApiLayer.ResponseBuilder.insertDataInDB(ResponseBuilder.java:2910) > at com.he.webApiLayer.InputAPI.lambda$1(InputAPI.java:127) > at spark.RouteImpl$1.handle(RouteImpl.java:61) > at spark.http.matching.Routes.execute(Routes.java:61) > at spark.http.matching.MatcherFilter.doFilter(MatcherFilter.java:128) > at > spark.embeddedserver.jetty.JettyHandler.doHandle(JettyHandler.java:50) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:189) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119) > at org.eclipse.jetty.server.Server.handle(Server.java:517) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:261) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) > at > org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:75) > at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213) > at > org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:147) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654) > at >
[jira] [Resolved] (DERBY-6961) SET CYCLE fails to let an identity column cycle if the range is already exhausted
[
https://issues.apache.org/jira/browse/DERBY-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas resolved DERBY-6961.
--
Resolution: Fixed
Fix Version/s: 10.14.0.0
> SET CYCLE fails to let an identity column cycle if the range is already
> exhausted
> -
>
> Key: DERBY-6961
> URL: https://issues.apache.org/jira/browse/DERBY-6961
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Fix For: 10.14.0.0
>
> Attachments: derby-6961-01-aa-recyclingExhaustedIdentityColumns.diff
>
>
> If a NO CYCLE identity column exhausts its range, then...
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> ...will not revive the identity column. No more rows can be inserted into the
> table. This violates the SQL Standard and is very surprising behavior after
> the ALTER TABLE command completed successfully.
> The problem is that the exhausted sequence generator has a next value of
> NULL, signifying that it is done. After the ALTER TABLE command, the next
> value of the sequence generator should be the minimum value (for an ascending
> sequence generator) or the maximum value (for a descending sequence
> generator) according to the 2016 SQL Standard, section 4.27.2 (Operations
> involving sequence generators), quoted here in full:
> "When a is applied to a sequence generator SG, SG
> issues a value V taken from SG's current cycle such that V is expressible as
> the current base value of SG plus N multiplied by the increment of SG, where
> N is a non-negative number.
> Thus a sequence generator will normally issue all of the values in its cycle
> and these will normally be in increasing or decreasing order (depending on
> the sign of the increment) but within that general ordering separate
> subgroups of ordered values may occur.
> If the sequence generator's cycle is exhausted (i.e., it cannot issue a value
> that meets the criteria), then a new cycle is created with the current base
> value set to the minimum value of SG (if SG is an ascending sequence
> generator) or the maximum value of SG (if SG is a descending sequence
> generator).
> If a new cycle is created and the descriptor of SG includes NOCYCLE, then an
> exception condition is raised.
> If there are multiple instances of s specifying the
> same sequence generator within a single SQL-statement, all those instances
> return the same value for a given row processed by that SQL-statement."
> The following script shows this problem:
> {noformat}
> connect 'jdbc:derby:memory:db;create=true';
>
> --
> -- Exhaust a NO CYCLE identity column.
> -- SET CYCLE does not allow the sequence generator
> -- to continue processing.
> --
>
> create table t_noCycleExhaust(a int generated always as identity (start with
> 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (2);
> -- the sequence generator has NULL as its next value
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- should fail
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
> alter table t_noCycleExhaust alter column a set cycle;
> -- the sequence generator still has NULL as its next value. this is the bug.
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- incorrectly fails
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
>
> --
> -- Do NOT exhaust a NO CYCLE identity column.
> -- Then SET CYCLE. The sequence generator will
> -- wrap around.
> --
>
> create table t_noCycleDoNotExhaust(a int generated always as identity (start
> with 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> alter table t_noCycleDoNotExhaust alter column a set cycle;
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (2);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (3);
>
[jira] [Commented] (DERBY-6961) SET CYCLE fails to let an identity column cycle if the range is already exhausted
[
https://issues.apache.org/jira/browse/DERBY-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169497#comment-16169497
]
Rick Hillegas commented on DERBY-6961:
--
Tests passed cleanly on derby-6961-01-aa-recyclingExhaustedIdentityColumns.diff.
> SET CYCLE fails to let an identity column cycle if the range is already
> exhausted
> -
>
> Key: DERBY-6961
> URL: https://issues.apache.org/jira/browse/DERBY-6961
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-6961-01-aa-recyclingExhaustedIdentityColumns.diff
>
>
> If a NO CYCLE identity column exhausts its range, then...
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> ...will not revive the identity column. No more rows can be inserted into the
> table. This violates the SQL Standard and is very surprising behavior after
> the ALTER TABLE command completed successfully.
> The problem is that the exhausted sequence generator has a next value of
> NULL, signifying that it is done. After the ALTER TABLE command, the next
> value of the sequence generator should be the minimum value (for an ascending
> sequence generator) or the maximum value (for a descending sequence
> generator) according to the 2016 SQL Standard, section 4.27.2 (Operations
> involving sequence generators), quoted here in full:
> "When a is applied to a sequence generator SG, SG
> issues a value V taken from SG's current cycle such that V is expressible as
> the current base value of SG plus N multiplied by the increment of SG, where
> N is a non-negative number.
> Thus a sequence generator will normally issue all of the values in its cycle
> and these will normally be in increasing or decreasing order (depending on
> the sign of the increment) but within that general ordering separate
> subgroups of ordered values may occur.
> If the sequence generator's cycle is exhausted (i.e., it cannot issue a value
> that meets the criteria), then a new cycle is created with the current base
> value set to the minimum value of SG (if SG is an ascending sequence
> generator) or the maximum value of SG (if SG is a descending sequence
> generator).
> If a new cycle is created and the descriptor of SG includes NOCYCLE, then an
> exception condition is raised.
> If there are multiple instances of s specifying the
> same sequence generator within a single SQL-statement, all those instances
> return the same value for a given row processed by that SQL-statement."
> The following script shows this problem:
> {noformat}
> connect 'jdbc:derby:memory:db;create=true';
>
> --
> -- Exhaust a NO CYCLE identity column.
> -- SET CYCLE does not allow the sequence generator
> -- to continue processing.
> --
>
> create table t_noCycleExhaust(a int generated always as identity (start with
> 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (2);
> -- the sequence generator has NULL as its next value
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- should fail
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
> alter table t_noCycleExhaust alter column a set cycle;
> -- the sequence generator still has NULL as its next value. this is the bug.
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- incorrectly fails
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
>
> --
> -- Do NOT exhaust a NO CYCLE identity column.
> -- Then SET CYCLE. The sequence generator will
> -- wrap around.
> --
>
> create table t_noCycleDoNotExhaust(a int generated always as identity (start
> with 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> alter table t_noCycleDoNotExhaust alter column a set cycle;
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (2);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into
[jira] [Updated] (DERBY-6961) SET CYCLE fails to let an identity column cycle if the range is already exhausted
[
https://issues.apache.org/jira/browse/DERBY-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6961:
-
Attachment: derby-6961-01-aa-recyclingExhaustedIdentityColumns.diff
Attaching derby-6961-01-aa-recyclingExhaustedIdentityColumns.diff. This patch
addresses both of the problems scripted above. I am running full tests now.
Touches the following files:
---
M
java/engine/org/apache/derby/impl/sql/execute/AlterTableConstantAction.java
Correctly handle ALTER TABLE...SET [NO] CYCLE for exhausted identity columns
which are at their rollover point.
---
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/AlterTableTest.java
Tests.
> SET CYCLE fails to let an identity column cycle if the range is already
> exhausted
> -
>
> Key: DERBY-6961
> URL: https://issues.apache.org/jira/browse/DERBY-6961
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-6961-01-aa-recyclingExhaustedIdentityColumns.diff
>
>
> If a NO CYCLE identity column exhausts its range, then...
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> ...will not revive the identity column. No more rows can be inserted into the
> table. This violates the SQL Standard and is very surprising behavior after
> the ALTER TABLE command completed successfully.
> The problem is that the exhausted sequence generator has a next value of
> NULL, signifying that it is done. After the ALTER TABLE command, the next
> value of the sequence generator should be the minimum value (for an ascending
> sequence generator) or the maximum value (for a descending sequence
> generator) according to the 2016 SQL Standard, section 4.27.2 (Operations
> involving sequence generators), quoted here in full:
> "When a is applied to a sequence generator SG, SG
> issues a value V taken from SG's current cycle such that V is expressible as
> the current base value of SG plus N multiplied by the increment of SG, where
> N is a non-negative number.
> Thus a sequence generator will normally issue all of the values in its cycle
> and these will normally be in increasing or decreasing order (depending on
> the sign of the increment) but within that general ordering separate
> subgroups of ordered values may occur.
> If the sequence generator's cycle is exhausted (i.e., it cannot issue a value
> that meets the criteria), then a new cycle is created with the current base
> value set to the minimum value of SG (if SG is an ascending sequence
> generator) or the maximum value of SG (if SG is a descending sequence
> generator).
> If a new cycle is created and the descriptor of SG includes NOCYCLE, then an
> exception condition is raised.
> If there are multiple instances of s specifying the
> same sequence generator within a single SQL-statement, all those instances
> return the same value for a given row processed by that SQL-statement."
> The following script shows this problem:
> {noformat}
> connect 'jdbc:derby:memory:db;create=true';
>
> --
> -- Exhaust a NO CYCLE identity column.
> -- SET CYCLE does not allow the sequence generator
> -- to continue processing.
> --
>
> create table t_noCycleExhaust(a int generated always as identity (start with
> 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (2);
> -- the sequence generator has NULL as its next value
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- should fail
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
> alter table t_noCycleExhaust alter column a set cycle;
> -- the sequence generator still has NULL as its next value. this is the bug.
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- incorrectly fails
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
>
> --
> -- Do NOT exhaust a NO CYCLE identity column.
> -- Then SET CYCLE. The sequence generator will
> -- wrap around.
> --
>
> create table t_noCycleDoNotExhaust(a int generated always as identity (start
> with 2147483646 no cycle), b
[jira] [Assigned] (DERBY-6961) SET CYCLE fails to let an identity column cycle if the range is already exhausted
[
https://issues.apache.org/jira/browse/DERBY-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas reassigned DERBY-6961:
Assignee: Rick Hillegas
> SET CYCLE fails to let an identity column cycle if the range is already
> exhausted
> -
>
> Key: DERBY-6961
> URL: https://issues.apache.org/jira/browse/DERBY-6961
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
>
> If a NO CYCLE identity column exhausts its range, then...
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> ...will not revive the identity column. No more rows can be inserted into the
> table. This violates the SQL Standard and is very surprising behavior after
> the ALTER TABLE command completed successfully.
> The problem is that the exhausted sequence generator has a next value of
> NULL, signifying that it is done. After the ALTER TABLE command, the next
> value of the sequence generator should be the minimum value (for an ascending
> sequence generator) or the maximum value (for a descending sequence
> generator) according to the 2016 SQL Standard, section 4.27.2 (Operations
> involving sequence generators), quoted here in full:
> "When a is applied to a sequence generator SG, SG
> issues a value V taken from SG's current cycle such that V is expressible as
> the current base value of SG plus N multiplied by the increment of SG, where
> N is a non-negative number.
> Thus a sequence generator will normally issue all of the values in its cycle
> and these will normally be in increasing or decreasing order (depending on
> the sign of the increment) but within that general ordering separate
> subgroups of ordered values may occur.
> If the sequence generator's cycle is exhausted (i.e., it cannot issue a value
> that meets the criteria), then a new cycle is created with the current base
> value set to the minimum value of SG (if SG is an ascending sequence
> generator) or the maximum value of SG (if SG is a descending sequence
> generator).
> If a new cycle is created and the descriptor of SG includes NOCYCLE, then an
> exception condition is raised.
> If there are multiple instances of s specifying the
> same sequence generator within a single SQL-statement, all those instances
> return the same value for a given row processed by that SQL-statement."
> The following script shows this problem:
> {noformat}
> connect 'jdbc:derby:memory:db;create=true';
>
> --
> -- Exhaust a NO CYCLE identity column.
> -- SET CYCLE does not allow the sequence generator
> -- to continue processing.
> --
>
> create table t_noCycleExhaust(a int generated always as identity (start with
> 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (2);
> -- the sequence generator has NULL as its next value
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- should fail
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
> alter table t_noCycleExhaust alter column a set cycle;
> -- the sequence generator still has NULL as its next value. this is the bug.
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- incorrectly fails
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
>
> --
> -- Do NOT exhaust a NO CYCLE identity column.
> -- Then SET CYCLE. The sequence generator will
> -- wrap around.
> --
>
> create table t_noCycleDoNotExhaust(a int generated always as identity (start
> with 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> alter table t_noCycleDoNotExhaust alter column a set cycle;
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (2);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> select * from t_noCycleDoNotExhaust order by b;
> {noformat}
[jira] [Closed] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11 databases
[
https://issues.apache.org/jira/browse/DERBY-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas closed DERBY-6962.
> Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11 databases
> ---
>
> Key: DERBY-6962
> URL: https://issues.apache.org/jira/browse/DERBY-6962
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Fix For: 10.14.0.0
>
> Attachments: derby-6962-01-aa-forbidSetCycleOn10_10.diff,
> derby-6962-01-ab-forbidSetCycleOn10_10.diff
>
>
> The
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> command does not raise an error even on identity columns in pre-10.12
> databases. Those identity columns are not backed by sequence generators.
> Afterwards, the columns do not cycle, even though the ALTER TABLE command
> appeared to run successfully. This should be easy to fix. The parser just
> needs to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases.
> The following scripts show this behavior:
> {noformat}
> -- run the following script with version 10.10.1.1:
> connect 'jdbc:derby:db;create=true';
> create table t1(a int generated always as identity (start with 2147483646), b
> int);
> insert into t1(b) values (1);
> insert into t1(b) values (2);
> -- fails as expected
> insert into t1(b) values (3);
> select * from t1 order by b;
> create table t2(a int generated always as identity (start with 2147483646), b
> int);
> -- now run the following script with 10.14
> connect 'jdbc:derby:db';
> -- succeeds but should not
> alter table t2 alter column a set cycle;
> insert into t2(b) values (1);
> insert into t2(b) values (2);
> -- fails because the cycling behavior did not change
> insert into t2(b) values (3);
> select * from t2 order by b;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11 databases
[
https://issues.apache.org/jira/browse/DERBY-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas resolved DERBY-6962.
--
Resolution: Fixed
> Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11 databases
> ---
>
> Key: DERBY-6962
> URL: https://issues.apache.org/jira/browse/DERBY-6962
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Fix For: 10.14.0.0
>
> Attachments: derby-6962-01-aa-forbidSetCycleOn10_10.diff,
> derby-6962-01-ab-forbidSetCycleOn10_10.diff
>
>
> The
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> command does not raise an error even on identity columns in pre-10.12
> databases. Those identity columns are not backed by sequence generators.
> Afterwards, the columns do not cycle, even though the ALTER TABLE command
> appeared to run successfully. This should be easy to fix. The parser just
> needs to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases.
> The following scripts show this behavior:
> {noformat}
> -- run the following script with version 10.10.1.1:
> connect 'jdbc:derby:db;create=true';
> create table t1(a int generated always as identity (start with 2147483646), b
> int);
> insert into t1(b) values (1);
> insert into t1(b) values (2);
> -- fails as expected
> insert into t1(b) values (3);
> select * from t1 order by b;
> create table t2(a int generated always as identity (start with 2147483646), b
> int);
> -- now run the following script with 10.14
> connect 'jdbc:derby:db';
> -- succeeds but should not
> alter table t2 alter column a set cycle;
> insert into t2(b) values (1);
> insert into t2(b) values (2);
> -- fails because the cycling behavior did not change
> insert into t2(b) values (3);
> select * from t2 order by b;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11 databases
[
https://issues.apache.org/jira/browse/DERBY-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169168#comment-16169168
]
Rick Hillegas commented on DERBY-6962:
--
Tests passed cleanly on derby-6962-01-ab-forbidSetCycleOn10_10.diff.
> Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11 databases
> ---
>
> Key: DERBY-6962
> URL: https://issues.apache.org/jira/browse/DERBY-6962
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Fix For: 10.14.0.0
>
> Attachments: derby-6962-01-aa-forbidSetCycleOn10_10.diff,
> derby-6962-01-ab-forbidSetCycleOn10_10.diff
>
>
> The
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> command does not raise an error even on identity columns in pre-10.12
> databases. Those identity columns are not backed by sequence generators.
> Afterwards, the columns do not cycle, even though the ALTER TABLE command
> appeared to run successfully. This should be easy to fix. The parser just
> needs to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases.
> The following scripts show this behavior:
> {noformat}
> -- run the following script with version 10.10.1.1:
> connect 'jdbc:derby:db;create=true';
> create table t1(a int generated always as identity (start with 2147483646), b
> int);
> insert into t1(b) values (1);
> insert into t1(b) values (2);
> -- fails as expected
> insert into t1(b) values (3);
> select * from t1 order by b;
> create table t2(a int generated always as identity (start with 2147483646), b
> int);
> -- now run the following script with 10.14
> connect 'jdbc:derby:db';
> -- succeeds but should not
> alter table t2 alter column a set cycle;
> insert into t2(b) values (1);
> insert into t2(b) values (2);
> -- fails because the cycling behavior did not change
> insert into t2(b) values (3);
> select * from t2 order by b;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11 databases
[
https://issues.apache.org/jira/browse/DERBY-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6962:
-
Summary: Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11
databases (was: Forbid ALTER TABLE ... SET CYCLE on identity columns in
pre-10.12 databases)
Thanks for catching that, Bryan. I am updating the title on this issue as you
recommended.
> Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.11 databases
> ---
>
> Key: DERBY-6962
> URL: https://issues.apache.org/jira/browse/DERBY-6962
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Fix For: 10.14.0.0
>
> Attachments: derby-6962-01-aa-forbidSetCycleOn10_10.diff,
> derby-6962-01-ab-forbidSetCycleOn10_10.diff
>
>
> The
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> command does not raise an error even on identity columns in pre-10.12
> databases. Those identity columns are not backed by sequence generators.
> Afterwards, the columns do not cycle, even though the ALTER TABLE command
> appeared to run successfully. This should be easy to fix. The parser just
> needs to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases.
> The following scripts show this behavior:
> {noformat}
> -- run the following script with version 10.10.1.1:
> connect 'jdbc:derby:db;create=true';
> create table t1(a int generated always as identity (start with 2147483646), b
> int);
> insert into t1(b) values (1);
> insert into t1(b) values (2);
> -- fails as expected
> insert into t1(b) values (3);
> select * from t1 order by b;
> create table t2(a int generated always as identity (start with 2147483646), b
> int);
> -- now run the following script with 10.14
> connect 'jdbc:derby:db';
> -- succeeds but should not
> alter table t2 alter column a set cycle;
> insert into t2(b) values (1);
> insert into t2(b) values (2);
> -- fails because the cycling behavior did not change
> insert into t2(b) values (3);
> select * from t2 order by b;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
[
https://issues.apache.org/jira/browse/DERBY-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6962:
-
Attachment: derby-6962-01-ab-forbidSetCycleOn10_10.diff
Attaching derby-6962-01-ab-forbidSetCycleOn10_10.diff. Tests passed cleanly on
the previous patch, but I realized that the new test belonged in a new,
10.14-specific test class. The new patch has been tested against the same
battery of old releases. I am running full tests again.
Touches the following files:
-
M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
Parser changes, as before.
-
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/insane.derbyTesting.jar.lastcontents
M
java/build/org/apache/derbyBuild/lastgoodjarcontents/sane.derbyTesting.jar.lastcontents
A
java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_14.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/UpgradeRun.java
New class to hold the new tests.
> Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
> ---
>
> Key: DERBY-6962
> URL: https://issues.apache.org/jira/browse/DERBY-6962
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Fix For: 10.14.0.0
>
> Attachments: derby-6962-01-aa-forbidSetCycleOn10_10.diff,
> derby-6962-01-ab-forbidSetCycleOn10_10.diff
>
>
> The
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> command does not raise an error even on identity columns in pre-10.12
> databases. Those identity columns are not backed by sequence generators.
> Afterwards, the columns do not cycle, even though the ALTER TABLE command
> appeared to run successfully. This should be easy to fix. The parser just
> needs to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases.
> The following scripts show this behavior:
> {noformat}
> -- run the following script with version 10.10.1.1:
> connect 'jdbc:derby:db;create=true';
> create table t1(a int generated always as identity (start with 2147483646), b
> int);
> insert into t1(b) values (1);
> insert into t1(b) values (2);
> -- fails as expected
> insert into t1(b) values (3);
> select * from t1 order by b;
> create table t2(a int generated always as identity (start with 2147483646), b
> int);
> -- now run the following script with 10.14
> connect 'jdbc:derby:db';
> -- succeeds but should not
> alter table t2 alter column a set cycle;
> insert into t2(b) values (1);
> insert into t2(b) values (2);
> -- fails because the cycling behavior did not change
> insert into t2(b) values (3);
> select * from t2 order by b;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
[
https://issues.apache.org/jira/browse/DERBY-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6962:
-
Attachment: derby-6962-01-aa-forbidSetCycleOn10_10.diff
Attaching derby-6962-01-aa-forbidSetCycleOn10_10.diff. This patch prevents
changes to the cycling behavior of identity columns in soft-upgraded databases
at level 10.10 and earlier. The upgrade tests ran cleanly against the following
releases:
10.1.1.0
10.1.2.1
10.1.3.1
10.2.1.6
10.2.2.0
10.2.2.1
10.3.3.0
10.4.1.3
10.4.2.0
10.4.2.1
10.5.1.1
10.5.3.0
10.6.1.0
10.6.2.1
10.7.1.1
10.8.1.2
10.8.2.2
10.9.1.0
10.10.1.1
10.10.1.2
10.10.1.3
10.10.2.0
10.11.1.1
10.12.1.1
10.13.1.1
I will run full regression tests now.
Touches the following files:
--
M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj
Raise an error at parse time if someone tries to change the cycling behavior of
an identity column in a database at level 10.10 or earlier.
--
M
java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_13.java
Upgrade test for this change.
> Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
> ---
>
> Key: DERBY-6962
> URL: https://issues.apache.org/jira/browse/DERBY-6962
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Fix For: 10.14.0.0
>
> Attachments: derby-6962-01-aa-forbidSetCycleOn10_10.diff
>
>
> The
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> command does not raise an error even on identity columns in pre-10.12
> databases. Those identity columns are not backed by sequence generators.
> Afterwards, the columns do not cycle, even though the ALTER TABLE command
> appeared to run successfully. This should be easy to fix. The parser just
> needs to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases.
> The following scripts show this behavior:
> {noformat}
> -- run the following script with version 10.10.1.1:
> connect 'jdbc:derby:db;create=true';
> create table t1(a int generated always as identity (start with 2147483646), b
> int);
> insert into t1(b) values (1);
> insert into t1(b) values (2);
> -- fails as expected
> insert into t1(b) values (3);
> select * from t1 order by b;
> create table t2(a int generated always as identity (start with 2147483646), b
> int);
> -- now run the following script with 10.14
> connect 'jdbc:derby:db';
> -- succeeds but should not
> alter table t2 alter column a set cycle;
> insert into t2(b) values (1);
> insert into t2(b) values (2);
> -- fails because the cycling behavior did not change
> insert into t2(b) values (3);
> select * from t2 order by b;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-6857) Deprecate support for building Derby under JDKs 6 and 7
[ https://issues.apache.org/jira/browse/DERBY-6857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6857: - Fix Version/s: 10.14.0.0 > Deprecate support for building Derby under JDKs 6 and 7 > --- > > Key: DERBY-6857 > URL: https://issues.apache.org/jira/browse/DERBY-6857 > Project: Derby > Issue Type: Bug > Components: Build tools >Affects Versions: 10.13.1.0 >Reporter: Rick Hillegas > Fix For: 10.14.0.0, 10.13.1.2 > > Attachments: classReferenceComparison.txt, ClassReferenceReader.java, > derby-6857-01-aa-remove6and7.diff, derby-6857-02-aa-cleanupOldJdks.diff, > derby-6857-03-aa-minimumVersion.diff, > derby-6857-04-aa-pruneConstantClasses.diff, jardriftcheck.diff, > jvminfo-constants.diff, mac-derby-jar-verbose.txt, mac-sane-TypeId.class, > new-byte-codes.diff, windows-derby-jar-verbose.txt, Windows-sane-TypeId.class > > > The community voted to stop supporting Java 6 and 7 as of release 10.13. See > the 2015-09-12 entry here: http://wiki.apache.org/db-derby/VoteResults. We no > longer need to support building Derby with those JDKs. This issue tracks > changes needed to remove that support and simplify the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6726) NPE from trigger
[
https://issues.apache.org/jira/browse/DERBY-6726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6726:
-
Fix Version/s: (was: 10.14.0.0)
> NPE from trigger
>
>
> Key: DERBY-6726
> URL: https://issues.apache.org/jira/browse/DERBY-6726
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.10.1.1
>Reporter: Tim Dudgeon
>Assignee: Bryan Pendleton
> Fix For: 10.12.1.2, 10.13.1.0
>
> Attachments: derbytrig.zip, fixesRepro.diff, getTableDescriptor.diff,
> TriggerTest.diff
>
>
> Saw this strange exception when doing an insert to a table with a trigger
> {code}
> Tue Sep 02 13:39:09 BST 2014 Thread[SQLExecution,1,system] (XID = 62693),
> (SESSIONID = 1), (DATABASE =
> C:/Users/timbo/Documents/IJCProjects/mini-regs/Vanilla
> Oracle/.config/derby-minireg-01-sep/db), (DRDAID = null), Failed Statement
> is: UPDATE samples SET sample_code = 'S123456' WHERE sample_id = CAST
> (org.apache.derby.iapi.db.Factory::getTriggerExecutionContext().getNewRow().getObject(1)
> AS INTEGER)
> java.lang.NullPointerException
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getTriggerActionString(Unknown
> Source)
> at
> org.apache.derby.iapi.sql.dictionary.TriggerDescriptor.getActionSPS(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.GenericTriggerExecutor.getAction(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.UpdateResultSet.fireAfterTriggers(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeSubStatement(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> {code}
> The trigger definition is this:
> {code}
> CREATE TRIGGER samples_code_trg
> AFTER INSERT ON samples
> REFERENCING NEW AS newrow FOR EACH ROW MODE DB2SQL
> UPDATE samples SET sample_code = 'S123456'
> WHERE samples.sample_id = newrow.sample_id;
> {code}
> As mentioned here:
> http://mail-archives.apache.org/mod_mbox/db-derby-user/201408.mbox/%3Cltq5hl$kps$1...@ger.gmane.org%3E
> it could be that its caused by another AFTER UPDATE trigger that's on the
> table.
> Unfortunately I rebuilt all the tables and triggers and not the problem
> doesn't happen, so I can't provide a test case.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
[
https://issues.apache.org/jira/browse/DERBY-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas reassigned DERBY-6962:
Assignee: Rick Hillegas
> Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
> ---
>
> Key: DERBY-6962
> URL: https://issues.apache.org/jira/browse/DERBY-6962
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Fix For: 10.14.0.0
>
>
> The
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> command does not raise an error even on identity columns in pre-10.12
> databases. Those identity columns are not backed by sequence generators.
> Afterwards, the columns do not cycle, even though the ALTER TABLE command
> appeared to run successfully. This should be easy to fix. The parser just
> needs to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases.
> The following scripts show this behavior:
> {noformat}
> -- run the following script with version 10.10.1.1:
> connect 'jdbc:derby:db;create=true';
> create table t1(a int generated always as identity (start with 2147483646), b
> int);
> insert into t1(b) values (1);
> insert into t1(b) values (2);
> -- fails as expected
> insert into t1(b) values (3);
> select * from t1 order by b;
> create table t2(a int generated always as identity (start with 2147483646), b
> int);
> -- now run the following script with 10.14
> connect 'jdbc:derby:db';
> -- succeeds but should not
> alter table t2 alter column a set cycle;
> insert into t2(b) values (1);
> insert into t2(b) values (2);
> -- fails because the cycling behavior did not change
> insert into t2(b) values (3);
> select * from t2 order by b;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
[
https://issues.apache.org/jira/browse/DERBY-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6962:
-
Description:
The
ALTER TABLE ALTER COLUMN $columnName SET CYCLE
command does not raise an error even on identity columns in pre-10.12
databases. Those identity columns are not backed by sequence generators.
Afterwards, the columns do not cycle, even though the ALTER TABLE command
appeared to run successfully. This should be easy to fix. The parser just needs
to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases. The
following scripts show this behavior:
{noformat}
-- run the following script with version 10.10.1.1:
connect 'jdbc:derby:db;create=true';
create table t1(a int generated always as identity (start with 2147483646), b
int);
insert into t1(b) values (1);
insert into t1(b) values (2);
-- fails as expected
insert into t1(b) values (3);
select * from t1 order by b;
create table t2(a int generated always as identity (start with 2147483646), b
int);
-- now run the following script with 10.14
connect 'jdbc:derby:db';
-- succeeds but should not
alter table t2 alter column a set cycle;
insert into t2(b) values (1);
insert into t2(b) values (2);
-- fails because the cycling behavior did not change
insert into t2(b) values (3);
select * from t2 order by b;
{noformat}
was:
The
ALTER TABLE ALTER COLUMN $columnName SET CYCLE
command dies not raise an error even on identity columns in pre-10.12
databases. Those identity columns are not backed by sequence generators.
Afterwards, the columns do not cycle, even though the ALTER TABLE command
appeared to run successfully. This should be easy to fix. The parser just needs
to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases. The
following scripts show this behavior:
{noformat}
-- run the following script with version 10.10.1.1:
connect 'jdbc:derby:db;create=true';
create table t1(a int generated always as identity (start with 2147483646), b
int);
insert into t1(b) values (1);
insert into t1(b) values (2);
-- fails as expected
insert into t1(b) values (3);
select * from t1 order by b;
create table t2(a int generated always as identity (start with 2147483646), b
int);
-- now run the following script with 10.14
connect 'jdbc:derby:db';
-- succeeds but should not
alter table t2 alter column a set cycle;
insert into t2(b) values (1);
insert into t2(b) values (2);
-- fails because the cycling behavior did not change
insert into t2(b) values (3);
select * from t2 order by b;
{noformat}
> Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
> ---
>
> Key: DERBY-6962
> URL: https://issues.apache.org/jira/browse/DERBY-6962
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
> Fix For: 10.14.0.0
>
>
> The
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> command does not raise an error even on identity columns in pre-10.12
> databases. Those identity columns are not backed by sequence generators.
> Afterwards, the columns do not cycle, even though the ALTER TABLE command
> appeared to run successfully. This should be easy to fix. The parser just
> needs to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases.
> The following scripts show this behavior:
> {noformat}
> -- run the following script with version 10.10.1.1:
> connect 'jdbc:derby:db;create=true';
> create table t1(a int generated always as identity (start with 2147483646), b
> int);
> insert into t1(b) values (1);
> insert into t1(b) values (2);
> -- fails as expected
> insert into t1(b) values (3);
> select * from t1 order by b;
> create table t2(a int generated always as identity (start with 2147483646), b
> int);
> -- now run the following script with 10.14
> connect 'jdbc:derby:db';
> -- succeeds but should not
> alter table t2 alter column a set cycle;
> insert into t2(b) values (1);
> insert into t2(b) values (2);
> -- fails because the cycling behavior did not change
> insert into t2(b) values (3);
> select * from t2 order by b;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (DERBY-6962) Forbid ALTER TABLE ... SET CYCLE on identity columns in pre-10.12 databases
Rick Hillegas created DERBY-6962:
Summary: Forbid ALTER TABLE ... SET CYCLE on identity columns in
pre-10.12 databases
Key: DERBY-6962
URL: https://issues.apache.org/jira/browse/DERBY-6962
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.14.0.0
Reporter: Rick Hillegas
Fix For: 10.14.0.0
The
ALTER TABLE ALTER COLUMN $columnName SET CYCLE
command dies not raise an error even on identity columns in pre-10.12
databases. Those identity columns are not backed by sequence generators.
Afterwards, the columns do not cycle, even though the ALTER TABLE command
appeared to run successfully. This should be easy to fix. The parser just needs
to forbid the ALTER TABLE...SET CYCLE command in pre-10.12 databases. The
following scripts show this behavior:
{noformat}
-- run the following script with version 10.10.1.1:
connect 'jdbc:derby:db;create=true';
create table t1(a int generated always as identity (start with 2147483646), b
int);
insert into t1(b) values (1);
insert into t1(b) values (2);
-- fails as expected
insert into t1(b) values (3);
select * from t1 order by b;
create table t2(a int generated always as identity (start with 2147483646), b
int);
-- now run the following script with 10.14
connect 'jdbc:derby:db';
-- succeeds but should not
alter table t2 alter column a set cycle;
insert into t2(b) values (1);
insert into t2(b) values (2);
-- fails because the cycling behavior did not change
insert into t2(b) values (3);
select * from t2 order by b;
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6961) SET CYCLE fails to let an identity column cycle if the range is already exhausted
[
https://issues.apache.org/jira/browse/DERBY-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165588#comment-16165588
]
Rick Hillegas commented on DERBY-6961:
--
Here's another, similar problem: If a CYCLE identity column is on the verge of
wrapping around and then the column is ALTERed to NO CYCLE, then the next
insert into the table should fail. But that insert succeeds, incorrectly. The
following script shows this:
{noformat}
connect 'jdbc:derby:memory:db;create=true';
create table t1(a int generated always as identity (start with 2147483646
cycle), b int);
insert into t1(b) values (1);
alter table t1 alter column a set no cycle;
insert into t1(b) values (2);
-- fails as expected
insert into t1(b) values (3);
select * from t1 order by b;
--
create table t2(a int generated always as identity (start with 2147483646
cycle), b int);
insert into t2(b) values (1);
insert into t2(b) values (2);
alter table t2 alter column a set no cycle;
-- should fail but does not
insert into t2(b) values (3);
select * from t2 order by b;
{noformat}
> SET CYCLE fails to let an identity column cycle if the range is already
> exhausted
> -
>
> Key: DERBY-6961
> URL: https://issues.apache.org/jira/browse/DERBY-6961
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>
> If a NO CYCLE identity column exhausts its range, then...
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> ...will not revive the identity column. No more rows can be inserted into the
> table. This violates the SQL Standard and is very surprising behavior after
> the ALTER TABLE command completed successfully.
> The problem is that the exhausted sequence generator has a next value of
> NULL, signifying that it is done. After the ALTER TABLE command, the next
> value of the sequence generator should be the minimum value (for an ascending
> sequence generator) or the maximum value (for a descending sequence
> generator) according to the 2016 SQL Standard, section 4.27.2 (Operations
> involving sequence generators), quoted here in full:
> "When a is applied to a sequence generator SG, SG
> issues a value V taken from SG's current cycle such that V is expressible as
> the current base value of SG plus N multiplied by the increment of SG, where
> N is a non-negative number.
> Thus a sequence generator will normally issue all of the values in its cycle
> and these will normally be in increasing or decreasing order (depending on
> the sign of the increment) but within that general ordering separate
> subgroups of ordered values may occur.
> If the sequence generator's cycle is exhausted (i.e., it cannot issue a value
> that meets the criteria), then a new cycle is created with the current base
> value set to the minimum value of SG (if SG is an ascending sequence
> generator) or the maximum value of SG (if SG is a descending sequence
> generator).
> If a new cycle is created and the descriptor of SG includes NOCYCLE, then an
> exception condition is raised.
> If there are multiple instances of s specifying the
> same sequence generator within a single SQL-statement, all those instances
> return the same value for a given row processed by that SQL-statement."
> The following script shows this problem:
> {noformat}
> connect 'jdbc:derby:memory:db;create=true';
>
> --
> -- Exhaust a NO CYCLE identity column.
> -- SET CYCLE does not allow the sequence generator
> -- to continue processing.
> --
>
> create table t_noCycleExhaust(a int generated always as identity (start with
> 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (2);
> -- the sequence generator has NULL as its next value
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- should fail
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
> alter table t_noCycleExhaust alter column a set cycle;
> -- the sequence generator still has NULL as its next value. this is the bug.
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- incorrectly fails
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
>
> --
> -- Do NOT exhaust a NO CYCLE identity column.
> -- Then SET CYCLE. The
[jira] [Resolved] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas resolved DERBY-6959. -- Resolution: Fixed I am done working on this issue. > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff, > derby-6959-01-ab-requireSETkeyword.diff, derby-6959-02-aa-setCycleDocs.diff, > rrefsqlj81859.html > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas closed DERBY-6959. > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff, > derby-6959-01-ab-requireSETkeyword.diff, derby-6959-02-aa-setCycleDocs.diff, > rrefsqlj81859.html > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6961) SET CYCLE fails to let an identity column cycle if the range is already exhausted
[
https://issues.apache.org/jira/browse/DERBY-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165546#comment-16165546
]
Rick Hillegas commented on DERBY-6961:
--
Hey Bryan,
I haven't looked at the code. But I think that it should be easy to fix. The
underlying sequence generator needs to be queried, the value in the system
tables needs to be updated, and the sequence generator needs to be destroyed so
that it can be recreated after the DBA commits the transaction which runs the
ALTER TABLE command.
Thanks,
-Rick
> SET CYCLE fails to let an identity column cycle if the range is already
> exhausted
> -
>
> Key: DERBY-6961
> URL: https://issues.apache.org/jira/browse/DERBY-6961
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.0.0
>Reporter: Rick Hillegas
>
> If a NO CYCLE identity column exhausts its range, then...
> ALTER TABLE ALTER COLUMN $columnName SET CYCLE
> ...will not revive the identity column. No more rows can be inserted into the
> table. This violates the SQL Standard and is very surprising behavior after
> the ALTER TABLE command completed successfully.
> The problem is that the exhausted sequence generator has a next value of
> NULL, signifying that it is done. After the ALTER TABLE command, the next
> value of the sequence generator should be the minimum value (for an ascending
> sequence generator) or the maximum value (for a descending sequence
> generator) according to the 2016 SQL Standard, section 4.27.2 (Operations
> involving sequence generators), quoted here in full:
> "When a is applied to a sequence generator SG, SG
> issues a value V taken from SG's current cycle such that V is expressible as
> the current base value of SG plus N multiplied by the increment of SG, where
> N is a non-negative number.
> Thus a sequence generator will normally issue all of the values in its cycle
> and these will normally be in increasing or decreasing order (depending on
> the sign of the increment) but within that general ordering separate
> subgroups of ordered values may occur.
> If the sequence generator's cycle is exhausted (i.e., it cannot issue a value
> that meets the criteria), then a new cycle is created with the current base
> value set to the minimum value of SG (if SG is an ascending sequence
> generator) or the maximum value of SG (if SG is a descending sequence
> generator).
> If a new cycle is created and the descriptor of SG includes NOCYCLE, then an
> exception condition is raised.
> If there are multiple instances of s specifying the
> same sequence generator within a single SQL-statement, all those instances
> return the same value for a given row processed by that SQL-statement."
> The following script shows this problem:
> {noformat}
> connect 'jdbc:derby:memory:db;create=true';
>
> --
> -- Exhaust a NO CYCLE identity column.
> -- SET CYCLE does not allow the sequence generator
> -- to continue processing.
> --
>
> create table t_noCycleExhaust(a int generated always as identity (start with
> 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> insert into t_noCycleExhaust(b) values (2);
> -- the sequence generator has NULL as its next value
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- should fail
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
> alter table t_noCycleExhaust alter column a set cycle;
> -- the sequence generator still has NULL as its next value. this is the bug.
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> -- incorrectly fails
> insert into t_noCycleExhaust(b) values (3);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
> select * from t_noCycleExhaust order by b;
>
> --
> -- Do NOT exhaust a NO CYCLE identity column.
> -- Then SET CYCLE. The sequence generator will
> -- wrap around.
> --
>
> create table t_noCycleDoNotExhaust(a int generated always as identity (start
> with 2147483646 no cycle), b int);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> insert into t_noCycleDoNotExhaust(b) values (1);
> values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
> alter table t_noCycleDoNotExhaust alter column a set cycle;
> values syscs_util.syscs_peek_at_identity('APP',
[jira] [Created] (DERBY-6961) SET CYCLE fails to let an identity column cycle if the range is already exhausted
Rick Hillegas created DERBY-6961:
Summary: SET CYCLE fails to let an identity column cycle if the
range is already exhausted
Key: DERBY-6961
URL: https://issues.apache.org/jira/browse/DERBY-6961
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.14.0.0
Reporter: Rick Hillegas
If a NO CYCLE identity column exhausts its range, then...
ALTER TABLE ALTER COLUMN $columnName SET CYCLE
...will not revive the identity column. No more rows can be inserted into the
table. This violates the SQL Standard and is very surprising behavior after the
ALTER TABLE command completed successfully.
The problem is that the exhausted sequence generator has a next value of NULL,
signifying that it is done. After the ALTER TABLE command, the next value of
the sequence generator should be the minimum value (for an ascending sequence
generator) or the maximum value (for a descending sequence generator) according
to the 2016 SQL Standard, section 4.27.2 (Operations involving sequence
generators), quoted here in full:
"When a is applied to a sequence generator SG, SG
issues a value V taken from SG's current cycle such that V is expressible as
the current base value of SG plus N multiplied by the increment of SG, where N
is a non-negative number.
Thus a sequence generator will normally issue all of the values in its cycle
and these will normally be in increasing or decreasing order (depending on the
sign of the increment) but within that general ordering separate subgroups of
ordered values may occur.
If the sequence generator's cycle is exhausted (i.e., it cannot issue a value
that meets the criteria), then a new cycle is created with the current base
value set to the minimum value of SG (if SG is an ascending sequence generator)
or the maximum value of SG (if SG is a descending sequence generator).
If a new cycle is created and the descriptor of SG includes NOCYCLE, then an
exception condition is raised.
If there are multiple instances of s specifying the same
sequence generator within a single SQL-statement, all those instances return
the same value for a given row processed by that SQL-statement."
The following script shows this problem:
{noformat}
connect 'jdbc:derby:memory:db;create=true';
--
-- Exhaust a NO CYCLE identity column.
-- SET CYCLE does not allow the sequence generator
-- to continue processing.
--
create table t_noCycleExhaust(a int generated always as identity (start with
2147483646 no cycle), b int);
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
insert into t_noCycleExhaust(b) values (1);
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
insert into t_noCycleExhaust(b) values (2);
-- the sequence generator has NULL as its next value
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
-- should fail
insert into t_noCycleExhaust(b) values (3);
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
select * from t_noCycleExhaust order by b;
alter table t_noCycleExhaust alter column a set cycle;
-- the sequence generator still has NULL as its next value. this is the bug.
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
-- incorrectly fails
insert into t_noCycleExhaust(b) values (3);
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEEXHAUST');
select * from t_noCycleExhaust order by b;
--
-- Do NOT exhaust a NO CYCLE identity column.
-- Then SET CYCLE. The sequence generator will
-- wrap around.
--
create table t_noCycleDoNotExhaust(a int generated always as identity (start
with 2147483646 no cycle), b int);
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
insert into t_noCycleDoNotExhaust(b) values (1);
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
alter table t_noCycleDoNotExhaust alter column a set cycle;
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
insert into t_noCycleDoNotExhaust(b) values (2);
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
insert into t_noCycleDoNotExhaust(b) values (3);
values syscs_util.syscs_peek_at_identity('APP', 'T_NOCYCLEDONOTEXHAUST');
select * from t_noCycleDoNotExhaust order by b;
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160492#comment-16160492 ] Rick Hillegas edited comment on DERBY-6959 at 9/11/17 4:43 AM: --- Attaching derby-6959-01-ab-requireSETkeyword.diff. This version of the patch corrects the grammar in order to fix a bug discovered by AlterTableTest. Touches the same files. was (Author: rhillegas): Attaching derby-6959-01-ab-requireSETkeyword.diff. This version of the test corrects the grammar in order to fix a bug discovered by AlterTableTest. Touches the same files. > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff, > derby-6959-01-ab-requireSETkeyword.diff, derby-6959-02-aa-setCycleDocs.diff, > rrefsqlj81859.html > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160454#comment-16160454 ] Rick Hillegas edited comment on DERBY-6959 at 9/11/17 4:43 AM: --- Attaching derby-6959-01-aa-requireSETkeyword.diff. This patch makes the SET keyword mandatory when altering the cycling behavior of an auto-increment column. I am running the full tests now. Touches the following files: M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj M java/testing/org/apache/derbyTesting/functionTests/tests/lang/AutoIncrementTest.java was (Author: rhillegas): Attaching derby-6959-01-aa-requireSETkeyword.diff. This patch makes the SET keyword mandatory when altering the cycle behavior of an auto-increment column. I am running the full tests now. Touches the following files: M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj M java/testing/org/apache/derbyTesting/functionTests/tests/lang/AutoIncrementTest.java > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff, > derby-6959-01-ab-requireSETkeyword.diff, derby-6959-02-aa-setCycleDocs.diff, > rrefsqlj81859.html > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6959: - Attachment: rrefsqlj81859.html > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff, > derby-6959-01-ab-requireSETkeyword.diff, derby-6959-02-aa-setCycleDocs.diff, > rrefsqlj81859.html > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6959: - Attachment: derby-6959-02-aa-setCycleDocs.diff Attaching derby-6959-02-aa-setCycleDocs.diff. This updates the Reference Manual section on ALTER TABLE to include the SET keyword in the grammar for changing the cycling behavior of an identity column. Also attaching the generated html output: rrefsqlj81859.html Touches the following file: M src/ref/rrefsqlj81859.dita > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff, > derby-6959-01-ab-requireSETkeyword.diff, derby-6959-02-aa-setCycleDocs.diff > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160649#comment-16160649 ] Rick Hillegas commented on DERBY-6959: -- Tests passed cleanly on derby-6959-01-ab-requireSETkeyword.diff. > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff, > derby-6959-01-ab-requireSETkeyword.diff > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DERBY-6960) Cleanup LOOKAHEADS in parser production for ALTER TABLE ALTER COLUMN
Rick Hillegas created DERBY-6960: Summary: Cleanup LOOKAHEADS in parser production for ALTER TABLE ALTER COLUMN Key: DERBY-6960 URL: https://issues.apache.org/jira/browse/DERBY-6960 Project: Derby Issue Type: Task Components: SQL Affects Versions: 10.14.0.0 Reporter: Rick Hillegas The columnAlterClause() production has a lot of LOOKAHEADs. It is probably possible to simplify this production and make it more readable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6959: - Attachment: derby-6959-01-ab-requireSETkeyword.diff Attaching derby-6959-01-ab-requireSETkeyword.diff. This version of the test corrects the grammar in order to fix a bug discovered by AlterTableTest. Touches the same files. > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff, > derby-6959-01-ab-requireSETkeyword.diff > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6959: - Attachment: derby-6959-01-aa-requireSETkeyword.diff Attaching derby-6959-01-aa-requireSETkeyword.diff. This patch makes the SET keyword mandatory when altering the cycle behavior of an auto-increment column. I am running the full tests now. Touches the following files: M java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj M java/testing/org/apache/derbyTesting/functionTests/tests/lang/AutoIncrementTest.java > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > Attachments: derby-6959-01-aa-requireSETkeyword.diff > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas reassigned DERBY-6959: Assignee: Rick Hillegas > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Fix For: 10.14.0.0 > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6959) Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
[ https://issues.apache.org/jira/browse/DERBY-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6959: - Summary: Require the Standard SET keyword in the syntax for changing the cycle behavior of identity columns (was: Required the Standard SET keyword in the syntax for changing the cycle behavior of identity columns) > Require the Standard SET keyword in the syntax for changing the cycle > behavior of identity columns > -- > > Key: DERBY-6959 > URL: https://issues.apache.org/jira/browse/DERBY-6959 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.14.0.0 >Reporter: Rick Hillegas > Fix For: 10.14.0.0 > > > The correct syntax for changing the cycling behavior of an auto-increment > column is... > ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE > ...according to the 2016 SQL Standard, part 2, sections 11.20 ( identity column specification) and 11.72 (). > This is also the syntax used by DB2 (see > https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). > Right now Derby does not accept the required SET keyword. We should bring > Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DERBY-6959) Required the Standard SET keyword in the syntax for changing the cycle behavior of identity columns
Rick Hillegas created DERBY-6959: Summary: Required the Standard SET keyword in the syntax for changing the cycle behavior of identity columns Key: DERBY-6959 URL: https://issues.apache.org/jira/browse/DERBY-6959 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.14.0.0 Reporter: Rick Hillegas Fix For: 10.14.0.0 The correct syntax for changing the cycling behavior of an auto-increment column is... ALTER TABLE ALTER COLUMN $columnName SET [NO] CYCLE ...according to the 2016 SQL Standard, part 2, sections 11.20 (). This is also the syntax used by DB2 (see https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/sqlref/src/tpc/db2z_sql_altertable.html). Right now Derby does not accept the required SET keyword. We should bring Derby into compliance with the Standard. I will attach a patch to do this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6958) Clean up the Derby website
[ https://issues.apache.org/jira/browse/DERBY-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160370#comment-16160370 ] Rick Hillegas commented on DERBY-6958: -- Linking to derby-6941 because I stumbled across these issues while re-organizing the download page. > Clean up the Derby website > -- > > Key: DERBY-6958 > URL: https://issues.apache.org/jira/browse/DERBY-6958 > Project: Derby > Issue Type: Improvement > Components: Web Site >Affects Versions: 10.13.1.1 >Reporter: Rick Hillegas > > The Derby website is stale and needs to be cleaned up. Here is an initial > list of things I want to clean up: > 1) The copyright year in the page footer is 2015. That should be 2017. Extra > credit if we can parameterize the footer so that the copyright year is > automatically updated whenever we refresh the website with a new release. > 2) The document references in the FAQ (http://db.apache.org/derby/faq.html) > are hard-coded. I just updated them from 10.7 doc references to be 10.13 > references. But we should parameterize doc references across the Derby > website so that, again, they are updated whenever we refresh the website with > a new release. > 3) I removed dead links in some of the top-level pages along with stale > information. We need to make a systematic pass through the whole website. > Extra credit if we can automate the location of dead links so that we can > clean up the website when we publish releases. > 4) We need to remove material which addresses old issues which no-one cares > about any more. > 5) Extra credit if we can cleanup the wiki similarly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DERBY-6958) Clean up the Derby website
Rick Hillegas created DERBY-6958: Summary: Clean up the Derby website Key: DERBY-6958 URL: https://issues.apache.org/jira/browse/DERBY-6958 Project: Derby Issue Type: Improvement Components: Web Site Affects Versions: 10.13.1.1 Reporter: Rick Hillegas The Derby website is stale and needs to be cleaned up. Here is an initial list of things I want to clean up: 1) The copyright year in the page footer is 2015. That should be 2017. Extra credit if we can parameterize the footer so that the copyright year is automatically updated whenever we refresh the website with a new release. 2) The document references in the FAQ (http://db.apache.org/derby/faq.html) are hard-coded. I just updated them from 10.7 doc references to be 10.13 references. But we should parameterize doc references across the Derby website so that, again, they are updated whenever we refresh the website with a new release. 3) I removed dead links in some of the top-level pages along with stale information. We need to make a systematic pass through the whole website. Extra credit if we can automate the location of dead links so that we can clean up the website when we publish releases. 4) We need to remove material which addresses old issues which no-one cares about any more. 5) Extra credit if we can cleanup the wiki similarly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160119#comment-16160119 ] Rick Hillegas commented on DERBY-6941: -- revision 1807935, the generated website changes corresponding to the previous commit of derby-6941-02-aa-organizeDownloadsByJavaVersion.diff. > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff, > derby-6941-02-aa-organizeDownloadsByJavaVersion.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6941: - Attachment: derby-6941-02-aa-organizeDownloadsByJavaVersion.diff Attaching derby-6941-02-aa-organizeDownloadsByJavaVersion.diff. This patch re-organizes the downloads page under headings which indicate which Java platforms can be used with each of the Derby releases. Other minor site cleanup: removing dead links, removing obsolete FAQ entries, and re-wording some awkward sentences. > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff, > derby-6941-02-aa-organizeDownloadsByJavaVersion.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-6941: - Attachment: derby-6941-01-aa-dryRunOfReleaseNotes.diff Attaching derby-6941-01-aa-dryRunOfReleaseNotes.diff. This patch adjusts some files based on a recent dry-run of the release notes generator. Touches the following files: -- M RELEASE-NOTES.html M releaseSummary.xml Text specific to the 10.14.1 release. Adjust the input releaseSummary text and checkin the resulting release notes. -- M java/build/org/apache/derbyBuild/ReleaseNotesGenerator.java So far this release has no detailed release notes. Made the generator smart enough to detect this condition and say so. -- M tools/release/jirasoap/src/main/java/org/apache/derbyBuild/jirasoap/FilteredIssueLister.java Added some more diagnostics to the issue lister. It was failing because the 10.13.1.1 release had not been marked as released. > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > Attachments: derby-6941-01-aa-dryRunOfReleaseNotes.diff > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (DERBY-6941) Tasks for producing a 10.14.1 release
[ https://issues.apache.org/jira/browse/DERBY-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas reassigned DERBY-6941: Assignee: Rick Hillegas > Tasks for producing a 10.14.1 release > - > > Key: DERBY-6941 > URL: https://issues.apache.org/jira/browse/DERBY-6941 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas >Assignee: Rick Hillegas > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (DERBY-6956) Create table as Select cannot copy Decimal columns
[
https://issues.apache.org/jira/browse/DERBY-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas resolved DERBY-6956.
--
Resolution: Fixed
Fix Version/s: 10.14.0.0
> Create table as Select cannot copy Decimal columns
> --
>
> Key: DERBY-6956
> URL: https://issues.apache.org/jira/browse/DERBY-6956
> Project: Derby
> Issue Type: Bug
> Components: JDBC, SQL
>Affects Versions: 10.13.1.1
> Environment: Windows 7, DataGrip
>Reporter: Murat Cengiz
> Labels: newbie
> Fix For: 10.14.0.0
>
> Attachments: derby-6956-01-aa-removeSpuriousCheck.diff, withTest.diff
>
>
> I create a test table with the following query:
> CREATE TABLE "DERBYTEST" ("STRINGCOLUMN" varchar(255), "INTEGERCOLUMN"
> integer, "SHORTCOLUMN" varchar(255), "LONGCOLUMN" bigint, "DOUBLECOLUMN"
> double, "FLOATCOLUMN" double, "DECIMALCOLUMN" decimal(31, 6), "BOOLEANCOLUMN"
> smallint, "DATECOLUMN" timestamp, "DATETIMECOLUMN" timestamp, "ID" integer,
> "LASTMODTIME" timestamp, PRIMARY KEY ("ID"))
> this query completes successfully
> I later try to copy the table with the following query:
> CREATE TABLE "DERBYTEST_TEMP" AS SELECT * FROM DERBYTEST WITH NO DATA
> This throws the following exception:
> [42X71][3] Invalid data type 'DECIMAL(31, 6)' for column 'DECIMALCOLUMN'
> Everything works perfectly fine if I remove the decimal column.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6956) Create table as Select cannot copy Decimal columns
[
https://issues.apache.org/jira/browse/DERBY-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16134254#comment-16134254
]
Rick Hillegas commented on DERBY-6956:
--
Hi Bryan,
Thanks for the additional tests. I don't plan to backport this fix to any other
codelines. I think that the issue can be resolved. What are your thoughts?
> Create table as Select cannot copy Decimal columns
> --
>
> Key: DERBY-6956
> URL: https://issues.apache.org/jira/browse/DERBY-6956
> Project: Derby
> Issue Type: Bug
> Components: JDBC, SQL
>Affects Versions: 10.13.1.1
> Environment: Windows 7, DataGrip
>Reporter: Murat Cengiz
> Labels: newbie
> Attachments: derby-6956-01-aa-removeSpuriousCheck.diff, withTest.diff
>
>
> I create a test table with the following query:
> CREATE TABLE "DERBYTEST" ("STRINGCOLUMN" varchar(255), "INTEGERCOLUMN"
> integer, "SHORTCOLUMN" varchar(255), "LONGCOLUMN" bigint, "DOUBLECOLUMN"
> double, "FLOATCOLUMN" double, "DECIMALCOLUMN" decimal(31, 6), "BOOLEANCOLUMN"
> smallint, "DATECOLUMN" timestamp, "DATETIMECOLUMN" timestamp, "ID" integer,
> "LASTMODTIME" timestamp, PRIMARY KEY ("ID"))
> this query completes successfully
> I later try to copy the table with the following query:
> CREATE TABLE "DERBYTEST_TEMP" AS SELECT * FROM DERBYTEST WITH NO DATA
> This throws the following exception:
> [42X71][3] Invalid data type 'DECIMAL(31, 6)' for column 'DECIMALCOLUMN'
> Everything works perfectly fine if I remove the decimal column.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6956) Create table as Select cannot copy Decimal columns
[
https://issues.apache.org/jira/browse/DERBY-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16129738#comment-16129738
]
Rick Hillegas commented on DERBY-6956:
--
Thanks, Bryan. I have committed the derby-6956-01-aa-removeSpuriousCheck.diff
patch.
> Create table as Select cannot copy Decimal columns
> --
>
> Key: DERBY-6956
> URL: https://issues.apache.org/jira/browse/DERBY-6956
> Project: Derby
> Issue Type: Bug
> Components: JDBC, SQL
>Affects Versions: 10.13.1.1
> Environment: Windows 7, DataGrip
>Reporter: Murat Cengiz
> Labels: newbie
> Attachments: derby-6956-01-aa-removeSpuriousCheck.diff, withTest.diff
>
>
> I create a test table with the following query:
> CREATE TABLE "DERBYTEST" ("STRINGCOLUMN" varchar(255), "INTEGERCOLUMN"
> integer, "SHORTCOLUMN" varchar(255), "LONGCOLUMN" bigint, "DOUBLECOLUMN"
> double, "FLOATCOLUMN" double, "DECIMALCOLUMN" decimal(31, 6), "BOOLEANCOLUMN"
> smallint, "DATECOLUMN" timestamp, "DATETIMECOLUMN" timestamp, "ID" integer,
> "LASTMODTIME" timestamp, PRIMARY KEY ("ID"))
> this query completes successfully
> I later try to copy the table with the following query:
> CREATE TABLE "DERBYTEST_TEMP" AS SELECT * FROM DERBYTEST WITH NO DATA
> This throws the following exception:
> [42X71][3] Invalid data type 'DECIMAL(31, 6)' for column 'DECIMALCOLUMN'
> Everything works perfectly fine if I remove the decimal column.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-6956) Create table as Select cannot copy Decimal columns
[
https://issues.apache.org/jira/browse/DERBY-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6956:
-
Attachment: derby-6956-01-aa-removeSpuriousCheck.diff
Attaching derby-6956-01-aa-removeSpuriousCheck.diff. This patch removes the
offending extra check for maximum width. Tests passed cleanly against this
patch.
Thanks for digging into the code, Bryan. I think that the extra check is just a
mistake. The datatype rejected by CREATE TABLE AS SELECT is exactly the same
datatype which was used by CREATE TABLE. The remaining checks for DECIMAL look
adequate to me.
I am inclined to commit this patch.
> Create table as Select cannot copy Decimal columns
> --
>
> Key: DERBY-6956
> URL: https://issues.apache.org/jira/browse/DERBY-6956
> Project: Derby
> Issue Type: Bug
> Components: JDBC, SQL
>Affects Versions: 10.13.1.1
> Environment: Windows 7, DataGrip
>Reporter: Murat Cengiz
> Labels: newbie
> Attachments: derby-6956-01-aa-removeSpuriousCheck.diff
>
>
> I create a test table with the following query:
> CREATE TABLE "DERBYTEST" ("STRINGCOLUMN" varchar(255), "INTEGERCOLUMN"
> integer, "SHORTCOLUMN" varchar(255), "LONGCOLUMN" bigint, "DOUBLECOLUMN"
> double, "FLOATCOLUMN" double, "DECIMALCOLUMN" decimal(31, 6), "BOOLEANCOLUMN"
> smallint, "DATECOLUMN" timestamp, "DATETIMECOLUMN" timestamp, "ID" integer,
> "LASTMODTIME" timestamp, PRIMARY KEY ("ID"))
> this query completes successfully
> I later try to copy the table with the following query:
> CREATE TABLE "DERBYTEST_TEMP" AS SELECT * FROM DERBYTEST WITH NO DATA
> This throws the following exception:
> [42X71][3] Invalid data type 'DECIMAL(31, 6)' for column 'DECIMALCOLUMN'
> Everything works perfectly fine if I remove the decimal column.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6956) Create table as Select cannot copy Decimal columns
[
https://issues.apache.org/jira/browse/DERBY-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16126720#comment-16126720
]
Rick Hillegas commented on DERBY-6956:
--
The CREATE TABLE AS SELECT statement fails because we flunk the following
check...
(getMaximumWidth() <= typeId.getMaximumMaximumWidth());
at line 1859 in DataTypeDescriptor.java. That, in turn is because the maximum
width accounts for a sign byte and a decimal point byte in addition to the
maximum number of digits in the decimal. I don't know yet why that check is
necessary.
> Create table as Select cannot copy Decimal columns
> --
>
> Key: DERBY-6956
> URL: https://issues.apache.org/jira/browse/DERBY-6956
> Project: Derby
> Issue Type: Bug
> Components: JDBC, SQL
>Affects Versions: 10.13.1.1
> Environment: Windows 7, DataGrip
>Reporter: Murat Cengiz
> Labels: newbie
>
> I create a test table with the following query:
> CREATE TABLE "DERBYTEST" ("STRINGCOLUMN" varchar(255), "INTEGERCOLUMN"
> integer, "SHORTCOLUMN" varchar(255), "LONGCOLUMN" bigint, "DOUBLECOLUMN"
> double, "FLOATCOLUMN" double, "DECIMALCOLUMN" decimal(31, 6), "BOOLEANCOLUMN"
> smallint, "DATECOLUMN" timestamp, "DATETIMECOLUMN" timestamp, "ID" integer,
> "LASTMODTIME" timestamp, PRIMARY KEY ("ID"))
> this query completes successfully
> I later try to copy the table with the following query:
> CREATE TABLE "DERBYTEST_TEMP" AS SELECT * FROM DERBYTEST WITH NO DATA
> This throws the following exception:
> [42X71][3] Invalid data type 'DECIMAL(31, 6)' for column 'DECIMALCOLUMN'
> Everything works perfectly fine if I remove the decimal column.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9
[ https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124749#comment-16124749 ] Rick Hillegas commented on DERBY-6856: -- I tested Derby against build 181 of JDK 9: o with 6856 patch, Derby compiles cleanly o with 6856 patch, tests run cleanly o with 6856 patch, javadoc compiles cleanly o the development trunk, compiled with JDK 8, runs tests cleanly under JDK 9 o 10.13.1.1 runs the JUNIT tests cleanly under JDK 9 The canon-based tests failed to run when using 10.13.1.1 against JDK 9. This is because the derbyall script could not be found. That, in turn, is because 10.13.1.1 does not have the derby-6856-11-aa-jigsawResourceLocation.diff (see above). In short, build 181 of JDK 9 looks good to me. > Make it possible to build Derby using JDK 9 > --- > > Key: DERBY-6856 > URL: https://issues.apache.org/jira/browse/DERBY-6856 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.12.1.1 >Reporter: Rick Hillegas > Attachments: derby-6856-01-ab-addShardingKey.diff, > derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff, > derby-6856-03-aa-autoboxingDeprecationWarnings.diff, > derby-6856-03-ab-autoboxingDeprecationWarnings.diff, > derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff, > derby-6856-04-ab-autoboxingDeprecationWarnings-part2.diff, > derby-6856-05-ac-roundingMode-Class.newInstance.diff, > derby-6856-05-af-roundingMode-Class.getDeclaredConstructor.diff, > derby-6856-05-ag-roundingMode-Class.newInstance.diff, > derby-6856-06-aa-observable.diff, derby-6856-07-aa-oneMoreNewInstance.diff, > derby-6856-08-aa-cleanupJavadoc.diff, derby-6856-09-aa-javadocEntities.diff, > derby-6856-10-aa-disable-permissions-subverting-test.diff, > derby-6856-11-aa-jigsawResourceLocation.diff, derby-6856-XX-ab-base.diff, > derby-6856-XX-ac-base.diff, derby-6856-XX-ad-base.diff, > derby-6856-XX-ae-base.diff, PTest.java, ptestScript > > > Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like > java.sql.ShardingKey and methods which refer to these new classes. > In addition, project Jigsaw has created a new way to name classes (see > http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool > which we use so that old JVMs can compile Derby and so that Derby can be > compiled to run on old JVMs. > It is likely that we will need to leave this issue open throughout the > development cycle of Java 9. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-5261) NetworkServerControl prints usage message twice on some errors
[
https://issues.apache.org/jira/browse/DERBY-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099347#comment-16099347
]
Rick Hillegas commented on DERBY-5261:
--
I think that Bryan is suggesting that you add a test case to
NetworkServerControlClientCommandTest. The test case would call
assertExecJavaCmdAsExpected() just as
NetworkServerControlClientCommandTest.assertSuccessfulPing() does.
> NetworkServerControl prints usage message twice on some errors
> --
>
> Key: DERBY-5261
> URL: https://issues.apache.org/jira/browse/DERBY-5261
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.8.1.2
>Reporter: Knut Anders Hatlen
>Assignee: INDIKA KUMARA
>Priority: Minor
> Labels: derby_triage10_9
>
> If you invoke NetworkServerControl with an invalid command, the usage message
> will be printed twice.
> $ java -jar derbynet.jar abc
> Mon Jun 06 10:14:25 CEST 2011 : Command abc is unknown.
> Usage: NetworkServerControl
> Commands:
> start [-h ] [-p ] [-noSecurityManager] [-ssl ]
> shutdown [-h ][-p ] [-ssl ] [-user ]
> [-password ]
> ping [-h ][-p ] [-ssl ]
> sysinfo [-h ][-p ] [-ssl ]
> runtimeinfo [-h ][-p ] [-ssl ]
> logconnections {on|off} [-h ][-p ] [-ssl ]
> maxthreads [-h ][-p ] [-ssl ]
> timeslice [-h ][-p ] [-ssl ]
> trace {on|off} [-s ][-h ][-p ] [-ssl ]
> tracedirectory [-h ][-p ] [-ssl ]
> Mon Jun 06 10:14:25 CEST 2011 : No command given.
> Usage: NetworkServerControl
> Commands:
> start [-h ] [-p ] [-noSecurityManager] [-ssl ]
> shutdown [-h ][-p ] [-ssl ] [-user ]
> [-password ]
> ping [-h ][-p ] [-ssl ]
> sysinfo [-h ][-p ] [-ssl ]
> runtimeinfo [-h ][-p ] [-ssl ]
> logconnections {on|off} [-h ][-p ] [-ssl ]
> maxthreads [-h ][-p ] [-ssl ]
> timeslice [-h ][-p ] [-ssl ]
> trace {on|off} [-s ][-h ][-p ] [-ssl ]
> tracedirectory [-h ][-p ] [-ssl ]
> Printing it once should be enough.
> The same problem is seen if you don't specify a required argument for an
> option. For example "java -jar derbynet start -p" (no port number).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6953) Support Standard syntax for retrieving INSERTed key values
[
https://issues.apache.org/jira/browse/DERBY-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16097472#comment-16097472
]
Rick Hillegas commented on DERBY-6953:
--
Thanks for that reference, Lukas. The grammar stanzas you cited are from the
2016 Standard, part 2, section 7.6 . According to GR 5b, for
an INSERT, with NEW, the contents of the are defined by section 15.10 (Effect of inserting tables into base
tables). It appears to be the set of all inserted rows, including all of their
columns. My reading of this language is that the user would phrase an insert
statement like this:
{noformat}
select keyCol from new table
(
insert into t(a, b, c) select (x, y, z) from s
)
;
{noformat}
See, for instance,
https://www.ibm.com/support/knowledgecenter/en/SSEPEK_10.0.0/apsg/src/tpc/db2z_selectvaluesmerge.html
I think that there is a fair amount of language to build here in order to wire
this into Derby's access control language and trigger mechanism. However, the
solution is attractive. For best performance, we would want to push the
projection (keyCol in the example above) down into the so that the engine only collects the desired column (keyCol) as the
engine processes the insert.
Thanks,
-Rick
> Support Standard syntax for retrieving INSERTed key
> values
>
>
> Key: DERBY-6953
> URL: https://issues.apache.org/jira/browse/DERBY-6953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Lukas Eder
>
> The SQL standard supports an interesting syntax that can be used as a reference>:
> {code}
> ::=
>TABLE
> ::=
>
> |
> |
> |
> ::=
> FINAL
> | NEW
> | OLD
> {code}
> This is currently supported by DB2. Databases like Firebird, Oracle (in
> PL/SQL), PostgreSQL support an alternative syntax through the RETURNING
> keyword that can be appended to . SQL Server has an
> OUTPUT keyword that can be placed in the middle of a .
> These statements are incredibly useful to retrieve generated ID values but
> also trigger-generated values after a DML operation for an arbitrary number
> of inserted / updated / deleted / merged rows.
> It would allow people to bypass the many problems that are currently still
> open related to Statement.getGeneratedKeys(). Quite likely, if these clauses
> were made available, Statement.getGeneratedKeys() could be implemented by
> patching the user-defined SQL to be wrapped with a
> clause.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DERBY-6953) Support Standard syntax for retrieving INSERTed key values
[
https://issues.apache.org/jira/browse/DERBY-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6953:
-
Summary: Support Standard syntax for retrieving
INSERTed key values (was: Support the SQL Standard)
> Support Standard syntax for retrieving INSERTed key
> values
>
>
> Key: DERBY-6953
> URL: https://issues.apache.org/jira/browse/DERBY-6953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Lukas Eder
>
> The SQL standard supports an interesting syntax that can be used as a reference>:
> {code}
> ::=
>TABLE
> ::=
>
> |
> |
> |
> ::=
> FINAL
> | NEW
> | OLD
> {code}
> This is currently supported by DB2. Databases like Firebird, Oracle (in
> PL/SQL), PostgreSQL support an alternative syntax through the RETURNING
> keyword that can be appended to . SQL Server has an
> OUTPUT keyword that can be placed in the middle of a .
> These statements are incredibly useful to retrieve generated ID values but
> also trigger-generated values after a DML operation for an arbitrary number
> of inserted / updated / deleted / merged rows.
> It would allow people to bypass the many problems that are currently still
> open related to Statement.getGeneratedKeys(). Quite likely, if these clauses
> were made available, Statement.getGeneratedKeys() could be implemented by
> patching the user-defined SQL to be wrapped with a
> clause.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9
[ https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16097416#comment-16097416 ] Rick Hillegas commented on DERBY-6856: -- Using build 178 of JDK 9, Derby compiles cleanly, the javadoc generates cleanly, and the tests run cleanly. > Make it possible to build Derby using JDK 9 > --- > > Key: DERBY-6856 > URL: https://issues.apache.org/jira/browse/DERBY-6856 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.12.1.1 >Reporter: Rick Hillegas > Attachments: derby-6856-01-ab-addShardingKey.diff, > derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff, > derby-6856-03-aa-autoboxingDeprecationWarnings.diff, > derby-6856-03-ab-autoboxingDeprecationWarnings.diff, > derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff, > derby-6856-04-ab-autoboxingDeprecationWarnings-part2.diff, > derby-6856-05-ac-roundingMode-Class.newInstance.diff, > derby-6856-05-af-roundingMode-Class.getDeclaredConstructor.diff, > derby-6856-05-ag-roundingMode-Class.newInstance.diff, > derby-6856-06-aa-observable.diff, derby-6856-07-aa-oneMoreNewInstance.diff, > derby-6856-08-aa-cleanupJavadoc.diff, derby-6856-09-aa-javadocEntities.diff, > derby-6856-10-aa-disable-permissions-subverting-test.diff, > derby-6856-11-aa-jigsawResourceLocation.diff, derby-6856-XX-ab-base.diff, > derby-6856-XX-ac-base.diff, derby-6856-XX-ad-base.diff, > derby-6856-XX-ae-base.diff, PTest.java, ptestScript > > > Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like > java.sql.ShardingKey and methods which refer to these new classes. > In addition, project Jigsaw has created a new way to name classes (see > http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool > which we use so that old JVMs can compile Derby and so that Derby can be > compiled to run on old JVMs. > It is likely that we will need to leave this issue open throughout the > development cycle of Java 9. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6952) Regression on Statement.getGeneratedKeys() on UPDATE statements
[
https://issues.apache.org/jira/browse/DERBY-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095617#comment-16095617
]
Rick Hillegas commented on DERBY-6952:
--
I have linked this issue to DERBY-3609. Statement.getGeneratedKeys() is a mess.
> Regression on Statement.getGeneratedKeys() on UPDATE statements
> ---
>
> Key: DERBY-6952
> URL: https://issues.apache.org/jira/browse/DERBY-6952
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.13.1.1
>Reporter: Lukas Eder
>
> Consider this program:
> {code}
> import java.sql.Connection;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import java.util.Properties;
> import org.apache.derby.jdbc.EmbeddedDriver;
> public class Derby {
> public static void main(String[] args) throws Exception {
> try (Connection c1 = new
> EmbeddedDriver().connect("jdbc:derby:memory:test;create=true", new
> Properties());
> Statement s = c1.createStatement()) {
> s.execute(
> "CREATE TABLE test ("
> + "id INT PRIMARY KEY NOT NULL GENERATED ALWAYS AS
> IDENTITY,"
> + "val INT)");
> try {
> s.executeUpdate("INSERT INTO test (val) VALUES (1)");
> try (PreparedStatement p = c1.prepareStatement("UPDATE test
> SET val = 2 WHERE id = 1", Statement.RETURN_GENERATED_KEYS)) {
> p.executeUpdate();
> try (ResultSet rs = p.getGeneratedKeys()) {
> while (rs.next())
> System.out.println(rs.getString(1));
> }
> }
> }
> finally {
> s.execute("DROP TABLE test");
> }
> }
> }
> }
> {code}
> Running this with Derby version 10.12.1.1 yields
> 1
> With 10.13.1.1, it yields:
> 0
> I'm not sure if this is (supposed to be) working at all, but the change is
> certainly a bit confusing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (DERBY-6512) Cannot use java.util.Arrays.toString( byte[] b ) as a function.
[ https://issues.apache.org/jira/browse/DERBY-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas reassigned DERBY-6512: Assignee: Dinuka Kodithuwakku > Cannot use java.util.Arrays.toString( byte[] b ) as a function. > --- > > Key: DERBY-6512 > URL: https://issues.apache.org/jira/browse/DERBY-6512 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.11.1.1 >Reporter: Rick Hillegas >Assignee: Dinuka Kodithuwakku >Priority: Minor > > Trying to use this method as a function raises the following error, which > seems to be a defect in Derby's method resolution: > ERROR 42X73: Method resolution for signature java.util.Arrays.toString([B) > was ambiguous. (No single maximally specific method.) > I can create a separate static method in another class, which just forwards > to java.util.Arrays.toString(). Registering and invoking that method as a > toString() function works. > The following script shows this problem: > connect 'jdbc:derby:memory:db;create=true'; > create function mb( cells int... ) returns char( 5 ) for bit data > language java parameter style derby deterministic no sql > external name > 'org.apache.derbyTesting.functionTests.tests.lang.MergeStatementTest.makeByteArray'; > create function toString( byteArray char( 5 ) for bit data ) returns varchar( > 20 ) > language java parameter style java deterministic no sql > external name 'java.util.Arrays.toString'; > values( toString( mb( 1, 2, 3, 4, 5 ) ) ); -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6948) INSERT .. SELECT produces NULL for getGeneratedKeys()
[
https://issues.apache.org/jira/browse/DERBY-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077378#comment-16077378
]
Rick Hillegas commented on DERBY-6948:
--
If you are the only one inserting into that table, and you have just inserted N
rows, then the last N key values inserted could be calculated from the
increment step and the value returned by SYSCS_UTIL.SYSCS_PEEK_AT_IDENTITY():
http://db.apache.org/derby/docs/10.13/ref/rrefsyscspeekidentity.html. If
multiple users are inserting simultaneously, then this won't work. I don't know
of a better workaround.
> INSERT .. SELECT produces NULL for getGeneratedKeys()
> -
>
> Key: DERBY-6948
> URL: https://issues.apache.org/jira/browse/DERBY-6948
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.13.1.1
>Reporter: Lukas Eder
>
> The following code:
> {code}
> import java.sql.Connection;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import org.apache.derby.jdbc.EmbeddedDataSource;
> public class Derby {
> public static void main(String[] args) throws Exception {
> EmbeddedDataSource ds;
> ds = new EmbeddedDataSource();
> ds.setDatabaseName("memory:test;create=true");
> try (Connection con = ds.getConnection();
> Statement s = con.createStatement()) {
> s.execute(
> "CREATE TABLE test ("
> + "id INT PRIMARY KEY NOT NULL GENERATED ALWAYS AS IDENTITY,"
> + "name VARCHAR(255))");
> try (PreparedStatement ps = con.prepareStatement("insert into
> test (name) select 'a' from sysibm.sysdummy1",
> Statement.RETURN_GENERATED_KEYS)) {
> ps.executeUpdate();
> try (ResultSet rs = ps.getGeneratedKeys()) {
> while (rs.next())
> System.out.println("GEN_ID: " + rs.getObject(1));
> }
> }
> try (PreparedStatement ps = con.prepareStatement("insert into
> test (name) select 'a' from sysibm.sysdummy1",
> Statement.RETURN_GENERATED_KEYS)) {
> ps.executeUpdate();
> try (ResultSet rs = ps.getGeneratedKeys()) {
> while (rs.next())
> System.out.println("GEN_ID: " + rs.getObject(1));
> }
> }
> try (ResultSet rs = s.executeQuery("select id from test")) {
> while (rs.next())
> System.out.println("ID: " + rs.getObject(1));
> }
> }
> }
> }
> {code}
> Produces this output:
> {code}
> GEN_ID: null
> GEN_ID: null
> ID: 1
> ID: 2
> ID: 3
> {code}
> The expected output would be:
> {code}
> GEN_ID: 1
> GEN_ID: 2
> GEN_ID: 3
> ID: 1
> ID: 2
> ID: 3
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6948) INSERT .. SELECT produces NULL for getGeneratedKeys()
[
https://issues.apache.org/jira/browse/DERBY-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16075675#comment-16075675
]
Rick Hillegas commented on DERBY-6948:
--
I have linked this issue to DERBY-3609. This is another example of the fact
that Derby does not really support getGeneratedKeys(). In its defense, Derby
doesn't claim to. In fact the return value of
DatabaseMetaData.supportsGetGeneratedKeys() is false, as can be see by running
the following script:
{noformat}
connect 'jdbc:derby:memory:db;create=true';
call syscs_util.syscs_register_tool( 'databaseMetaData', true );
values supportsGetGeneratedKeys();
{noformat}
> INSERT .. SELECT produces NULL for getGeneratedKeys()
> -
>
> Key: DERBY-6948
> URL: https://issues.apache.org/jira/browse/DERBY-6948
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.13.1.1
>Reporter: Lukas Eder
>
> The following code:
> {code}
> import java.sql.Connection;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import org.apache.derby.jdbc.EmbeddedDataSource;
> public class Derby {
> public static void main(String[] args) throws Exception {
> EmbeddedDataSource ds;
> ds = new EmbeddedDataSource();
> ds.setDatabaseName("memory:test;create=true");
> try (Connection con = ds.getConnection();
> Statement s = con.createStatement()) {
> s.execute(
> "CREATE TABLE test ("
> + "id INT PRIMARY KEY NOT NULL GENERATED ALWAYS AS IDENTITY,"
> + "name VARCHAR(255))");
> try (PreparedStatement ps = con.prepareStatement("insert into
> test (name) select 'a' from sysibm.sysdummy1",
> Statement.RETURN_GENERATED_KEYS)) {
> ps.executeUpdate();
> try (ResultSet rs = ps.getGeneratedKeys()) {
> while (rs.next())
> System.out.println("GEN_ID: " + rs.getObject(1));
> }
> }
> try (PreparedStatement ps = con.prepareStatement("insert into
> test (name) select 'a' from sysibm.sysdummy1",
> Statement.RETURN_GENERATED_KEYS)) {
> ps.executeUpdate();
> try (ResultSet rs = ps.getGeneratedKeys()) {
> while (rs.next())
> System.out.println("GEN_ID: " + rs.getObject(1));
> }
> }
> try (ResultSet rs = s.executeQuery("select id from test")) {
> while (rs.next())
> System.out.println("ID: " + rs.getObject(1));
> }
> }
> }
> }
> {code}
> Produces this output:
> {code}
> GEN_ID: null
> GEN_ID: null
> ID: 1
> ID: 2
> ID: 3
> {code}
> The expected output would be:
> {code}
> GEN_ID: 1
> GEN_ID: 2
> GEN_ID: 3
> ID: 1
> ID: 2
> ID: 3
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DERBY-6944) tomcat, maven, derby jar file manifest, jar naming
[ https://issues.apache.org/jira/browse/DERBY-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074001#comment-16074001 ] Rick Hillegas commented on DERBY-6944: -- I suppose that a classpath in the engine jar supports the now discouraged use-case of running embedded Derby applets in browsers. Would Tomcat apps still somehow find the message localizations if the engine manifest dropped them from the classpath? If I correctly understand the reference material for the JarScanner element (https://tomcat.apache.org/tomcat-8.0-doc/config/jar-scanner.html), then it is scoped to a single application. So setting that extra flag for a Derby-powered app will not break other applications deployed in the same Tomcat instance. If your app can tolerate running without the message localizations (i.e., if English is good enough for your users), then that sounds like a decent workaround. Thanks for logging this issue. It will help inform our thinking about a jigsaw-ready Derby for Java 9. > tomcat, maven, derby jar file manifest, jar naming > -- > > Key: DERBY-6944 > URL: https://issues.apache.org/jira/browse/DERBY-6944 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.3.0, 10.13.1.1 >Reporter: Martin Sillence >Priority: Minor > > The main derby jar file has a manifest with a classpath entry e.g. > Class-Path: derbyLocale_cs.jar derbyLocale_de_DE.jar... > When using maven repository it downloads the files with the version numbers > in it: > derbyLocale_cs-10.5.3.0_1.jar > if deployed on a recent version of tomcat the manifest it automatically > interrogated and tomcat attempts to load the jar files as named. This fails > as the names do not match. > Also the additional files are not specified as dependencies in the derby > pom.xml file so they are not automatically retrieved. > Please would you consider adding in the dependencies to the published files > and putting in the version in the names in the manifest when publishing to > maven? > Workarounds: > fetch maven dependencies with "-Dmdep.stripVersion=true" > Turn off auto loading of manifest classpath for all files > add: > to tomcats context.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (DERBY-6395) SYSCS_UTIL.SYSCS_COMPRESS_TABLE message for not found table says: 'ALTER TABLE' cannot be performed
[
https://issues.apache.org/jira/browse/DERBY-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas reassigned DERBY-6395:
Assignee: Lashan Faliq
> SYSCS_UTIL.SYSCS_COMPRESS_TABLE message for not found table says: 'ALTER
> TABLE' cannot be performed
>
>
> Key: DERBY-6395
> URL: https://issues.apache.org/jira/browse/DERBY-6395
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Kathey Marsden
>Assignee: Lashan Faliq
>Priority: Trivial
>
> For historical reasons SYCSCS_UTIL.SYSCS_COMPRESS_TABLE gives a not very
> sensible message. The user did not actually execute an ALTER TABLE command.
> ij> CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP','NOTTHERE',1);
> ERROR 38000: The exception 'java.sql.SQLException: 'ALTER TABLE' cannot be
> performed on 'APP.NOTTHERE' because it does n
> ot exist.' was thrown while evaluating an expression.
> ERROR 42Y55: 'ALTER TABLE' cannot be performed on 'APP.NOTTHERE' because it
> does not exist.
> ij>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (DERBY-6931) ClientPreparedStatement doesn't support executeLargeBatch
[ https://issues.apache.org/jira/browse/DERBY-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas reassigned DERBY-6931: Assignee: Himasha De Silva > ClientPreparedStatement doesn't support executeLargeBatch > - > > Key: DERBY-6931 > URL: https://issues.apache.org/jira/browse/DERBY-6931 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client >Affects Versions: 10.11.1.1, 10.12.1.1, 10.13.1.1 >Reporter: Mark Swatosh >Assignee: Himasha De Silva > Attachments: Main.java > > > When trying to run executeLargeBatch on a PreparedStatement, the following > error is seen: > Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; > cannot be cast to java.lang.String > at > org.apache.derby.client.am.ClientStatement.flowExecuteBatch(ClientStatement.java:2460) > at > org.apache.derby.client.am.ClientStatement.executeBatchX(ClientStatement.java:1292) > at > org.apache.derby.client.am.ClientStatement.executeLargeBatch(ClientStatement.java:1269) > at com.test.Main.main(Main.java:22) > Upon further inspection, I found executeLargeBatch isn't implemented in > ClientPreparedStatement and it is using ClientStatement instead. It pulls in > the parameter for the PreparedStatement as a Statement, which is where the > ClassCastException occurs. I will attach a simple reproduction. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6944) tomcat, maven, derby jar file manifest, jar naming
[ https://issues.apache.org/jira/browse/DERBY-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071716#comment-16071716 ] Rick Hillegas commented on DERBY-6944: -- I have linked this issue to DERBY-6945. We will want to consider the Tomcat usage pattern when we re-factor Derby into jigsaw modules after Java 9 is released. > tomcat, maven, derby jar file manifest, jar naming > -- > > Key: DERBY-6944 > URL: https://issues.apache.org/jira/browse/DERBY-6944 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.3.0, 10.13.1.1 >Reporter: Martin Sillence >Priority: Minor > > The main derby jar file has a manifest with a classpath entry e.g. > Class-Path: derbyLocale_cs.jar derbyLocale_de_DE.jar... > When using maven repository it downloads the files with the version numbers > in it: > derbyLocale_cs-10.5.3.0_1.jar > if deployed on a recent version of tomcat the manifest it automatically > interrogated and tomcat attempts to load the jar files as named. This fails > as the names do not match. > Also the additional files are not specified as dependencies in the derby > pom.xml file so they are not automatically retrieved. > Please would you consider adding in the dependencies to the published files > and putting in the version in the names in the manifest when publishing to > maven? > Workarounds: > fetch maven dependencies with "-Dmdep.stripVersion=true" > Turn off auto loading of manifest classpath for all files > add: > to tomcats context.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DERBY-6945) Re-package Derby as a collection of jigsaw modules
Rick Hillegas created DERBY-6945: Summary: Re-package Derby as a collection of jigsaw modules Key: DERBY-6945 URL: https://issues.apache.org/jira/browse/DERBY-6945 Project: Derby Issue Type: Improvement Affects Versions: 10.13.1.2 Reporter: Rick Hillegas Once we commit to building with Java 9 (see DERBY-6856), we should consider re-packaging Derby as a set of jigsaw modules. This would result in a different set of release artifacts. This might be a good opportunity to address the Tomcat artifactory issues raised by issue DERBY-6944. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6944) tomcat, maven, derby jar file manifest, jar naming
[ https://issues.apache.org/jira/browse/DERBY-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071713#comment-16071713 ] Rick Hillegas commented on DERBY-6944: -- I see the argument for adding the localizations as dependencies of the engine jar. Note that they are conceived as optional files, that is, as add-ons, not as dependencies, and they are meant to be picked up on the classpath only if they are present. The whole pile of localizations weighs in at more than 1M. Resource-constrained devices would not welcome the extra weight. I can see that this conflicts with Tomcat's assumption that everything on the manifest classpath must be a required dependency of the jar file. > tomcat, maven, derby jar file manifest, jar naming > -- > > Key: DERBY-6944 > URL: https://issues.apache.org/jira/browse/DERBY-6944 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.3.0, 10.13.1.1 >Reporter: Martin Sillence >Priority: Minor > > The main derby jar file has a manifest with a classpath entry e.g. > Class-Path: derbyLocale_cs.jar derbyLocale_de_DE.jar... > When using maven repository it downloads the files with the version numbers > in it: > derbyLocale_cs-10.5.3.0_1.jar > if deployed on a recent version of tomcat the manifest it automatically > interrogated and tomcat attempts to load the jar files as named. This fails > as the names do not match. > Also the additional files are not specified as dependencies in the derby > pom.xml file so they are not automatically retrieved. > Please would you consider adding in the dependencies to the published files > and putting in the version in the names in the manifest when publishing to > maven? > Workarounds: > fetch maven dependencies with "-Dmdep.stripVersion=true" > Turn off auto loading of manifest classpath for all files > add: > to tomcats context.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6944) tomcat, maven, derby jar file manifest, jar naming
[ https://issues.apache.org/jira/browse/DERBY-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071708#comment-16071708 ] Rick Hillegas commented on DERBY-6944: -- Hey Bryan, Yes, I agree that this would widen the problem of jar file misconfiguration. > tomcat, maven, derby jar file manifest, jar naming > -- > > Key: DERBY-6944 > URL: https://issues.apache.org/jira/browse/DERBY-6944 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.3.0, 10.13.1.1 >Reporter: Martin Sillence >Priority: Minor > > The main derby jar file has a manifest with a classpath entry e.g. > Class-Path: derbyLocale_cs.jar derbyLocale_de_DE.jar... > When using maven repository it downloads the files with the version numbers > in it: > derbyLocale_cs-10.5.3.0_1.jar > if deployed on a recent version of tomcat the manifest it automatically > interrogated and tomcat attempts to load the jar files as named. This fails > as the names do not match. > Also the additional files are not specified as dependencies in the derby > pom.xml file so they are not automatically retrieved. > Please would you consider adding in the dependencies to the published files > and putting in the version in the names in the manifest when publishing to > maven? > Workarounds: > fetch maven dependencies with "-Dmdep.stripVersion=true" > Turn off auto loading of manifest classpath for all files > add: > to tomcats context.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-6944) tomcat, maven, derby jar file manifest, jar naming
[ https://issues.apache.org/jira/browse/DERBY-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16071705#comment-16071705 ] Rick Hillegas commented on DERBY-6944: -- I have re-read your comment. Simply adding more jar files to the front of the manifest classpath won't help you. The trailing jar files still won't be found and that will make tomcat grumble, if I understand your comment correctly. > tomcat, maven, derby jar file manifest, jar naming > -- > > Key: DERBY-6944 > URL: https://issues.apache.org/jira/browse/DERBY-6944 > Project: Derby > Issue Type: Improvement > Components: Localization >Affects Versions: 10.5.3.0, 10.13.1.1 >Reporter: Martin Sillence >Priority: Minor > > The main derby jar file has a manifest with a classpath entry e.g. > Class-Path: derbyLocale_cs.jar derbyLocale_de_DE.jar... > When using maven repository it downloads the files with the version numbers > in it: > derbyLocale_cs-10.5.3.0_1.jar > if deployed on a recent version of tomcat the manifest it automatically > interrogated and tomcat attempts to load the jar files as named. This fails > as the names do not match. > Also the additional files are not specified as dependencies in the derby > pom.xml file so they are not automatically retrieved. > Please would you consider adding in the dependencies to the published files > and putting in the version in the names in the manifest when publishing to > maven? > Workarounds: > fetch maven dependencies with "-Dmdep.stripVersion=true" > Turn off auto loading of manifest classpath for all files > add: > to tomcats context.xml -- This message was sent by Atlassian JIRA (v6.4.14#64029)
