[jira] [Commented] (DERBY-7054) Website references old email address
[ https://issues.apache.org/jira/browse/DERBY-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16937238#comment-16937238 ] Rick Hillegas commented on DERBY-7054: -- Thanks for spotting that. Who fields requests for logo usage these days? We can update the page with that replacement contact point or we can just remove the offending paragraph. > Website references old email address > > > Key: DERBY-7054 > URL: https://issues.apache.org/jira/browse/DERBY-7054 > Project: Derby > Issue Type: Bug > Components: Web Site >Reporter: Sebb >Priority: Major > > The page https://db.apache.org/derby/logo.html references the prc@ mailing > list which was closed down many years ago (Mar 2010?). > Please update as necessary/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DERBY-7053) Further top build.xml streamlining
[
https://issues.apache.org/jira/browse/DERBY-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16927086#comment-16927086
]
Rick Hillegas commented on DERBY-7053:
--
Attaching derby-7053-01-aa-minorChanges.diff. This patch makes minor changes to
Davide Grandi's original patch:
1) Eliminates an empty target which had no purpose other than to depend on the
real workhorse target.
2) Empty files have been svn deleted.
With this patch, Derby builds cleanly and passes the tests both with the
classpath and with the modulepath. In addition, I have verified that the master
release target builds release distributions as expected.
Touches the following files:
{noformat}
M build.xml
D java/build/build.xml
D java/build/org/apache/derbyBuild/build.xml
D java/build/org/apache/derbyPreBuild/build.xml
D java/org.apache.derby.client/build.xml
D java/org.apache.derby.commons/build.xml
D java/org.apache.derby.engine/build.xml
D java/org.apache.derby.engine/org/apache/derby/loc/build.xml
D java/org.apache.derby.optionaltools/build.xml
D java/org.apache.derby.runner/build.xml
D java/org.apache.derby.server/build.xml
D java/org.apache.derby.tools/build.xml
D java/storeless/build.xml
{noformat}
> Further top build.xml streamlining
> --
>
> Key: DERBY-7053
> URL: https://issues.apache.org/jira/browse/DERBY-7053
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Davide Grandi
>Priority: Minor
> Labels: build, patch
> Attachments: Explanation.txt, build-0.dot, build-0.pdf, build-0.xml,
> build-22.dot, build-22.pdf, build-22.xml, derby-7053-01-aa-minorChanges.diff,
> svn.diff
>
>
> Considering the (all => init) and (buildjars => init) targets flow I've
> expanded all the and nearly all tasks.
> This required the expansion and deleting of 12 secondary build files, and the
> conversion of some antcall-ed targets in ant macros (keeping the names).
> In every step I've checked build result and binary compares with initial
> build file.
> I've attached :
> * original build-0.xml, *.dot version and *.pdf rendered with graphviz
> * final build-22.xml, *.dot, and *.pdf
> * a step by step (boring) Explanation.txt
> * svn.diff patch
> Nearly all targets are buildable without error, being dependent with their
> real dependencies.
> What's missing : normalization of init-sane and locales-split-dosplit groups.
> Best regards, Davide Grandi
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (DERBY-7053) Further top build.xml streamlining
[ https://issues.apache.org/jira/browse/DERBY-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7053: - Attachment: derby-7053-01-aa-minorChanges.diff > Further top build.xml streamlining > -- > > Key: DERBY-7053 > URL: https://issues.apache.org/jira/browse/DERBY-7053 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.15.1.3 >Reporter: Davide Grandi >Priority: Minor > Labels: build, patch > Attachments: Explanation.txt, build-0.dot, build-0.pdf, build-0.xml, > build-22.dot, build-22.pdf, build-22.xml, derby-7053-01-aa-minorChanges.diff, > svn.diff > > > Considering the (all => init) and (buildjars => init) targets flow I've > expanded all the and nearly all tasks. > This required the expansion and deleting of 12 secondary build files, and the > conversion of some antcall-ed targets in ant macros (keeping the names). > In every step I've checked build result and binary compares with initial > build file. > I've attached : > * original build-0.xml, *.dot version and *.pdf rendered with graphviz > * final build-22.xml, *.dot, and *.pdf > * a step by step (boring) Explanation.txt > * svn.diff patch > Nearly all targets are buildable without error, being dependent with their > real dependencies. > What's missing : normalization of init-sane and locales-split-dosplit groups. > Best regards, Davide Grandi -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (DERBY-7053) Further top build.xml streamlining
[ https://issues.apache.org/jira/browse/DERBY-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926622#comment-16926622 ] Rick Hillegas commented on DERBY-7053: -- I ran the top level release target in debug mode (setting -Ddebug.release.build=true). The correct artifacts were built. I believe that this patch does NOT disturb the release process. > Further top build.xml streamlining > -- > > Key: DERBY-7053 > URL: https://issues.apache.org/jira/browse/DERBY-7053 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.15.1.3 >Reporter: Davide Grandi >Priority: Minor > Labels: build, patch > Attachments: Explanation.txt, build-0.dot, build-0.pdf, build-0.xml, > build-22.dot, build-22.pdf, build-22.xml, svn.diff > > > Considering the (all => init) and (buildjars => init) targets flow I've > expanded all the and nearly all tasks. > This required the expansion and deleting of 12 secondary build files, and the > conversion of some antcall-ed targets in ant macros (keeping the names). > In every step I've checked build result and binary compares with initial > build file. > I've attached : > * original build-0.xml, *.dot version and *.pdf rendered with graphviz > * final build-22.xml, *.dot, and *.pdf > * a step by step (boring) Explanation.txt > * svn.diff patch > Nearly all targets are buildable without error, being dependent with their > real dependencies. > What's missing : normalization of init-sane and locales-split-dosplit groups. > Best regards, Davide Grandi -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (DERBY-7053) Further top build.xml streamlining
[ https://issues.apache.org/jira/browse/DERBY-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925663#comment-16925663 ] Rick Hillegas commented on DERBY-7053: -- I have applied the patch (with some small changes) and built the jar files. Tests ran cleanly for me with a classpath and with a modulepath. Next, I will verify the correct operation of the release targets. > Further top build.xml streamlining > -- > > Key: DERBY-7053 > URL: https://issues.apache.org/jira/browse/DERBY-7053 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.15.1.3 >Reporter: Davide Grandi >Priority: Minor > Labels: build, patch > Attachments: Explanation.txt, build-0.dot, build-0.pdf, build-0.xml, > build-22.dot, build-22.pdf, build-22.xml, svn.diff > > > Considering the (all => init) and (buildjars => init) targets flow I've > expanded all the and nearly all tasks. > This required the expansion and deleting of 12 secondary build files, and the > conversion of some antcall-ed targets in ant macros (keeping the names). > In every step I've checked build result and binary compares with initial > build file. > I've attached : > * original build-0.xml, *.dot version and *.pdf rendered with graphviz > * final build-22.xml, *.dot, and *.pdf > * a step by step (boring) Explanation.txt > * svn.diff patch > Nearly all targets are buildable without error, being dependent with their > real dependencies. > What's missing : normalization of init-sane and locales-split-dosplit groups. > Best regards, Davide Grandi -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (DERBY-7053) Further top build.xml streamlining
[ https://issues.apache.org/jira/browse/DERBY-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16923430#comment-16923430 ] Rick Hillegas commented on DERBY-7053: -- Thanks for the patch and explanation, Davide. This looks like useful cleanup. It will take me a while to study the patch. > Further top build.xml streamlining > -- > > Key: DERBY-7053 > URL: https://issues.apache.org/jira/browse/DERBY-7053 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.15.1.3 >Reporter: Davide Grandi >Priority: Minor > Labels: build, patch > Attachments: Explanation.txt, build-0.dot, build-0.pdf, build-0.xml, > build-22.dot, build-22.pdf, build-22.xml, svn.diff > > > Considering the (all => init) and (buildjars => init) targets flow I've > expanded all the and nearly all tasks. > This required the expansion and deleting of 12 secondary build files, and the > conversion of some antcall-ed targets in ant macros (keeping the names). > In every step I've checked build result and binary compares with initial > build file. > I've attached : > * original build-0.xml, *.dot version and *.pdf rendered with graphviz > * final build-22.xml, *.dot, and *.pdf > * a step by step (boring) Explanation.txt > * svn.diff patch > Nearly all targets are buildable without error, being dependent with their > real dependencies. > What's missing : normalization of init-sane and locales-split-dosplit groups. > Best regards, Davide Grandi -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (DERBY-7052) Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
[
https://issues.apache.org/jira/browse/DERBY-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16911328#comment-16911328
]
Rick Hillegas commented on DERBY-7052:
--
Closing this issue. Thanks again for the patch, Davide.
> Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
> -
>
> Key: DERBY-7052
> URL: https://issues.apache.org/jira/browse/DERBY-7052
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Davide Grandi
>Priority: Minor
> Fix For: 10.16.0.0
>
> Attachments: build-11.buildsource-expanded.pdf,
> build-11.buildsource.pdf, build-11.xml, build-11.xml.pdf,
> bu...@1863766.buildsource-expanded.pdf, bu...@1863766.buildsource.pdf,
> bu...@1863766.xml, bu...@1863766.xml.pdf, dot.zip, intermediate.zip, patch.txt
>
>
> Module dependencies should be reflected by Ant targets dependencies.
> And Ant targets execution follows the rules stated in
> [https://ant.apache.org/manual/targets.html]
> so a dependency could be covered (being redundant) by applying transitivity
> rule
> to every dependency's dependecies (please look at the dot+pdf diagrams).
>
>
> Modules dependencies, by the docs, are :
> ||module depends||on||
> |org.apache.derby.client|org.apache.derby.commons|
> |org.apache.derby.engine|org.apache.derby.commons|
> |org.apache.derby.locale_*|org.apache.derby.commons|
> | | |
> |org.apache.derby.tools|org.apache.derby.client|
> |org.apache.derby.tools|org.apache.derby.engine|
> | | |
> |org.apache.derby.optionaltools|org.apache.derby.tools|
> | | |
> |org.apache.derby.server|org.apache.derby.tools|
> | | |
> |org.apache.derby.runner|org.apache.derby.server|
> | | |
> |org.apache.derby.engine|org.osgi.framework|
> but actual ant dependencies are (partial target => module map) :
>
> ||target||depends||and module||depends on||
> |buildsource|client| | |
> |buildsource|shared| | |
> |buildsource|felixStubs| |org.osgi.framework|
> |engine|shared|org.apache.derby.engine|org.apache.derby.commons|
> |client|shared|org.apache.derby.client|org.apache.derby.commons|
> |tools|engine|org.apache.derby.tools|org.apache.derby.engine|
> |drda|engine| | |
> |runner|optional| | |
> |optional|engine| | |
> so we expect that building 'engine' target alone will fails due to the lack of
> 'felixstubs' dependency.
> And it fails ("01 ant engine.log") quoting "requires static
> org.osgi.framework;"
> So the best try is to delete (on copy "build-01.xml" of "build.xml") the
> dependency
> buildsource => felixstubs
> and to put it as last dependency of 'engine' target
> Result : success ("02 ant -f build-01.xml engine.txt")
> Similarly we can expect that also 'tools' fails, since it really depends on
> 'client' but this is not explicited in "build.xml".
> And it fails ("03 ant -f build-01.xml tools.log") with:
> [javac] requires static org.apache.derby.client;
> So the best try is to switch the 'client' dependency (in copy "build-02.xml"
> of
> "build-01.xml") from 'buildsource' to 'tools'.
> Result: success ("04 ant -f build-02.xml tools.log").
> The same thing for 'optional' that should depends on 'tools' but depends only
> on
> 'engine'.
> And it fails ("05 ant -f build-02.xml optional.log") with
> [javac] requires org.apache.derby.tools;
> So we switch the 'tools' dependency from 'buildsource' to 'optional' (in copy
> "build-03.xml" of "build.02.xml")
> And it succeeds ("06 ant -f build-03.xml optional.log").
> Same as 'drda' (aka server) that require 'tools' ("07 ant -f build-03.xml
> drda.log")
> [javac] requires org.apache.derby.tools;
> that succeds after adding 'tools' dependency to 'drda'
> ("08 ant -f build-04.xml drda.log")
> and also for 'runner' ("09 ant -f build-04.xml runner.log") that requires
> 'drda'
> [javac] requires org.apache.derby.server;
> and succeeds after adding it into copy "build-05.xml" of "build-04.xml".
> ("10 ant -f build-05.xml runner.log")
> After graphing "build-05.xml" (in "build-05.xml.pdf") one can notice that,
> apart from redundant prerequisites (covered later), there's an extra
> dependency
> on 'runner', that in module hierararchy needs only 'drda'.
> After duplicating "build-05.xml" in "build-06.xml" and edited, removing
> 'runner' -> 'optional' prerequisite, build of 'runner' succeeds
> ("11 ant -f build-06.xml runner.log")
> The next step is removing all the extra dependencies.
> Given the transitivity of dependencies in this set
> A => C (a depends on C)
> A => B (a depends on B)
> B => C (B depends on C)
> the first dependendency is already covered by second
[jira] [Closed] (DERBY-7052) Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
[
https://issues.apache.org/jira/browse/DERBY-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas closed DERBY-7052.
Fix Version/s: 10.16.0.0
Resolution: Fixed
> Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
> -
>
> Key: DERBY-7052
> URL: https://issues.apache.org/jira/browse/DERBY-7052
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Davide Grandi
>Priority: Minor
> Fix For: 10.16.0.0
>
> Attachments: build-11.buildsource-expanded.pdf,
> build-11.buildsource.pdf, build-11.xml, build-11.xml.pdf,
> bu...@1863766.buildsource-expanded.pdf, bu...@1863766.buildsource.pdf,
> bu...@1863766.xml, bu...@1863766.xml.pdf, dot.zip, intermediate.zip, patch.txt
>
>
> Module dependencies should be reflected by Ant targets dependencies.
> And Ant targets execution follows the rules stated in
> [https://ant.apache.org/manual/targets.html]
> so a dependency could be covered (being redundant) by applying transitivity
> rule
> to every dependency's dependecies (please look at the dot+pdf diagrams).
>
>
> Modules dependencies, by the docs, are :
> ||module depends||on||
> |org.apache.derby.client|org.apache.derby.commons|
> |org.apache.derby.engine|org.apache.derby.commons|
> |org.apache.derby.locale_*|org.apache.derby.commons|
> | | |
> |org.apache.derby.tools|org.apache.derby.client|
> |org.apache.derby.tools|org.apache.derby.engine|
> | | |
> |org.apache.derby.optionaltools|org.apache.derby.tools|
> | | |
> |org.apache.derby.server|org.apache.derby.tools|
> | | |
> |org.apache.derby.runner|org.apache.derby.server|
> | | |
> |org.apache.derby.engine|org.osgi.framework|
> but actual ant dependencies are (partial target => module map) :
>
> ||target||depends||and module||depends on||
> |buildsource|client| | |
> |buildsource|shared| | |
> |buildsource|felixStubs| |org.osgi.framework|
> |engine|shared|org.apache.derby.engine|org.apache.derby.commons|
> |client|shared|org.apache.derby.client|org.apache.derby.commons|
> |tools|engine|org.apache.derby.tools|org.apache.derby.engine|
> |drda|engine| | |
> |runner|optional| | |
> |optional|engine| | |
> so we expect that building 'engine' target alone will fails due to the lack of
> 'felixstubs' dependency.
> And it fails ("01 ant engine.log") quoting "requires static
> org.osgi.framework;"
> So the best try is to delete (on copy "build-01.xml" of "build.xml") the
> dependency
> buildsource => felixstubs
> and to put it as last dependency of 'engine' target
> Result : success ("02 ant -f build-01.xml engine.txt")
> Similarly we can expect that also 'tools' fails, since it really depends on
> 'client' but this is not explicited in "build.xml".
> And it fails ("03 ant -f build-01.xml tools.log") with:
> [javac] requires static org.apache.derby.client;
> So the best try is to switch the 'client' dependency (in copy "build-02.xml"
> of
> "build-01.xml") from 'buildsource' to 'tools'.
> Result: success ("04 ant -f build-02.xml tools.log").
> The same thing for 'optional' that should depends on 'tools' but depends only
> on
> 'engine'.
> And it fails ("05 ant -f build-02.xml optional.log") with
> [javac] requires org.apache.derby.tools;
> So we switch the 'tools' dependency from 'buildsource' to 'optional' (in copy
> "build-03.xml" of "build.02.xml")
> And it succeeds ("06 ant -f build-03.xml optional.log").
> Same as 'drda' (aka server) that require 'tools' ("07 ant -f build-03.xml
> drda.log")
> [javac] requires org.apache.derby.tools;
> that succeds after adding 'tools' dependency to 'drda'
> ("08 ant -f build-04.xml drda.log")
> and also for 'runner' ("09 ant -f build-04.xml runner.log") that requires
> 'drda'
> [javac] requires org.apache.derby.server;
> and succeeds after adding it into copy "build-05.xml" of "build-04.xml".
> ("10 ant -f build-05.xml runner.log")
> After graphing "build-05.xml" (in "build-05.xml.pdf") one can notice that,
> apart from redundant prerequisites (covered later), there's an extra
> dependency
> on 'runner', that in module hierararchy needs only 'drda'.
> After duplicating "build-05.xml" in "build-06.xml" and edited, removing
> 'runner' -> 'optional' prerequisite, build of 'runner' succeeds
> ("11 ant -f build-06.xml runner.log")
> The next step is removing all the extra dependencies.
> Given the transitivity of dependencies in this set
> A => C (a depends on C)
> A => B (a depends on B)
> B => C (B depends on C)
> the first dependendency is already covered by second and third one, and ant
> will ignore it.
> After graphing "b
[jira] [Commented] (DERBY-7052) Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
[
https://issues.apache.org/jira/browse/DERBY-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16910082#comment-16910082
]
Rick Hillegas commented on DERBY-7052:
--
With both the classpath and the module path, the tests passed cleanly for me
with the patch applied (modulo the environmental errors I see at this location).
> Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
> -
>
> Key: DERBY-7052
> URL: https://issues.apache.org/jira/browse/DERBY-7052
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Davide Grandi
>Priority: Minor
> Attachments: build-11.buildsource-expanded.pdf,
> build-11.buildsource.pdf, build-11.xml, build-11.xml.pdf,
> bu...@1863766.buildsource-expanded.pdf, bu...@1863766.buildsource.pdf,
> bu...@1863766.xml, bu...@1863766.xml.pdf, dot.zip, intermediate.zip, patch.txt
>
>
> Module dependencies should be reflected by Ant targets dependencies.
> And Ant targets execution follows the rules stated in
> [https://ant.apache.org/manual/targets.html]
> so a dependency could be covered (being redundant) by applying transitivity
> rule
> to every dependency's dependecies (please look at the dot+pdf diagrams).
>
>
> Modules dependencies, by the docs, are :
> ||module depends||on||
> |org.apache.derby.client|org.apache.derby.commons|
> |org.apache.derby.engine|org.apache.derby.commons|
> |org.apache.derby.locale_*|org.apache.derby.commons|
> | | |
> |org.apache.derby.tools|org.apache.derby.client|
> |org.apache.derby.tools|org.apache.derby.engine|
> | | |
> |org.apache.derby.optionaltools|org.apache.derby.tools|
> | | |
> |org.apache.derby.server|org.apache.derby.tools|
> | | |
> |org.apache.derby.runner|org.apache.derby.server|
> | | |
> |org.apache.derby.engine|org.osgi.framework|
> but actual ant dependencies are (partial target => module map) :
>
> ||target||depends||and module||depends on||
> |buildsource|client| | |
> |buildsource|shared| | |
> |buildsource|felixStubs| |org.osgi.framework|
> |engine|shared|org.apache.derby.engine|org.apache.derby.commons|
> |client|shared|org.apache.derby.client|org.apache.derby.commons|
> |tools|engine|org.apache.derby.tools|org.apache.derby.engine|
> |drda|engine| | |
> |runner|optional| | |
> |optional|engine| | |
> so we expect that building 'engine' target alone will fails due to the lack of
> 'felixstubs' dependency.
> And it fails ("01 ant engine.log") quoting "requires static
> org.osgi.framework;"
> So the best try is to delete (on copy "build-01.xml" of "build.xml") the
> dependency
> buildsource => felixstubs
> and to put it as last dependency of 'engine' target
> Result : success ("02 ant -f build-01.xml engine.txt")
> Similarly we can expect that also 'tools' fails, since it really depends on
> 'client' but this is not explicited in "build.xml".
> And it fails ("03 ant -f build-01.xml tools.log") with:
> [javac] requires static org.apache.derby.client;
> So the best try is to switch the 'client' dependency (in copy "build-02.xml"
> of
> "build-01.xml") from 'buildsource' to 'tools'.
> Result: success ("04 ant -f build-02.xml tools.log").
> The same thing for 'optional' that should depends on 'tools' but depends only
> on
> 'engine'.
> And it fails ("05 ant -f build-02.xml optional.log") with
> [javac] requires org.apache.derby.tools;
> So we switch the 'tools' dependency from 'buildsource' to 'optional' (in copy
> "build-03.xml" of "build.02.xml")
> And it succeeds ("06 ant -f build-03.xml optional.log").
> Same as 'drda' (aka server) that require 'tools' ("07 ant -f build-03.xml
> drda.log")
> [javac] requires org.apache.derby.tools;
> that succeds after adding 'tools' dependency to 'drda'
> ("08 ant -f build-04.xml drda.log")
> and also for 'runner' ("09 ant -f build-04.xml runner.log") that requires
> 'drda'
> [javac] requires org.apache.derby.server;
> and succeeds after adding it into copy "build-05.xml" of "build-04.xml".
> ("10 ant -f build-05.xml runner.log")
> After graphing "build-05.xml" (in "build-05.xml.pdf") one can notice that,
> apart from redundant prerequisites (covered later), there's an extra
> dependency
> on 'runner', that in module hierararchy needs only 'drda'.
> After duplicating "build-05.xml" in "build-06.xml" and edited, removing
> 'runner' -> 'optional' prerequisite, build of 'runner' succeeds
> ("11 ant -f build-06.xml runner.log")
> The next step is removing all the extra dependencies.
> Given the transitivity of dependencies in this set
> A => C (a depends on C)
> A => B (a depends on B)
> B => C (B d
[jira] [Commented] (DERBY-7052) Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
[
https://issues.apache.org/jira/browse/DERBY-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909997#comment-16909997
]
Rick Hillegas commented on DERBY-7052:
--
Thanks for this comprehensive analysis, Davide. I think that this is a welcome
cleanup.
I have applied your patch and verified clean builds when invoking the targets
you modified. Now I have done a full build. I will run full tests both with the
classpath and the modulepath.
> Reordering and (mildly) reorganizing build.xml Ant targets around buildsource
> -
>
> Key: DERBY-7052
> URL: https://issues.apache.org/jira/browse/DERBY-7052
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Davide Grandi
>Priority: Minor
> Attachments: build-11.buildsource-expanded.pdf,
> build-11.buildsource.pdf, build-11.xml, build-11.xml.pdf,
> bu...@1863766.buildsource-expanded.pdf, bu...@1863766.buildsource.pdf,
> bu...@1863766.xml, bu...@1863766.xml.pdf, dot.zip, intermediate.zip, patch.txt
>
>
> Module dependencies should be reflected by Ant targets dependencies.
> And Ant targets execution follows the rules stated in
> [https://ant.apache.org/manual/targets.html]
> so a dependency could be covered (being redundant) by applying transitivity
> rule
> to every dependency's dependecies (please look at the dot+pdf diagrams).
>
>
> Modules dependencies, by the docs, are :
> ||module depends||on||
> |org.apache.derby.client|org.apache.derby.commons|
> |org.apache.derby.engine|org.apache.derby.commons|
> |org.apache.derby.locale_*|org.apache.derby.commons|
> | | |
> |org.apache.derby.tools|org.apache.derby.client|
> |org.apache.derby.tools|org.apache.derby.engine|
> | | |
> |org.apache.derby.optionaltools|org.apache.derby.tools|
> | | |
> |org.apache.derby.server|org.apache.derby.tools|
> | | |
> |org.apache.derby.runner|org.apache.derby.server|
> | | |
> |org.apache.derby.engine|org.osgi.framework|
> but actual ant dependencies are (partial target => module map) :
>
> ||target||depends||and module||depends on||
> |buildsource|client| | |
> |buildsource|shared| | |
> |buildsource|felixStubs| |org.osgi.framework|
> |engine|shared|org.apache.derby.engine|org.apache.derby.commons|
> |client|shared|org.apache.derby.client|org.apache.derby.commons|
> |tools|engine|org.apache.derby.tools|org.apache.derby.engine|
> |drda|engine| | |
> |runner|optional| | |
> |optional|engine| | |
> so we expect that building 'engine' target alone will fails due to the lack of
> 'felixstubs' dependency.
> And it fails ("01 ant engine.log") quoting "requires static
> org.osgi.framework;"
> So the best try is to delete (on copy "build-01.xml" of "build.xml") the
> dependency
> buildsource => felixstubs
> and to put it as last dependency of 'engine' target
> Result : success ("02 ant -f build-01.xml engine.txt")
> Similarly we can expect that also 'tools' fails, since it really depends on
> 'client' but this is not explicited in "build.xml".
> And it fails ("03 ant -f build-01.xml tools.log") with:
> [javac] requires static org.apache.derby.client;
> So the best try is to switch the 'client' dependency (in copy "build-02.xml"
> of
> "build-01.xml") from 'buildsource' to 'tools'.
> Result: success ("04 ant -f build-02.xml tools.log").
> The same thing for 'optional' that should depends on 'tools' but depends only
> on
> 'engine'.
> And it fails ("05 ant -f build-02.xml optional.log") with
> [javac] requires org.apache.derby.tools;
> So we switch the 'tools' dependency from 'buildsource' to 'optional' (in copy
> "build-03.xml" of "build.02.xml")
> And it succeeds ("06 ant -f build-03.xml optional.log").
> Same as 'drda' (aka server) that require 'tools' ("07 ant -f build-03.xml
> drda.log")
> [javac] requires org.apache.derby.tools;
> that succeds after adding 'tools' dependency to 'drda'
> ("08 ant -f build-04.xml drda.log")
> and also for 'runner' ("09 ant -f build-04.xml runner.log") that requires
> 'drda'
> [javac] requires org.apache.derby.server;
> and succeeds after adding it into copy "build-05.xml" of "build-04.xml".
> ("10 ant -f build-05.xml runner.log")
> After graphing "build-05.xml" (in "build-05.xml.pdf") one can notice that,
> apart from redundant prerequisites (covered later), there's an extra
> dependency
> on 'runner', that in module hierararchy needs only 'drda'.
> After duplicating "build-05.xml" in "build-06.xml" and edited, removing
> 'runner' -> 'optional' prerequisite, build of 'runner' succeeds
> ("11 ant -f build-06.xml runner.log")
> The next step is removing all the extra dependencies.
[jira] [Commented] (DERBY-7051) Multiple DISTINCT columns are not supported
[
https://issues.apache.org/jira/browse/DERBY-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908059#comment-16908059
]
Rick Hillegas commented on DERBY-7051:
--
Glad to hear it! Closing this issue.
> Multiple DISTINCT columns are not supported
> ---
>
> Key: DERBY-7051
> URL: https://issues.apache.org/jira/browse/DERBY-7051
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Environment: derby-10.11.1.1;
>Reporter: JackLi0812
>Priority: Major
> Fix For: 10.16.0.0
>
>
>
> {code:java}
> SELECT DISTINCT (ORDERS.CUSTOMER_ID), DISTINCT (ORDERS.ORDER_ID)
> FROM ORDERS
> ORDER BY ORDERS.ORDER_ID
> ;{code}
> throw error:
> {code:java}
> SQL Error [42X01]: Syntax error: Encountered "DISTINCT" at line 1, column 39.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (DERBY-7051) Multiple DISTINCT columns are not supported
[
https://issues.apache.org/jira/browse/DERBY-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas closed DERBY-7051.
Resolution: Not A Bug
Fix Version/s: 10.16.0.0
> Multiple DISTINCT columns are not supported
> ---
>
> Key: DERBY-7051
> URL: https://issues.apache.org/jira/browse/DERBY-7051
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Environment: derby-10.11.1.1;
>Reporter: JackLi0812
>Priority: Major
> Fix For: 10.16.0.0
>
>
>
> {code:java}
> SELECT DISTINCT (ORDERS.CUSTOMER_ID), DISTINCT (ORDERS.ORDER_ID)
> FROM ORDERS
> ORDER BY ORDERS.ORDER_ID
> ;{code}
> throw error:
> {code:java}
> SQL Error [42X01]: Syntax error: Encountered "DISTINCT" at line 1, column 39.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-7051) Multiple DISTINCT columns are not supported
[
https://issues.apache.org/jira/browse/DERBY-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16907241#comment-16907241
]
Rick Hillegas commented on DERBY-7051:
--
Try this:
{noformat}
connect 'jdbc:derby:memory:db;create=true';
CREATE TABLE t(userName VARCHAR(50), product VARCHAR(50));
SELECT
(SELECT DISTINCT userName FROM t) userCount,
(SELECT DISTINCT product FROM t) productCount
FROM sysibm.sysdummy1;
{noformat}
> Multiple DISTINCT columns are not supported
> ---
>
> Key: DERBY-7051
> URL: https://issues.apache.org/jira/browse/DERBY-7051
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Environment: derby-10.11.1.1;
>Reporter: JackLi0812
>Priority: Major
>
>
> {code:java}
> SELECT DISTINCT (ORDERS.CUSTOMER_ID), DISTINCT (ORDERS.ORDER_ID)
> FROM ORDERS
> ORDER BY ORDERS.ORDER_ID
> ;{code}
> throw error:
> {code:java}
> SQL Error [42X01]: Syntax error: Encountered "DISTINCT" at line 1, column 39.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-7051) Multiple DISTINCT columns are not supported
[
https://issues.apache.org/jira/browse/DERBY-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906793#comment-16906793
]
Rick Hillegas commented on DERBY-7051:
--
Try this:
{noformat}
connect 'jdbc:derby:memory:db;create=true';
CREATE TABLE t(userName VARCHAR(50), product VARCHAR(50));
VALUES
(
(SELECT DISTINCT userName FROM t),
(SELECT DISTINCT product FROM t)
)
;
{noformat}
> Multiple DISTINCT columns are not supported
> ---
>
> Key: DERBY-7051
> URL: https://issues.apache.org/jira/browse/DERBY-7051
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Environment: derby-10.11.1.1;
>Reporter: JackLi0812
>Priority: Major
>
>
> {code:java}
> SELECT DISTINCT (ORDERS.CUSTOMER_ID), DISTINCT (ORDERS.ORDER_ID)
> FROM ORDERS
> ORDER BY ORDERS.ORDER_ID
> ;{code}
> throw error:
> {code:java}
> SQL Error [42X01]: Syntax error: Encountered "DISTINCT" at line 1, column 39.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-7051) Multiple DISTINCT columns are not supported
[
https://issues.apache.org/jira/browse/DERBY-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906182#comment-16906182
]
Rick Hillegas commented on DERBY-7051:
--
That is non-Standard syntax. The (DISTINCT) must appear before
the entire according to the 2016 SQL Standard, part 2, subclause
7.16 (). You cannot use the DISTINCT quantifier to
decorate individual items in the .
I'm not sure what you are trying to achieve with that query. Maybe the
following workaround will help:
{noformat}
connect 'jdbc:derby:memory:db;create=true';
CREATE TABLE orders (customerID BIGINT, orderID BIGINT);
-- illegal syntax
SELECT DISTINCT(customerID), DISTINCT(orderID) FROM orders;
-- works
SELECT DISTINCT customerID, orderID FROM orders;
{noformat}
> Multiple DISTINCT columns are not supported
> ---
>
> Key: DERBY-7051
> URL: https://issues.apache.org/jira/browse/DERBY-7051
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Environment: derby-10.11.1.1;
>Reporter: JackLi0812
>Priority: Major
>
>
> {code:java}
> SELECT DISTINCT (ORDERS.CUSTOMER_ID), DISTINCT (ORDERS.ORDER_ID)
> FROM ORDERS
> ORDER BY ORDERS.ORDER_ID
> ;{code}
> throw error:
> {code:java}
> SQL Error [42X01]: Syntax error: Encountered "DISTINCT" at line 1, column 39.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904684#comment-16904684
]
Rick Hillegas commented on DERBY-7049:
--
Glad to hear that you have been able to push this problem forward.
The statement cache is per-database and it is shared across all sessions in
that database.
The default size of the statement cache is 100 statements. You can configure
this via the derby.language.statementCacheSize property. See
http://db.apache.org/derby/docs/10.15/ref/rrefproperstatementcachesize.html and
http://db.apache.org/derby/docs/10.15/tuning/ctundepth29804.html.
You may have some other leak. See Bryan's advice above for further advice about
that.
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
> Attachments: StatementLogReadingVTI.java
>
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of each transaction? But
> even if I really have to shut-down the DB, it is certainly a bug that the
> classes are still kept in "compressed class space" even after the shut-down.
> I searched the release notes and the existing bugs
[jira] [Comment Edited] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894479#comment-16894479
]
Rick Hillegas edited comment on DERBY-7049 at 7/27/19 3:30 PM:
---
Integer.MAX_VALUE is the maximum number of ? parameters which a JDBC
PreparedStatement can take. I don't think that Derby imposes a smaller limit.
List does not map onto any Standard SQL type. However, you could do the
following:
1) bind a user-defined type to java.util.ArrayList via the CREATE TYPE
statement (see
http://db.apache.org/derby/docs/10.15/ref/rrefsqljcreatetype.html).
2) create a user defined function which calls ArrayList.contains() (see
http://db.apache.org/derby/docs/10.15/ref/rrefcreatefunctionstatement.html).
3) Then you could issue a query like the following:
{noformat}
SELECT * FROM t where myArrayContainsFunction((cast ? as MyArrayType), t.id);
{noformat}
4) Your application program would stuff the candidate values into an ArrayList
object and then call the following method on the PreparedStatement:
{noformat}
ps.setObject(1, myArrayList);
{noformat}
I can give you a hand with this if it's not clear. Hope this helps.
was (Author: rhillegas):
Integer.MAX_VALUE is the maximum number of ? parameters which a JDBC
PreparedStatement can take. I don't think that Derby imposes a smaller limit.
List does not map onto any Standard SQL type. However, you could do the
following:
1) bind a user-defined type to java.util.ArrayList via the CREATE TYPE
statement (see
http://db.apache.org/derby/docs/10.15/ref/rrefsqljcreatetype.html).
2) create a user defined function which calls ArrayList.contains() (see
http://db.apache.org/derby/docs/10.15/ref/rrefcreatefunctionstatement.html).
3) Then you could issue a query like the following:
{noformat}
SELECT * FROM t where myArrayContainsFunction((cast ? as MyArrayType), t.id);
{noformat}
4) Your application program would stuff the candidate values into an ArrayList
object and then call the following method on the PreparedStatement:
{noformat}
ps,setObject(1, myArrayList);
{noformat}
I can give you a hand with this if it's not clear. Hope this helps.
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
> Attachments: StatementLogReadingVTI.java
>
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.ja
[jira] [Commented] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16894479#comment-16894479
]
Rick Hillegas commented on DERBY-7049:
--
Integer.MAX_VALUE is the maximum number of ? parameters which a JDBC
PreparedStatement can take. I don't think that Derby imposes a smaller limit.
List does not map onto any Standard SQL type. However, you could do the
following:
1) bind a user-defined type to java.util.ArrayList via the CREATE TYPE
statement (see
http://db.apache.org/derby/docs/10.15/ref/rrefsqljcreatetype.html).
2) create a user defined function which calls ArrayList.contains() (see
http://db.apache.org/derby/docs/10.15/ref/rrefcreatefunctionstatement.html).
3) Then you could issue a query like the following:
{noformat}
SELECT * FROM t where myArrayContainsFunction((cast ? as MyArrayType), t.id);
{noformat}
4) Your application program would stuff the candidate values into an ArrayList
object and then call the following method on the PreparedStatement:
{noformat}
ps,setObject(1, myArrayList);
{noformat}
I can give you a hand with this if it's not clear. Hope this helps.
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
> Attachments: StatementLogReadingVTI.java
>
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is
[jira] [Commented] (DERBY-7050) In build.xml of derby root there's a vestigial target (+ patch)
[ https://issues.apache.org/jira/browse/DERBY-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893272#comment-16893272 ] Rick Hillegas commented on DERBY-7050: -- Thanks for the patch, Davide. I have committed it. > In build.xml of derby root there's a vestigial target (+ patch) > --- > > Key: DERBY-7050 > URL: https://issues.apache.org/jira/browse/DERBY-7050 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.15.1.3 >Reporter: Davide Grandi >Priority: Trivial > Attachments: build-20190625.dot, build-20190625.pdf, > build-expanded-20190625.dot, build-expanded-20190625.pdf, patch.txt > > > In main build.xml, the one at the project's root, there's a target > engine_169_opt > that executes an > > task, against > java\org.apache.derby.engine\build.xml > that, in turn, DOESNT contain a engine_169_opt target, so it raises an error. > No other build file (in fact, no other FILE in derby) contains an > "engine_169_opt" string. > So I think that target engine_169_opt in main build file can be safely > removed. > I'll attach (when possible) > # an svn diff file (the engine_169_opt target removal) > # and 2 maps (in dot and pdf format) of target relationships of build family > files of Derby > Best regards, > Davide Grandi -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891853#comment-16891853
]
Rick Hillegas commented on DERBY-7049:
--
Here is a way to discover how many unique statements your program is generating.
Attaching StatementLogReadingVTI.java. This is a table function which reads
derby.log and finds all of the statements which have been compiled--provided
that the engine was booted with the following trace flags:
{noformat}
-Dderby.language.logStatementText=true
-Dderby.stream.error.logSeverityLevel=0
{noformat}
1) Compile StatementLogReadingVTI and put it on your classpath.
2) Then run the following script. You will need to substitute your own
derby.log for the one mentioned in the script.
3) The final query should print out the number of unique statements produced by
your program.
{noformat}
connect 'jdbc:derby:memory:db;create=true';
CREATE FUNCTION readStatements
(
fileName VARCHAR(32672),
charSet VARCHAR(100)
)
RETURNS TABLE
(
statement_text VARCHAR(32672)
)
LANGUAGE JAVA
PARAMETER STYLE DERBY_JDBC_RESULT_SET
NO SQL
EXTERNAL NAME 'StatementLogReadingVTI.readStatements'
;
CREATE TABLE statementText(statement_text VARCHAR(32672));
INSERT INTO statementText
SELECT * FROM TABLE
(
readStatements('/Users/rhillegas/derby/mainline/derby.log1', 'UTF-8')
) t
;
SELECT COUNT (DISTINCT statement_text) FROM statementText;
{noformat}
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
> Attachments: StatementLogReadingVTI.java
>
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {co
[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7049:
-
Attachment: StatementLogReadingVTI.java
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
> Attachments: StatementLogReadingVTI.java
>
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of each transaction? But
> even if I really have to shut-down the DB, it is certainly a bug that the
> classes are still kept in "compressed class space" even after the shut-down.
> I searched the release notes and the existing bugs (here in JIRA) and did not
> find anything related to this {{OutOfMemoryError}}. Hence, I open this
> bug-report, now.
> This issue was originally reported in
> [subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
> clearly a Derby bug.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891448#comment-16891448
]
Rick Hillegas commented on DERBY-7049:
--
Thanks for that extra information. It does not make sense to me. Derby caches
query plans, keyed by the statement text. Your statement cache will grow to a
maximum size under the following circumstances:
1) Your statement cache is big enough. See
http://db.apache.org/derby/docs/10.15/ref/rrefproperstatementcachesize.html
2) There really are a finite number of unique statements.
If you boot the application with the following system flags...
{noformat}
-Dderby.language.logStatementText=true
-Dderby.stream.error.logSeverityLevel=0
{noformat}
...then Derby will log more information to the diagnostic derby.log file. This
information will include the text of every statement prepared by the engine.
That would help us verify that we really are dealing with a finite number of
parameterized statements.
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of ea
[jira] [Commented] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16891022#comment-16891022
]
Rick Hillegas commented on DERBY-7049:
--
That shutdown command SHOULD release the generated classes--but we have had
bugs in this area in the past.
1) Have you profiled your memory usage? Are you sure that the accumulating
classes are generated Derby query plans? Who is still referencing the plans?
2) Why does your application accumulate query plans? Does some logic in the
application hold onto them, maybe by storing PreparedStatements in a HashMap?
3) Why does the application even generate so many query plans? Is statement
text being generated on the fly? Are you not using PreparedStatements with ?
parameters?
Thanks.
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of each transaction? But
> even if I really have to shut-down the DB, it is certainly a bug that the
> classes are still kept in "compressed class space" even after the shut-down.
> I searched the release notes and the existing
[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7049:
-
Bug behavior facts: Crash,Seen in production
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of each transaction? But
> even if I really have to shut-down the DB, it is certainly a bug that the
> classes are still kept in "compressed class space" even after the shut-down.
> I searched the release notes and the existing bugs (here in JIRA) and did not
> find anything related to this {{OutOfMemoryError}}. Hence, I open this
> bug-report, now.
> This issue was originally reported in
> [subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
> clearly a Derby bug.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (DERBY-7049) OutOfMemoryError: Compressed class space
[
https://issues.apache.org/jira/browse/DERBY-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7049:
-
Component/s: SQL
> OutOfMemoryError: Compressed class space
>
>
> Key: DERBY-7049
> URL: https://issues.apache.org/jira/browse/DERBY-7049
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Marco
>Priority: Major
>
> After a few days of working with an embedded Derby database (currently
> version 10.13.1.1 on Oracle Java 1.8.0_201-b09), the following error occurs:
> *java.lang.OutOfMemoryError: Compressed class space*
> {code:java}
> java.lang.OutOfMemoryError: Compressed class space
> at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_201]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_201]
> at
> org.apache.derby.impl.services.reflect.ReflectLoaderJava2.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.ReflectClassesJava2.loadGeneratedClassFromData(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.compile.StatementNode.generate(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
> ~[derby-10.13.1.1.jar:na]
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement42.(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.jdbc.Driver42.newEmbedPreparedStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source) ~[derby-10.13.1.1.jar:na]
> at
> org.datanucleus.store.rdbms.datasource.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:259)
> ~[datanucleus-rdbms-4.0.12.jar:na]{code}
> I tried to solve the problem by periodically shutting down the database,
> because I read that the generated classes as well as all other allocated
> resources should be released when the DB is shut-down.
> I thus perform the following code once per roughly 20 minutes:
> {code:java}
> String shutdownConnectionURL = connectionURL + ";shutdown=true";
> try {
> DriverManager.getConnection(shutdownConnectionURL);
> } catch (SQLException e) {
> int errorCode = e.getErrorCode();
> if (DERBY_ERROR_CODE_SHUTDOWN_DATABASE_SUCCESSFULLY != errorCode &&
> DERBY_ERROR_CODE_SHUTDOWN_DATABASE_WAS_NOT_RUNNING != errorCode) {
> throw new RuntimeException(e);
> }
> }
> {code}
> Unfortunately, this has no effect :( The OutOfMemoryError still occurs after
> about 2 days. Do I assume correctly that the above code _should_ properly
> shut-down the database? And do I assume correctly that this shut-down should
> release the generated classes?
> IMHO, it is already a bug in Derby that I need to shut-down the database at
> all in order to prevent it from piling up generated classes. Shouldn't it
> already release the generated classes at the end of each transaction? But
> even if I really have to shut-down the DB, it is certainly a bug that the
> classes are still kept in "compressed class space" even after the shut-down.
> I searched the release notes and the existing bugs (here in JIRA) and did not
> find anything related to this {{OutOfMemoryError}}. Hence, I open this
> bug-report, now.
> This issue was originally reported in
> [subshare#74|https://github.com/subshare/subshare/issues/74], but it is IMHO
> clearly a Derby bug.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890576#comment-16890576 ] Rick Hillegas commented on DERBY-5728: -- Hi Bernard. Can you help me understand what the JPQL query is trying to achieve? What does it mean? Thanks. > Add Support for NULL IS NULL > > > Key: DERBY-5728 > URL: https://issues.apache.org/jira/browse/DERBY-5728 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.8.2.2 > Environment: Windows XP > java version "1.6.0_31" > Java(TM) SE Runtime Environment (build 1.6.0_31-b05) > Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) >Reporter: bernard >Priority: Critical > Labels: derby_triage10_10 > Attachments: NullParameterEclipseLinkDerbyMaven.zip, > NullParameterHibernateDerbyMaven.zip > > > The following query fails: > SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) > Why this is an issue? > At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues > with generating SQL for trivial JPQL queries such as: > select object(c) from Customer c where ((name: is null) or (c.name = name:)) > where name: is a parameter > For why this is a fundamental issue, please see a minimalistic JPQL query at > http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples > Part of this has already been resolved by issue "Add support for > setObject(, null)" > https://issues.apache.org/jira/browse/DERBY-1938 > Please see EclipseLink and Hibernate test cases for verification. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[
https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16890522#comment-16890522
]
Rick Hillegas commented on DERBY-5728:
--
Neither of those statements is valid SQL. Did you mean to type the final
statement in the following batch?
{noformat}
connect 'jdbc:derby:memory:db;create=true';
CREATE TABLE vocab (name VARCHAR(50));
-- raises Syntax error: Encountered "NULL" at line 1, column 21.
SELECT * FROM vocab NULL IS NULL;
-- raises Syntax error: Encountered "NULL" at line 1, column 27.
SELECT * FROM vocab WHERE NULL IS NULL;
-- succeeds
SELECT * FROM vocab WHERE name IS NULL;
{noformat}
If not, what are you trying to achieve with those two, illegal statements?
> Add Support for NULL IS NULL
>
>
> Key: DERBY-5728
> URL: https://issues.apache.org/jira/browse/DERBY-5728
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.8.2.2
> Environment: Windows XP
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
> Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
>Reporter: bernard
>Priority: Critical
> Labels: derby_triage10_10
> Attachments: NullParameterEclipseLinkDerbyMaven.zip,
> NullParameterHibernateDerbyMaven.zip
>
>
> The following query fails:
> SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL))
> Why this is an issue?
> At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues
> with generating SQL for trivial JPQL queries such as:
> select object(c) from Customer c where ((name: is null) or (c.name = name:))
> where name: is a parameter
> For why this is a fundamental issue, please see a minimalistic JPQL query at
> http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples
> Part of this has already been resolved by issue "Add support for
> setObject(, null)"
> https://issues.apache.org/jira/browse/DERBY-1938
> Please see EclipseLink and Hibernate test cases for verification.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (DERBY-7047) derby classCastException during SELECT statement
[ https://issues.apache.org/jira/browse/DERBY-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7047: - Bug behavior facts: Seen in production > derby classCastException during SELECT statement > > > Key: DERBY-7047 > URL: https://issues.apache.org/jira/browse/DERBY-7047 > Project: Derby > Issue Type: Bug > Components: SQL, Store >Affects Versions: 10.14.2.0 >Reporter: Yoaz >Priority: Major > > we use embedded derby for tests and get a ClassCastException during > performing a select statement when multiple threads are executing the > following statement. > seems similar to the following ticket: > https://issues.apache.org/jira/browse/HIVE-16362 > "SELECT * FROM node_props WHERE node_id = ?" > our Derby jdbc version is : > *org.apache.derby:10.14.2.0* > following is our SELECT Statement: > Caused by: java.sql.SQLException: Java exception: > 'org.apache.derby.iapi.services.io.FormatableBitSet cannot be cast to > org.apache.derby.iapi.store.access.StaticCompiledOpenConglomInfo: > java.lang.ClassCastException'. > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown > Source) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) > at org.apache.derby.impl.jdbc.ConnectionChild.handleException(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.executeQuery(Unknown > Source) > at org.jfrog.storage.JdbcHelper.executeSelect(JdbcHelper.java:184) > at org.jfrog.storage.JdbcHelper.executeSelect(JdbcHelper.java:152) > at > org.artifactory.storage.db.fs.dao.PropertiesDao.getNodeProperties(PropertiesDao.java:85) > at > org.artifactory.storage.db.fs.service.DbPropertiesServiceImpl.loadProperties(DbPropertiesServiceImpl.java:163) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7047) derby classCastException during SELECT statement
[ https://issues.apache.org/jira/browse/DERBY-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7047: - Component/s: Store SQL > derby classCastException during SELECT statement > > > Key: DERBY-7047 > URL: https://issues.apache.org/jira/browse/DERBY-7047 > Project: Derby > Issue Type: Bug > Components: SQL, Store >Affects Versions: 10.14.2.0 >Reporter: Yoaz >Priority: Major > > we use embedded derby for tests and get a ClassCastException during > performing a select statement when multiple threads are executing the > following statement. > seems similar to the following ticket: > https://issues.apache.org/jira/browse/HIVE-16362 > "SELECT * FROM node_props WHERE node_id = ?" > our Derby jdbc version is : > *org.apache.derby:10.14.2.0* > following is our SELECT Statement: > Caused by: java.sql.SQLException: Java exception: > 'org.apache.derby.iapi.services.io.FormatableBitSet cannot be cast to > org.apache.derby.iapi.store.access.StaticCompiledOpenConglomInfo: > java.lang.ClassCastException'. > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown > Source) > at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown > Source) > at > org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) > at org.apache.derby.impl.jdbc.ConnectionChild.handleException(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.executeQuery(Unknown > Source) > at org.jfrog.storage.JdbcHelper.executeSelect(JdbcHelper.java:184) > at org.jfrog.storage.JdbcHelper.executeSelect(JdbcHelper.java:152) > at > org.artifactory.storage.db.fs.dao.PropertiesDao.getNodeProperties(PropertiesDao.java:85) > at > org.artifactory.storage.db.fs.service.DbPropertiesServiceImpl.loadProperties(DbPropertiesServiceImpl.java:163) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872782#comment-16872782
]
Rick Hillegas commented on DERBY-7046:
--
Hey Bryan,
That sounds like a good idea. If we'd had such a test, then this regression
would have been caught earlier!
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Assignee: Rick Hillegas
>Priority: Major
> Attachments: derby-7046-01-aa-addToolsJarToServerManifest.diff
>
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872341#comment-16872341
]
Rick Hillegas commented on DERBY-7046:
--
Tests passed cleanly for me with both the classpath and the modulepath except
for the known instabilities described by DERBY-4762 and DERBY-5941.
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Assignee: Rick Hillegas
>Priority: Major
> Attachments: derby-7046-01-aa-addToolsJarToServerManifest.diff
>
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16871895#comment-16871895
]
Rick Hillegas commented on DERBY-7046:
--
Attaching derby-7046-01-aa-addToolsJarToServerManifest.diff. This patch adds
derbytools.jar to the classpath scribbled into derbynet.jar's manifest.
With this change, I can boot the server as follows:
{noformat}
java -jar trunk/jars/sane/derbynet.jar start
{noformat}
I will run full tests with both the classpath and the modulepath.
Touches the following file:
{noformat}
M build.xml
{noformat}
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Assignee: Rick Hillegas
>Priority: Major
> Attachments: derby-7046-01-aa-addToolsJarToServerManifest.diff
>
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7046:
-
Attachment: derby-7046-01-aa-addToolsJarToServerManifest.diff
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Assignee: Rick Hillegas
>Priority: Major
> Attachments: derby-7046-01-aa-addToolsJarToServerManifest.diff
>
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7046:
-
Urgency: Normal
Bug behavior facts: Regression,Seen in production
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Assignee: Rick Hillegas
>Priority: Major
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16871860#comment-16871860
]
Rick Hillegas commented on DERBY-7046:
--
Thanks for finding this regression. I can confirm that a ClassNotFoundException
is raised by the following command:
{noformat}
java -jar derbynet.jar start
{noformat}
Try the following workaround:
{noformat}
java -jar derbyrun.jar server start
{noformat}
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Assignee: Rick Hillegas
>Priority: Major
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas reassigned DERBY-7046:
Assignee: Rick Hillegas
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Assignee: Rick Hillegas
>Priority: Major
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7046) NoClassDefFoundError on 'java -jar derbynet.jar'
[
https://issues.apache.org/jira/browse/DERBY-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7046:
-
Component/s: Network Server
> NoClassDefFoundError on 'java -jar derbynet.jar'
>
>
> Key: DERBY-7046
> URL: https://issues.apache.org/jira/browse/DERBY-7046
> Project: Derby
> Issue Type: Bug
> Components: Network Server
>Affects Versions: 10.15.1.3
> Environment: openjdk version "11.0.3" 2019-04-16
> db-derby-10.15.1.3-bin
>Reporter: Piotr Zygielo
>Priority: Major
>
> {{derbynet.jar}} seems to be runnable jar - it has
> {code}
> Main-Class: org.apache.derby.drda.NetworkServerControl
> {code}
> but
> {code}
> Class-Path: derby.jar derbyshared.jar
> {code}
> does not include {{derbytools.jar}}.
> So on running {code:sh}java -jar derbynet.jar{code} following is presented:
> {code}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/derby/iapi/tools/i18n/LocalizedOutput
> at
> org.apache.derby.drda.NetworkServerControl.main(NetworkServerControl.java:319)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.derby.iapi.tools.i18n.LocalizedOutput
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 1 more
> {code}
> It works fine with previous version (10.14.2.0).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7034) Derby's sync() handling can lead to database corruption (at least on Linux)
[
https://issues.apache.org/jira/browse/DERBY-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856263#comment-16856263
]
Rick Hillegas commented on DERBY-7034:
--
Thanks for that clarification, David.
> Derby's sync() handling can lead to database corruption (at least on Linux)
> ---
>
> Key: DERBY-7034
> URL: https://issues.apache.org/jira/browse/DERBY-7034
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.14.2.0
>Reporter: David Sitsky
>Priority: Major
>
> I recently read about "fsyncgate 2018" that the Postgres team raised:
> https://wiki.postgresql.org/wiki/Fsync_Errors.
> https://lwn.net/Articles/752063/ has a good overview of the issue relating to
> fsync() behaviour on Linux. The short summary is on some versions of Linux
> if you retry fsync() after it failed, it will succeed and you will end up
> with corrupted data on disk.
> At a quick glance at the Derby code, I have already seen two places where
> sync() is retried in a loop which is clearly dangerous. There could be other
> areas too.
> In LogAccessFile:
> {code}
> /**
> * Guarantee all writes up to the last call to flushLogAccessFile on disk.
> *
> * A call for clients of LogAccessFile to insure that all data written
> * up to the last call to flushLogAccessFile() are written to disk.
> * This call will not return until those writes have hit disk.
> *
> * Note that this routine may block waiting for I/O to complete so
> * callers should limit the number of resource held locked while this
> * operation is called. It is expected that the caller
> * Note that this routine only "writes" the data to the file, this does
> not
> * mean that the data has been synced to disk. The only way to insure
> that
> * is to first call switchLogBuffer() and then follow by a call of sync().
> *
> **/
> public void syncLogAccessFile()
> throws IOException, StandardException
> {
> for( int i=0; ; )
> {
> // 3311: JVM sync call sometimes fails under high load against
> NFS
> // mounted disk. We re-try to do this 20 times.
> try
> {
> synchronized( this)
> {
> log.sync();
> }
> // the sync succeed, so return
> break;
> }
> catch( SyncFailedException sfe )
> {
> i++;
> try
> {
> // wait for .2 of a second, hopefully I/O is done by now
> // we wait a max of 4 seconds before we give up
> Thread.sleep( 200 );
> }
> catch( InterruptedException ie )
> {
> InterruptStatus.setInterrupted();
> }
> if( i > 20 )
> throw StandardException.newException(
> SQLState.LOG_FULL, sfe);
> }
> }
> }
> {code}
> And LogToFile has similar retry code.. but without handling for
> SyncFailedException:
> {code}
> /**
> * Utility routine to call sync() on the input file descriptor.
> *
> */
> private void syncFile( StorageRandomAccessFile raf)
> throws StandardException
> {
> for( int i=0; ; )
> {
> // 3311: JVM sync call sometimes fails under high load against
> NFS
> // mounted disk. We re-try to do this 20 times.
> try
> {
> raf.sync();
> // the sync succeed, so return
> break;
> }
> catch (IOException ioe)
> {
> i++;
> try
> {
> // wait for .2 of a second, hopefully I/O is done by now
> // we wait a max of 4 seconds before we give up
> Thread.sleep(200);
> }
> catch( InterruptedException ie )
> {
> InterruptStatus.setInterrupted();
> }
> if( i > 20 )
> {
> throw StandardException.newException(
> SQLState.LOG_FULL, ioe);
> }
> }
> }
> }
> {code}
> It seems Postgres, MySQL and MongoDB have already changed their code to
> "panic" if an error comes from an fsync() call.
> There is a lot more complexities with how fsync() reports errors (if at all).
> It is worth getting into it further as I am not familiar with Derby's
> internals and how
[jira] [Commented] (DERBY-7034) Derby's sync() handling can lead to database corruption (at least on Linux)
[
https://issues.apache.org/jira/browse/DERBY-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16855714#comment-16855714
]
Rick Hillegas commented on DERBY-7034:
--
Thanks for the nudge, David. I have briefly browsed the link you provided. Is
the following a fair summary of the problem:
1) The Linux fsync() call does not obey its contract. It can return before
writes have durably recorded. The fix is to skip caching and use direct io
instead.
2) FileDescriptor.sync() probably relies on fsync() (I haven't verified this
claim). Therefore, system software like the Derby engine can not guarantee that
commits have durably recorded. That, in turn, can corrupt data when, for
instance, a USB stick is yanked out of its slot prematurely.
Can you help me understand why this is not a bigger problem than Derby? It
seems to me that the problem is that FileDescriptor.sync() does not fulfill its
contract. Has a bug been logged against Open JDK?
Thanks,
-Rick
> Derby's sync() handling can lead to database corruption (at least on Linux)
> ---
>
> Key: DERBY-7034
> URL: https://issues.apache.org/jira/browse/DERBY-7034
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.14.2.0
>Reporter: David Sitsky
>Priority: Major
>
> I recently read about "fsyncgate 2018" that the Postgres team raised:
> https://wiki.postgresql.org/wiki/Fsync_Errors.
> https://lwn.net/Articles/752063/ has a good overview of the issue relating to
> fsync() behaviour on Linux. The short summary is on some versions of Linux
> if you retry fsync() after it failed, it will succeed and you will end up
> with corrupted data on disk.
> At a quick glance at the Derby code, I have already seen two places where
> sync() is retried in a loop which is clearly dangerous. There could be other
> areas too.
> In LogAccessFile:
> {code}
> /**
> * Guarantee all writes up to the last call to flushLogAccessFile on disk.
> *
> * A call for clients of LogAccessFile to insure that all data written
> * up to the last call to flushLogAccessFile() are written to disk.
> * This call will not return until those writes have hit disk.
> *
> * Note that this routine may block waiting for I/O to complete so
> * callers should limit the number of resource held locked while this
> * operation is called. It is expected that the caller
> * Note that this routine only "writes" the data to the file, this does
> not
> * mean that the data has been synced to disk. The only way to insure
> that
> * is to first call switchLogBuffer() and then follow by a call of sync().
> *
> **/
> public void syncLogAccessFile()
> throws IOException, StandardException
> {
> for( int i=0; ; )
> {
> // 3311: JVM sync call sometimes fails under high load against
> NFS
> // mounted disk. We re-try to do this 20 times.
> try
> {
> synchronized( this)
> {
> log.sync();
> }
> // the sync succeed, so return
> break;
> }
> catch( SyncFailedException sfe )
> {
> i++;
> try
> {
> // wait for .2 of a second, hopefully I/O is done by now
> // we wait a max of 4 seconds before we give up
> Thread.sleep( 200 );
> }
> catch( InterruptedException ie )
> {
> InterruptStatus.setInterrupted();
> }
> if( i > 20 )
> throw StandardException.newException(
> SQLState.LOG_FULL, sfe);
> }
> }
> }
> {code}
> And LogToFile has similar retry code.. but without handling for
> SyncFailedException:
> {code}
> /**
> * Utility routine to call sync() on the input file descriptor.
> *
> */
> private void syncFile( StorageRandomAccessFile raf)
> throws StandardException
> {
> for( int i=0; ; )
> {
> // 3311: JVM sync call sometimes fails under high load against
> NFS
> // mounted disk. We re-try to do this 20 times.
> try
> {
> raf.sync();
> // the sync succeed, so return
> break;
> }
> catch (IOException ioe)
> {
> i++;
> try
> {
> // wait for .2 of a second, hopefully I/O is done by now
> // we wait a max of 4 seco
[jira] [Commented] (DERBY-11) Recursive SQL and WITH A(col list) as (Select col list From Table List) Support.
[ https://issues.apache.org/jira/browse/DERBY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16851355#comment-16851355 ] Rick Hillegas commented on DERBY-11: I'm not aware of any work on this useful issue. > Recursive SQL and WITH A(col list) as (Select col list From Table List) > Support. > > > Key: DERBY-11 > URL: https://issues.apache.org/jira/browse/DERBY-11 > Project: Derby > Issue Type: Improvement > Components: SQL > Environment: ANY. >Reporter: Ali Demir >Priority: Major > Labels: derby_triage10_11 > > Right now, in Derby, there is no way to define a temporary Result Set to use > in subsequent statements. This makes complicated concepts to be expressed in > SQL either very very complicated and lengthy or simply impossible. > DB2 has a simple and useful syntax using a "WITH" statement. It would be nice > if Derby can support this. An example is as below: > WITH A(COL1, COL2) as (SELECT COL1, COL2 FROM T1 WHERE condition) > SELECT T2.COL3 FROM T2, A WHERE condition2 > It can be extended to include more WITH clauses: > WITH A(COL1, COL2) as (SELECT COL1, COL2 FROM T1 WHERE condition) > WITH B(COL3) as (SELECT COL3 FROM T1,A WHERE condition2) > SELECT T2.COL5, B.COL3 FROM T2, A, B WHERE condition3 > and so on. > Note that as the following example shows, the use of table correlation name > in another subselect is NOT supported and cannot be a workaround: > SELECT cols FROM (SELECT cols FROM T1) as A, (SELECT cols FROM T2,A where A > relates to T2) as B where condition > Another interesting aspect of these WITH clauses is their ability to make > RECURSIVE SQL possible. In below example, definition of A includes a select > from ITSELF: > WITH A(COL1, COL2) as (SELECT COL1, COL2 FROM T1 UNION ALL SELECT COL1, COL2 > FROM T2, A where A.COL1=T2.COLN) > SELECT COL1, COL2 FROM A WHERE condition2 > Recursion with a WITH clause relies on a specific syntax. Consult DB2 > documentation for more info about Recursion and WITH clause. > Recursion is an important facility and it would be very very useful to have > it in Derby. > Recursion comes in very handy when a single table holds a hierarchy of rows > that are related to each other with parent-child relationships of N-Levels > where N is large or unknown in which case non-recursive solutions are either > impossible or require complicated code at the Client side. With recursion > possible at the SQL level, many problems can be reduced to single SQL > statements instead of lengthy application code. > Regards, > Suavi Demir -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7038) Upgrade ant version and re-write javadoc build targets to use improved task
[
https://issues.apache.org/jira/browse/DERBY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839022#comment-16839022
]
Rick Hillegas commented on DERBY-7038:
--
Attaching derby-7038-02-aa-use-ant-javadoc-task.diff. This patch reverts the
build to using the task to build javadoc rather than the task.
This is now possible because ant 1.10.6 supports several module-aware javadoc
switches.
The old and new javadoc outputs (for public api and for internal Derby classes)
is slightly different. Mostly, the new output is more informative. However,
there are cases where the old output is more informative. I don't know what
causes the discrepancies. In any event, the differences do not look significant
to me, either way.
Regardless of which output one prefers, it seems to me that if we wanted to
invest more effort in the javadoc, a more critical improvement would be to
systematically add package summaries to the overview page for each module. Some
packages have summary lines but most don't.
Touches the following file:
{noformat}
-
M build.xml
Replaces tasks with tasks.
{noformat}
> Upgrade ant version and re-write javadoc build targets to use improved
> task
>
>
> Key: DERBY-7038
> URL: https://issues.apache.org/jira/browse/DERBY-7038
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.16.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
>Priority: Major
> Attachments: derby-7038-01-aa-require-Ant-1.10.6.diff,
> derby-7038-02-aa-use-ant-javadoc-task.diff
>
>
> Version 1.10.6 of ant will enhance the task in order to understand
> some of the module-aware switches introduced by Java 9. Currently, our
> javadoc targets work around the limitations of the task by running
> javadoc via the task. We should upgrade our version of ant and
> re-write the javadoc targets to take advantage of the improvements introduced
> by ant 1.10.16 (see
> https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html). I
> imagine this work will occur in 3 phases:
> 1) Upgrade the Jenkins scripts to require ant 1.10.6.
> 2) Upgrade our build scripts to require ant 1.10.6.
> 3) Re-wire our javadoc targets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7038) Upgrade ant version and re-write javadoc build targets to use improved task
[ https://issues.apache.org/jira/browse/DERBY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7038: - Attachment: derby-7038-02-aa-use-ant-javadoc-task.diff > Upgrade ant version and re-write javadoc build targets to use improved > task > > > Key: DERBY-7038 > URL: https://issues.apache.org/jira/browse/DERBY-7038 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas >Priority: Major > Attachments: derby-7038-01-aa-require-Ant-1.10.6.diff, > derby-7038-02-aa-use-ant-javadoc-task.diff > > > Version 1.10.6 of ant will enhance the task in order to understand > some of the module-aware switches introduced by Java 9. Currently, our > javadoc targets work around the limitations of the task by running > javadoc via the task. We should upgrade our version of ant and > re-write the javadoc targets to take advantage of the improvements introduced > by ant 1.10.16 (see > https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html). I > imagine this work will occur in 3 phases: > 1) Upgrade the Jenkins scripts to require ant 1.10.6. > 2) Upgrade our build scripts to require ant 1.10.6. > 3) Re-wire our javadoc targets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7038) Upgrade ant version and re-write javadoc build targets to use improved task
[ https://issues.apache.org/jira/browse/DERBY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7038: - Attachment: derby-7038-01-aa-require-Ant-1.10.6.diff > Upgrade ant version and re-write javadoc build targets to use improved > task > > > Key: DERBY-7038 > URL: https://issues.apache.org/jira/browse/DERBY-7038 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas >Priority: Major > Attachments: derby-7038-01-aa-require-Ant-1.10.6.diff > > > Version 1.10.6 of ant will enhance the task in order to understand > some of the module-aware switches introduced by Java 9. Currently, our > javadoc targets work around the limitations of the task by running > javadoc via the task. We should upgrade our version of ant and > re-write the javadoc targets to take advantage of the improvements introduced > by ant 1.10.16 (see > https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html). I > imagine this work will occur in 3 phases: > 1) Upgrade the Jenkins scripts to require ant 1.10.6. > 2) Upgrade our build scripts to require ant 1.10.6. > 3) Re-wire our javadoc targets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7038) Upgrade ant version and re-write javadoc build targets to use improved task
[
https://issues.apache.org/jira/browse/DERBY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838102#comment-16838102
]
Rick Hillegas commented on DERBY-7038:
--
Attaching derby-7038-01-aa-require-Ant-1.10.6.diff. This patch changes the
build to require ant version 1.10.6 or higher.
Touches the following files:
{noformat}
-
M build.xml
Change the top level build script to require ant version 1.10.6.
-
M BUILDING.html
Update the build instructions to note that the minimum version of ant
has changed.
{noformat}
> Upgrade ant version and re-write javadoc build targets to use improved
> task
>
>
> Key: DERBY-7038
> URL: https://issues.apache.org/jira/browse/DERBY-7038
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.16.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
>Priority: Major
> Attachments: derby-7038-01-aa-require-Ant-1.10.6.diff
>
>
> Version 1.10.6 of ant will enhance the task in order to understand
> some of the module-aware switches introduced by Java 9. Currently, our
> javadoc targets work around the limitations of the task by running
> javadoc via the task. We should upgrade our version of ant and
> re-write the javadoc targets to take advantage of the improvements introduced
> by ant 1.10.16 (see
> https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html). I
> imagine this work will occur in 3 phases:
> 1) Upgrade the Jenkins scripts to require ant 1.10.6.
> 2) Upgrade our build scripts to require ant 1.10.6.
> 3) Re-wire our javadoc targets.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7038) Upgrade ant version and re-write javadoc build targets to use improved task
[ https://issues.apache.org/jira/browse/DERBY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838098#comment-16838098 ] Rick Hillegas commented on DERBY-7038: -- We don't need to adjust the Jenkins scripts to specify Ant 1.10.6. The Jenkins scripts already require the latest version of Ant. > Upgrade ant version and re-write javadoc build targets to use improved > task > > > Key: DERBY-7038 > URL: https://issues.apache.org/jira/browse/DERBY-7038 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas >Priority: Major > > Version 1.10.6 of ant will enhance the task in order to understand > some of the module-aware switches introduced by Java 9. Currently, our > javadoc targets work around the limitations of the task by running > javadoc via the task. We should upgrade our version of ant and > re-write the javadoc targets to take advantage of the improvements introduced > by ant 1.10.16 (see > https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html). I > imagine this work will occur in 3 phases: > 1) Upgrade the Jenkins scripts to require ant 1.10.6. > 2) Upgrade our build scripts to require ant 1.10.6. > 3) Re-wire our javadoc targets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7038) Upgrade ant version and re-write javadoc build targets to use improved task
[ https://issues.apache.org/jira/browse/DERBY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838097#comment-16838097 ] Rick Hillegas commented on DERBY-7038: -- I have upgraded my ant version to 1.10.6, successfully built Derby, and successfully run the tests both with a classpath and a module path. > Upgrade ant version and re-write javadoc build targets to use improved > task > > > Key: DERBY-7038 > URL: https://issues.apache.org/jira/browse/DERBY-7038 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas >Priority: Major > > Version 1.10.6 of ant will enhance the task in order to understand > some of the module-aware switches introduced by Java 9. Currently, our > javadoc targets work around the limitations of the task by running > javadoc via the task. We should upgrade our version of ant and > re-write the javadoc targets to take advantage of the improvements introduced > by ant 1.10.16 (see > https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html). I > imagine this work will occur in 3 phases: > 1) Upgrade the Jenkins scripts to require ant 1.10.6. > 2) Upgrade our build scripts to require ant 1.10.6. > 3) Re-wire our javadoc targets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7045) Declare variable not supported in derby
[ https://issues.apache.org/jira/browse/DERBY-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838096#comment-16838096 ] Rick Hillegas commented on DERBY-7045: -- It used to be possible to download a free copy of the SQL Standard. I can't find any way to do that now. Section 21 defines language for embedding SQL in a number of host languages. Statements like DECLARE and IF are part of procedural extensions to the Standard, which many databases support. They are used to write the execution logic of a database procedure in a way which can be included as part of the CREATE PROCEDURE statement. Derby does not support any of these procedural statements. Derby database procedures are written in Java as described by the SQL Reference Manual (see http://db.apache.org/derby/docs/10.15/ref/rrefcreateprocedurestatement.html) and the SQL Developer's Guide (see http://db.apache.org/derby/docs/10.15/devguide/cdevspecial42117.html). Please consult those documents if you need to write procedural code which runs inside the Derby engine. > Declare variable not supported in derby > --- > > Key: DERBY-7045 > URL: https://issues.apache.org/jira/browse/DERBY-7045 > Project: Derby > Issue Type: Improvement >Reporter: Naresh >Priority: Major > > Hi Team, > Can you please confirm if Derby DB is supporting declaration of a variable. > I have listed below example similar to that we need to declare variable in > derby db . > DECLARE count INTEGER; > DECLARE status VARCHAR; > Similar to above use case I would like to declare a variable in derby db. Can > you please help me on this issue. > Thanks, > Naresh. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7045) Declare variable not supported in derby
[ https://issues.apache.org/jira/browse/DERBY-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7045: - Issue Type: Improvement (was: Bug) > Declare variable not supported in derby > --- > > Key: DERBY-7045 > URL: https://issues.apache.org/jira/browse/DERBY-7045 > Project: Derby > Issue Type: Improvement >Reporter: Naresh >Priority: Major > > Hi Team, > Can you please confirm if Derby DB is supporting declaration of a variable. > I have listed below example similar to that we need to declare variable in > derby db . > DECLARE count INTEGER; > DECLARE status VARCHAR; > Similar to above use case I would like to declare a variable in derby db. Can > you please help me on this issue. > Thanks, > Naresh. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7045) Declare variable not supported in derby
[ https://issues.apache.org/jira/browse/DERBY-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837688#comment-16837688 ] Rick Hillegas commented on DERBY-7045: -- Derby does not support the SQL PL/I language defined in part 2, section 21.9 of the 2016 SQL Standard. > Declare variable not supported in derby > --- > > Key: DERBY-7045 > URL: https://issues.apache.org/jira/browse/DERBY-7045 > Project: Derby > Issue Type: Bug >Reporter: Naresh >Priority: Major > > Hi Team, > Can you please confirm if Derby DB is supporting declaration of a variable. > I have listed below example similar to that we need to declare variable in > derby db . > DECLARE count INTEGER; > DECLARE status VARCHAR; > Similar to above use case I would like to declare a variable in derby db. Can > you please help me on this issue. > Thanks, > Naresh. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7045) Declare variable not supported in derby
[ https://issues.apache.org/jira/browse/DERBY-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7045: - Urgency: Low (was: Urgent) > Declare variable not supported in derby > --- > > Key: DERBY-7045 > URL: https://issues.apache.org/jira/browse/DERBY-7045 > Project: Derby > Issue Type: Bug >Reporter: Naresh >Priority: Major > > Hi Team, > Can you please confirm if Derby DB is supporting declaration of a variable. > I have listed below example similar to that we need to declare variable in > derby db . > DECLARE count INTEGER; > DECLARE status VARCHAR; > Similar to above use case I would like to declare a variable in derby db. Can > you please help me on this issue. > Thanks, > Naresh. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-6645) Switch to Maven for building Apache Derby
[ https://issues.apache.org/jira/browse/DERBY-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836789#comment-16836789 ] Rick Hillegas commented on DERBY-6645: -- Thanks, Davide! > Switch to Maven for building Apache Derby > - > > Key: DERBY-6645 > URL: https://issues.apache.org/jira/browse/DERBY-6645 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.10.2.0 >Reporter: Moritz Hoffmann >Priority: Major > Attachments: DERBY-6645_v1.patch, build.xml.dot.pdf, build2dot.zip > > > For a new user building Derby is very hard. It does not follow established > Java project structures and requires a lot of prior knowledge. Also the > documentation is rather short. Especially running the tests is non-intuitive > at the beginning. Thus, I propose that Derby switches to building using Maven > and restructures its components in a cleaner way. Testing should be revised > to produce reproducible results. This would make development and testing much > easier and more user-friendly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7043) DROP SCHEMA results in ERROR XSAI2
[
https://issues.apache.org/jira/browse/DERBY-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832116#comment-16832116
]
Rick Hillegas commented on DERBY-7043:
--
It seems that the base table for SYS.SYSSEQUENCES has been deleted. Is it
possible that it has been deleted by some software layer between your
application and Derby?
> DROP SCHEMA results in ERROR XSAI2
> --
>
> Key: DERBY-7043
> URL: https://issues.apache.org/jira/browse/DERBY-7043
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.8.2.2
> Environment: OS/400
>Reporter: Rick Cook
>Priority: Minor
>
> DROP SCHEMA schemaname RESTRICT results in:
> *{color:#d04437}ERROR XSAI2: The conglomerate (1,024) requested does not
> exist.{color}*
> Prior to DROP SCHEMA, I did drop all tables in that schema.
> I realize that 1,024 conglomerate number translates into c400.dat file in
> Derby seq0 directory, and that c400.dat file is indeed missing, and I neither
> know why nor for how long.
> I ran consistency checks on database using SQL commands from
> [https://wiki.apache.org/db-derby/DatabaseConsistencyCheck] to find the bad
> table(s):
> *{color:#14892c}I isolated the 1,024 conglomerate error to the
> SYS.SYSSEQUENCES table.{color}*
> And I used the following SQL to identify the conglomerate name:
> {color:#654982}*SYSSEQUENCES_HEAP*{color}
> SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME FROM
> SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE CONGLOMERATENUMBER = 1024 AND
> s.schemaid = C.schemaid
> In fact, I cannot even SQL SELECT on SYS.SYSSEQUENCES table without getting
> the same conglomerate error as the DROP SCHEMA schemaname RESTRICT command.
> In other words, I cannot DROP SCHEMA schemaname RESTRICT until
> SYS.SYSSEQUENCES corruption is resolved.
> I was wondering if anyone knew how to resolve this easily with either SQL
> command(s) or any UNIX style java commands.
> P.S. Keep in mind, that I am not an IJ expert, as I have been using a simple
> front-end Derby tool created by our manufacturer to run SQL statements on
> Derby DB, without all the complexity of using IJ and setting up IJ with
> environment variables, classpaths, etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7042) Multiple triggers with rowLocking = false causes deadlock
[
https://issues.apache.org/jira/browse/DERBY-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811686#comment-16811686
]
Rick Hillegas commented on DERBY-7042:
--
Thanks for those suggestions, Bryan. Attaching a new version of Derby7042.java.
This version adds another procedure which leaves more fingerprints in
derby.log. I also updated the script with the following changes:
* Moved the property-setting out of the script and onto the VM boot command,
just in case I'm misunderstanding when the properties take effect.
* Printed timestamps before and after the UPDATE statement.
* Increased the lock timeout to twice the length of the deadlock timeout.
* Performed two UPDATEs back-to-back.
I ran with the following trace properties:
{noformat}
-Dderby.storage.rowLocking=false \
-Dderby.locks.deadlockTimeout=5 \
-Dderby.locks.waitTimeout=10 \
-Dderby.locks.deadlockTrace=true \
-Dderby.locks.monitor=true \
-Dderby.language.logStatementText=true \
-Dderby.stream.error.logSeverityLevel=0 \
{noformat}
The revised experiment discloses the following behavior:
* The INSERT takes 10 seconds to run, the length of the lock timeout. Looking
inside derby.log, the 10 seconds elapse between the compilation and execution
of the insert trigger. The trigger compilation and execution occur AFTER the
execution of the INSERT statement.
* The first UPDATE takes 10 seconds to run, the length of the lock timeout. As
with the INSERT statement, the 10 seconds elapse between the compilation and
execution of the update trigger. The trigger compilation and execution occur
AFTER the execution of the UPDATE statement.
* The second UPDATE executes immediately. There is no pause between the
compilation and execution of the update trigger.
* There are no timeout or deadlock diagnostics in derby.log. However, there are
transaction ids on the statements. It appears that the triggers are being
compiled in the same transaction as their triggering statements.
Maybe, somehow, the table-level lock forced by derby.storage.rowLocking=false
is interfering with the compilation of the triggers. The second execution goes
fast because the triggers are already compiled and sitting in the statement
cache.
Here is the revised script:
{noformat}
connect 'jdbc:derby:memory:db1;create=true';
-- create schema
CREATE TABLE ZooAnimals
(
Name VARCHAR(255),
Amount INT,
Feed BOOLEAN,
Zoo VARCHAR(255)
)
;
CREATE PROCEDURE helloDML(dml varchar(100))
LANGUAGE JAVA
EXTERNAL NAME 'Derby7042.helloDML'
PARAMETER STYLE JAVA
NO SQL
;
CREATE TRIGGER ZooUpdateTrigger
AFTER UPDATE ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloDML('UPDATE')
;
CREATE TRIGGER ZooInsertTrigger
AFTER INSERT ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloDML('INSERT')
;
CREATE TRIGGER ZooDeleteTrigger
AFTER DELETE ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloDML('DELETE')
;
-- populate table. this takes 10 seconds, the length of the lock timeout.
VALUES CURRENT_TIMESTAMP;
INSERT INTO ZooAnimals (Name, Amount, Feed, Zoo) VALUES ('Gorilla', 1, true,
'Cincinnati');
VALUES CURRENT_TIMESTAMP;
SELECT * FROM ZooAnimals;
-- reboot to flush the statement cache.
connect 'jdbc:derby:memory:db1;shutdown=true';
connect 'jdbc:derby:memory:db1';
-- update table. the UPDATE takes 10 seconds, the length of the lock timeout.
VALUES CURRENT_TIMESTAMP;
UPDATE ZooAnimals SET Name = 'Aardvark' WHERE Zoo = 'Cincinnati';
VALUES CURRENT_TIMESTAMP;
SELECT * FROM ZooAnimals;
-- try it again. the UPDATE runs immediately.
VALUES CURRENT_TIMESTAMP;
UPDATE ZooAnimals SET Name = 'Alligator' WHERE Zoo = 'Cincinnati';
VALUES CURRENT_TIMESTAMP;
SELECT * FROM ZooAnimals;
{noformat}
Here is its output:
{noformat}
ij version 10.16
ij> connect 'jdbc:derby:memory:db1;create=true';
ij> -- create schema
CREATE TABLE ZooAnimals
(
Name VARCHAR(255),
Amount INT,
Feed BOOLEAN,
Zoo VARCHAR(255)
)
;
0 rows inserted/updated/deleted
ij> CREATE PROCEDURE helloDML(dml varchar(100))
LANGUAGE JAVA
EXTERNAL NAME 'Derby7042.helloDML'
PARAMETER STYLE JAVA
NO SQL
;
0 rows inserted/updated/deleted
ij> CREATE TRIGGER ZooUpdateTrigger
AFTER UPDATE ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloDML('UPDATE')
;
0 rows inserted/updated/deleted
ij> CREATE TRIGGER ZooInsertTrigger
AFTER INSERT ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloDML('INSERT')
;
0 rows inserted/updated/deleted
ij> CREATE TRIGGER ZooDeleteTrigger
AFTER DELETE ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloDML('DELETE')
;
0 rows inserted/updated/deleted
ij> -- populate table. this takes 10 seconds, the length of the lock timeout.
VALUES CURRENT_TIMESTAMP;
1
-
2019-04-06 12:57:55.049
1 row selected
ij> INSERT INTO ZooAnimals (Name, Amount, Feed, Zoo) VALUES
[jira] [Updated] (DERBY-7042) Multiple triggers with rowLocking = false causes deadlock
[
https://issues.apache.org/jira/browse/DERBY-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7042:
-
Attachment: Derby7042.java
> Multiple triggers with rowLocking = false causes deadlock
> -
>
> Key: DERBY-7042
> URL: https://issues.apache.org/jira/browse/DERBY-7042
> Project: Derby
> Issue Type: Bug
> Components: Documentation, JDBC
>Affects Versions: 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.14.2.0, 10.15.1.3
> Environment: -- Java Information --
> Java Version:1.8.0_201
> Java Vendor: Oracle Corporation
> OS name: Linux
> OS architecture: i386
> OS version: 4.15.0-46-generic
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.8
> java.runtime.version: 1.8.0_201-b09
> - Derby Information
> [.../TriggerRepro/derby/derby-10.14.1.0.jar] 10.14.1.0 - (1808820)
>Reporter: Michael Schuetze
>Priority: Minor
> Labels: documentation, performance
> Attachments: Derby7042.java, Derby7042.java
>
>
> Repro for the bug can be found here:
> [https://github.com/mjschuetze102/TriggerRepro]
> Includes a detailed README of steps that show effect of bug as well as two
> versions of the Derby database. 10.8.1.2, the last version where the bug was
> not present and version 10.14.1.0, for easy access.
> This may just be an issue of not having enough documentation on database
> Triggers (see Conclusions Based on Results)
> h2. Summary of Issue
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes
> issues with deadlocking*
> # Executing Update trigger causes deadlock when there is an Insert or Delete
> trigger
> # Executing Insert trigger causes deadlock when there is a Delete trigger
> # Executing Delete trigger does not cause deadlock
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> # While executing issue above, none of the triggers were terminated and
> waitTimeout time was hit
> h2. Conclusions Based on Results
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes
> issues with deadlocking*
> Triggers seem to get into deadlock scenarios with any trigger defined after
> itself. If this is the case, it should be documented somewhere that
> rowLocking needs to be enabled to use the trigger feature if multiple
> triggers would be used on the same database table.
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> Based on documentation, I could not find any concrete evidence of whether
> this is intended functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas reassigned DERBY-7041:
Assignee: Rick Hillegas
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Assignee: Rick Hillegas
>Priority: Major
> Fix For: 10.15.1.4
>
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff, derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas closed DERBY-7041.
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Fix For: 10.15.1.4
>
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff, derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas resolved DERBY-7041.
--
Resolution: Fixed
Fix Version/s: 10.15.1.4
Issue & fix info: Repro attached
Bug behavior facts: Seen in production
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Fix For: 10.15.1.4
>
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff, derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7042) Multiple triggers with rowLocking = false causes deadlock
[
https://issues.apache.org/jira/browse/DERBY-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811617#comment-16811617
]
Rick Hillegas commented on DERBY-7042:
--
I am trying to understand how to trip this bug, but so far I have not been able
to make it occur. I have extracted the following script from your repro and I
have run the script against both the development trunk and the latest 10.15.1.3
release. It runs without error for me. Could you take a look at this script and
suggest how to make it demonstrate the problem you are seeing?
Thanks,
-Rick
Here is the script:
{noformat}
connect 'jdbc:derby:memory:db1;create=true';
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.storage.rowLocking',
'false');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.locks.deadlockTimeout', '5');
CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.locks.waitTimeout', '5');
-- create schema
CREATE TABLE ZooAnimals
(
Name VARCHAR(255),
Amount INT,
Feed BOOLEAN,
Zoo VARCHAR(255)
)
;
CREATE PROCEDURE helloWorld()
LANGUAGE JAVA
EXTERNAL NAME 'Derby7042.helloWorld'
PARAMETER STYLE JAVA
NO SQL
;
CREATE TRIGGER ZooUpdateTrigger
AFTER UPDATE ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloWorld()
;
CREATE TRIGGER ZooInsertTrigger
AFTER INSERT ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloWorld()
;
CREATE TRIGGER ZooDeleteTrigger
AFTER DELETE ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloWorld()
;
-- populate table
INSERT INTO ZOOANIMALS (Name, Amount, Feed, Zoo) VALUES ('Gorilla', 1, true,
'Cincinnati');
SELECT * FROM ZooAnimals;
-- reboot just in case the documentation lies about the properties being dynamic
connect 'jdbc:derby:memory:db1;shutdown=true';
connect 'jdbc:derby:memory:db1';
-- update table
UPDATE ZooAnimals SET Name = 'Aardvark' WHERE Zoo = 'Cincinnati';
SELECT * FROM ZooAnimals;
{noformat}
Here is the output of the script when run against 10.15.1.3:
{noformat}
ij version 10.15
ij> connect 'jdbc:derby:memory:db1;create=true';
ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.storage.rowLocking',
'false');
0 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.locks.deadlockTimeout',
'5');
0 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY('derby.locks.waitTimeout', '5');
0 rows inserted/updated/deleted
ij> -- create schema
CREATE TABLE ZooAnimals
(
Name VARCHAR(255),
Amount INT,
Feed BOOLEAN,
Zoo VARCHAR(255)
)
;
0 rows inserted/updated/deleted
ij> CREATE PROCEDURE helloWorld()
LANGUAGE JAVA
EXTERNAL NAME 'Derby7042.helloWorld'
PARAMETER STYLE JAVA
NO SQL
;
0 rows inserted/updated/deleted
ij> CREATE TRIGGER ZooUpdateTrigger
AFTER UPDATE ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloWorld()
;
0 rows inserted/updated/deleted
ij> CREATE TRIGGER ZooInsertTrigger
AFTER INSERT ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloWorld()
;
0 rows inserted/updated/deleted
ij> CREATE TRIGGER ZooDeleteTrigger
AFTER DELETE ON ZOOANIMALS FOR EACH STATEMENT MODE DB2SQL
CALL helloWorld()
;
0 rows inserted/updated/deleted
ij> -- populate table
INSERT INTO ZOOANIMALS (Name, Amount, Feed, Zoo) VALUES ('Gorilla', 1, true,
'Cincinnati');
Hello World
1 row inserted/updated/deleted
ij> SELECT * FROM ZooAnimals;
NAME
|AMOUNT |FEED |ZOO
---
Gorilla
|1 |true |Cincinnati
1 row selected
ij> -- reboot just in case the documentation lies about the properties being
dynamic
connect 'jdbc:derby:memory:db1;shutdown=true';
ERROR 08006: Database 'memory:db1' shutdown.
ij> connect 'jdbc:derby:memory:db1';
ij(CONNECTION1)> -- update table
UPDATE ZooAnimals SET Name = 'Aardvark' WHERE Zoo = 'Cincinnati';
Hello World
1 row inserted/updated/deleted
ij(CONNECTION1)> SELECT * FROM ZooAnimals;
NAME
|AMOUNT |FEED |ZOO
--
[jira] [Commented] (DERBY-7042) Multiple triggers with rowLocking = false causes deadlock
[
https://issues.apache.org/jira/browse/DERBY-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808236#comment-16808236
]
Rick Hillegas commented on DERBY-7042:
--
Attaching Derby7042.java--this is the Database.java class from the git site. I
have simply renamed the class. When I run the repro, it produces the following
output:
{noformat}
Hello World
Insert time: 15 seconds
Hello World
Update time: 15 seconds
Gorilla 3 true Cincinnati
Hello World
{noformat}
Can you explain how this is evidence of the bug? Thanks.
> Multiple triggers with rowLocking = false causes deadlock
> -
>
> Key: DERBY-7042
> URL: https://issues.apache.org/jira/browse/DERBY-7042
> Project: Derby
> Issue Type: Bug
> Components: Documentation, JDBC
>Affects Versions: 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.14.2.0, 10.15.1.3
> Environment: -- Java Information --
> Java Version:1.8.0_201
> Java Vendor: Oracle Corporation
> OS name: Linux
> OS architecture: i386
> OS version: 4.15.0-46-generic
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.8
> java.runtime.version: 1.8.0_201-b09
> - Derby Information
> [.../TriggerRepro/derby/derby-10.14.1.0.jar] 10.14.1.0 - (1808820)
>Reporter: Michael Schuetze
>Priority: Minor
> Labels: documentation, performance
> Attachments: Derby7042.java
>
>
> Repro for the bug can be found here:
> [https://github.com/mjschuetze102/TriggerRepro]
> Includes a detailed README of steps that show effect of bug as well as two
> versions of the Derby database. 10.8.1.2, the last version where the bug was
> not present and version 10.14.1.0, for easy access.
> This may just be an issue of not having enough documentation on database
> Triggers (see Conclusions Based on Results)
> h2. Summary of Issue
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes
> issues with deadlocking*
> # Executing Update trigger causes deadlock when there is an Insert or Delete
> trigger
> # Executing Insert trigger causes deadlock when there is a Delete trigger
> # Executing Delete trigger does not cause deadlock
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> # While executing issue above, none of the triggers were terminated and
> waitTimeout time was hit
> h2. Conclusions Based on Results
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes
> issues with deadlocking*
> Triggers seem to get into deadlock scenarios with any trigger defined after
> itself. If this is the case, it should be documented somewhere that
> rowLocking needs to be enabled to use the trigger feature if multiple
> triggers would be used on the same database table.
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> Based on documentation, I could not find any concrete evidence of whether
> this is intended functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7042) Multiple triggers with rowLocking = false causes deadlock
[
https://issues.apache.org/jira/browse/DERBY-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7042:
-
Attachment: Derby7042.java
> Multiple triggers with rowLocking = false causes deadlock
> -
>
> Key: DERBY-7042
> URL: https://issues.apache.org/jira/browse/DERBY-7042
> Project: Derby
> Issue Type: Bug
> Components: Documentation, JDBC
>Affects Versions: 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.14.2.0, 10.15.1.3
> Environment: -- Java Information --
> Java Version:1.8.0_201
> Java Vendor: Oracle Corporation
> OS name: Linux
> OS architecture: i386
> OS version: 4.15.0-46-generic
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.8
> java.runtime.version: 1.8.0_201-b09
> - Derby Information
> [.../TriggerRepro/derby/derby-10.14.1.0.jar] 10.14.1.0 - (1808820)
>Reporter: Michael Schuetze
>Priority: Minor
> Labels: documentation, performance
> Attachments: Derby7042.java
>
>
> Repro for the bug can be found here:
> [https://github.com/mjschuetze102/TriggerRepro]
> Includes a detailed README of steps that show effect of bug as well as two
> versions of the Derby database. 10.8.1.2, the last version where the bug was
> not present and version 10.14.1.0, for easy access.
> This may just be an issue of not having enough documentation on database
> Triggers (see Conclusions Based on Results)
> h2. Summary of Issue
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes
> issues with deadlocking*
> # Executing Update trigger causes deadlock when there is an Insert or Delete
> trigger
> # Executing Insert trigger causes deadlock when there is a Delete trigger
> # Executing Delete trigger does not cause deadlock
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> # While executing issue above, none of the triggers were terminated and
> waitTimeout time was hit
> h2. Conclusions Based on Results
> *Having multiple triggers with {{'derby.storage.rowLocking', 'false'}} causes
> issues with deadlocking*
> Triggers seem to get into deadlock scenarios with any trigger defined after
> itself. If this is the case, it should be documented somewhere that
> rowLocking needs to be enabled to use the trigger feature if multiple
> triggers would be used on the same database table.
> *{{'derby.locks.deadlockTimeout'}} does not seem to work in above case*
> Based on documentation, I could not find any concrete evidence of whether
> this is intended functionality.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808221#comment-16808221
]
Rick Hillegas commented on DERBY-7041:
--
I can port the patch to the 10.14 branch if that helps you. But you are
correct, I have no plans to manage a 10.14.2 release at this time.
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff, derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806745#comment-16806745
]
Rick Hillegas commented on DERBY-7041:
--
Tests passed cleanly for me on
derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff, modulo the usual
diffs I see in NetworkServerControlClientCommandTest and
InvalidLDAPServerAuthenticationTest.
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff, derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7041:
-
Attachment: derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff, derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806302#comment-16806302
]
Rick Hillegas commented on DERBY-7041:
--
Attaching derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff. This
patch makes view creation skip dependency registration between views and
system-supplied aggregates.
I will run the full test suite.
Touches the following files:
{noformat}
---
M
java/org.apache.derby.engine/org/apache/derby/impl/sql/compile/AggregateNode.java
Don't create a persistent dependency from a view to a user-defined
aggregate which is really a system-supplied aggregate implemented via
the user-defined aggregate machinery.
---
M
java/org.apache.derby.tests/org/apache/derbyTesting/functionTests/tests/lang/AggBuiltinTest.java
Add a test case verifying that the NPE has disappeared.
{noformat}
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041-01-aa-omitDependencyOnSystemSuppliedAggregate.diff, derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806301#comment-16806301
]
Rick Hillegas commented on DERBY-7041:
--
No NPE occurs when I substitute a user-defined aggregate for the STDDEV_SAMP.
So the object ID is disappearing only for the statistical aggregates as far as
I can see.
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (DERBY-7040) Add dependency stanzas to maven poms
[ https://issues.apache.org/jira/browse/DERBY-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas resolved DERBY-7040. -- Resolution: Fixed Fix Version/s: 10.15.1.4 > Add dependency stanzas to maven poms > > > Key: DERBY-7040 > URL: https://issues.apache.org/jira/browse/DERBY-7040 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Fix For: 10.15.1.4 > > Attachments: derby-7040-01-aa-addDependenciesToPOMs.diff > > > Add hard dependencies (from the module diagrams) to the poms under maven2. > The dependency stanza in the network server pom can be used as a template. In > particular, dependencies on derbyshared.jar should be listed. This issue was > raised by DERBY-7039. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (DERBY-7040) Add dependency stanzas to maven poms
[ https://issues.apache.org/jira/browse/DERBY-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas closed DERBY-7040. Assignee: Rick Hillegas > Add dependency stanzas to maven poms > > > Key: DERBY-7040 > URL: https://issues.apache.org/jira/browse/DERBY-7040 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Assignee: Rick Hillegas >Priority: Major > Fix For: 10.15.1.4 > > Attachments: derby-7040-01-aa-addDependenciesToPOMs.diff > > > Add hard dependencies (from the module diagrams) to the poms under maven2. > The dependency stanza in the network server pom can be used as a template. In > particular, dependencies on derbyshared.jar should be listed. This issue was > raised by DERBY-7039. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7040) Add dependency stanzas to maven poms
[
https://issues.apache.org/jira/browse/DERBY-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806275#comment-16806275
]
Rick Hillegas commented on DERBY-7040:
--
Attaching derby-7040-01-aa-addDependenciesToPOMs.diff. This patch adds hard
dependencies to the maven poms which are published at the end of a release. The
hard dependencies are the non-optional dependencies from the 10.15.1 module
diagrams.
It seems that these poms are consulted by projects which use maven as their
build tool. See the commentary on DERBY-7039.
Touches the following files:
{noformat}
M maven2/client/pom.xml
M maven2/engine/pom.xml
M maven2/net/pom.xml
M maven2/optionaltools/pom.xml
M maven2/tools/pom.xml
{noformat}
> Add dependency stanzas to maven poms
>
>
> Key: DERBY-7040
> URL: https://issues.apache.org/jira/browse/DERBY-7040
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7040-01-aa-addDependenciesToPOMs.diff
>
>
> Add hard dependencies (from the module diagrams) to the poms under maven2.
> The dependency stanza in the network server pom can be used as a template. In
> particular, dependencies on derbyshared.jar should be listed. This issue was
> raised by DERBY-7039.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7040) Add dependency stanzas to maven poms
[ https://issues.apache.org/jira/browse/DERBY-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7040: - Attachment: derby-7040-01-aa-addDependenciesToPOMs.diff > Add dependency stanzas to maven poms > > > Key: DERBY-7040 > URL: https://issues.apache.org/jira/browse/DERBY-7040 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7040-01-aa-addDependenciesToPOMs.diff > > > Add hard dependencies (from the module diagrams) to the poms under maven2. > The dependency stanza in the network server pom can be used as a template. In > particular, dependencies on derbyshared.jar should be listed. This issue was > raised by DERBY-7039. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806178#comment-16806178
]
Rick Hillegas commented on DERBY-7041:
--
The stack trace shows that the CREATE VIEW statement incurs an NPE while trying
to record a persistent dependency of the view on the STDDEV_SAMP aggregate:
{noformat}
java.lang.NullPointerException
at java.base/java.util.Hashtable.put(Hashtable.java:479)
at
org.apache.derby.iapi.sql.depend.ProviderList.addProvider(ProviderList.java:42)
at
org.apache.derby.impl.sql.compile.CompilerContextImpl.addProviderToAuxiliaryList(CompilerContextImpl.java:319)
at
org.apache.derby.impl.sql.compile.CompilerContextImpl.createDependency(CompilerContextImpl.java:290)
at
org.apache.derby.impl.sql.compile.AggregateNode.bindExpression(AggregateNode.java:404)
at
org.apache.derby.impl.sql.compile.JavaToSQLValueNode.bindExpression(JavaToSQLValueNode.java:237)
at
org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(ResultColumn.java:759)
at
org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(ResultColumnList.java:839)
at
org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:575)
at
org.apache.derby.impl.sql.compile.CreateViewNode.bindViewDefinition(CreateViewNode.java:255)
at
org.apache.derby.impl.sql.compile.CreateViewNode.bindStatement(CreateViewNode.java:175)
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:401)
at
org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:99)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:1114)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:689)
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:637)
at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:372)
at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:534)
at
org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:375)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:251)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:229)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184)
at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
at org.apache.derby.tools.ij.main(ij.java:59)
{noformat}
This happens because we implemented the statistical aggregates as user defined
aggregates and because the aggregate descriptor has a NULL object ID.
Two things look odd here and could serve as the basis for a fix:
* There should be no need to declare a persistent dependency between a
user-defined view and a system-supplied aggregate.
* The aggregate descriptor, nonetheless, should have a real object ID.
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_D
[jira] [Commented] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805881#comment-16805881
]
Rick Hillegas commented on DERBY-7041:
--
Attaching derby-7041.sql, a simpler script for the problem.
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-7041:
-
Attachment: derby-7041.sql
> null pointer exception when creating view based on other views
> --
>
> Key: DERBY-7041
> URL: https://issues.apache.org/jira/browse/DERBY-7041
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.14.2.0
> Environment: max os x , intellij
>Reporter: Manuel Rossetti
>Priority: Major
> Attachments: JSLDb.sql, JSLDb.sql, JSLDb_DriveThroughPharmacy.zip,
> derby-7041.sql
>
>
> I can execute a SELECT query that works but when I try to create a view on
> that select query, I simply get a java null pointer exception with no
> details. I have tested the same statements on a postgres database and they
> worked without error.
> Below, the PW_DIFF_WITHIN_REP_VIEW create does work, but the
> PW_DIFF_AR_REP_VIEW does not. Again, the SELECT clause of
> PW_DIFF_AR_REP_VIEW will work, but when used within the create clause the
> error occurs.
> I have attached the entire database creation script and an embedded instance
> that can be used for testing. It has data.
>
> -- WITHIN_REP_VIEW combines the WITHIN_REP_COUNTER_VIEW and
> WITHIN_REP_RESPONSE_VIEW into one table from which across
> -- replication or other statistical summaries by replication can be produced
> CREATE VIEW JSL_DB.WITHIN_REP_VIEW (SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, VALUE) AS
> (SELECT JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, AVERAGE AS VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_STAT.ELEMENT_ID_FK
> UNION
> SELECT JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK, EXP_NAME, ELEMENT_NAME,
> STAT_NAME, REP_NUM, LAST_VALUE as VALUE
> FROM (JSL_DB.SIMULATION_RUN JOIN JSL_DB.WITHIN_REP_COUNTER_STAT on
> JSL_DB.SIMULATION_RUN.ID = JSL_DB.WITHIN_REP_COUNTER_STAT.SIM_RUN_ID_FK)
> JOIN JSL_DB.MODEL_ELEMENT ON ELEMENT_ID =
> JSL_DB.WITHIN_REP_COUNTER_STAT.ELEMENT_ID_FK);
>
> -- PW_DIFF_WITHIN_REP_VIEW computes the pairwise differences across
> difference simulation experiments
> -- doesn't work for derby, 3-28-2019, works for postgres
> --
> -- create view JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- as (select SIMULATION_RUN.SIM_NAME, A.SIM_RUN_ID_FK AS A_SIM_NUM,
> A.STAT_NAME, A.EXP_NAME as A_EXP_NAME, A.REP_NUM, A.VALUE as A_VALUE,
> -- B.SIM_RUN_ID_FK as B_SIM_NUM, B.EXP_NAME as B_EXP_NAME, B.VALUE as B_VALUE,
> -- '(' || A.EXP_NAME || ' - ' || B.EXP_NAME || ')' as DIFF_NAME, (A.VALUE -
> B.VALUE) as A_MINUS_B
> -- from JSL_DB.WITHIN_REP_VIEW as A, JSL_DB.WITHIN_REP_VIEW as B,
> JSL_DB.SIMULATION_RUN
> -- where A.SIM_RUN_ID_FK = JSL_DB.SIMULATION_RUN.ID
> -- and A.STAT_NAME = B.STAT_NAME
> -- and A.REP_NUM = B.REP_NUM
> -- and A.SIM_RUN_ID_FK > B.SIM_RUN_ID_FK
> -- and A.ELEMENT_NAME = B.ELEMENT_NAME);
> --
> -- create view JSL_DB.PW_DIFF_AR_REP_VIEW (SIM_NAME, STAT_NAME, A_EXP_NAME,
> B_EXP_NAME, DIFF_NAME, AVG_A, STD_DEV_A,
> -- AVG_B, STD_DEV_B, AVG_DIFF_A_MINUS_B, STD_DEV_DIFF_A_MINUS_B, STAT_COUNT)
> -- as (select SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME,
> AVG(A_VALUE) as AVG_A, STDDEV_SAMP(A_VALUE) as STD_DEV_A,
> -- AVG(B_VALUE) as AVG_B, STDDEV_SAMP(B_VALUE) as STD_DEV_B,
> -- AVG(A_MINUS_B) as AVG_DIFF_A_MINUS_B, STDDEV_SAMP(A_MINUS_B) as
> STD_DEV_DIFF_A_MINUS_B,
> -- COUNT(A_MINUS_B) as STAT_COUNT
> -- from JSL_DB.PW_DIFF_WITHIN_REP_VIEW
> -- group by SIM_NAME, STAT_NAME, A_EXP_NAME, B_EXP_NAME, DIFF_NAME);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7041) null pointer exception when creating view based on other views
[
https://issues.apache.org/jira/browse/DERBY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804427#comment-16804427
]
Rick Hillegas commented on DERBY-7041:
--
I'm afraid that the attached script raises other compile-time errors for me and
it does not fail on an NPE. Here is the output from running the script as
provided with the problem CREATE statement uncommented:
{noformat}
ij> connect 'jdbc:derby:db;create=true';
WARNING 01J01: Database 'db' not created, connection made to existing database
instead.
ij> CREATE SCHEMA JSL_DB;
0 rows inserted/updated/deleted
ij> -- SIMULATION_RUN captures the execution of a simulation experiment and its
related options
CREATE TABLE JSL_DB.SIMULATION_RUN (
ID INTEGER NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY (START
WITH 1 INCREMENT BY 1),
SIM_NAME VARCHAR(510) NOT NULL,
MODEL_NAME VARCHAR(510) NOT NULL,
EXP_NAME VARCHAR(510) NOT NULL,
EXP_START_TIME_STAMP TIMESTAMP,
EXP_END_TIME_STAMP TIMESTAMP,
NUM_REPS INTEGER NOT NULL CHECK (NUM_REPS >=1),
LAST_REP INTEGER,
LENGTH_OF_REP DOUBLE PRECISION,
LENGTH_OF_WARM_UP DOUBLE PRECISION,
HAS_MORE_REPS BOOLEAN,
REP_ALLOWED_EXEC_TIME BIGINT,
REP_INIT_OPTION BOOLEAN,
RESET_START_STREAM_OPTION BOOLEAN,
ANTITHETIC_OPTION BOOLEAN,
ADV_NEXT_SUB_STREAM_OPTION BOOLEAN,
NUM_STREAM_ADVANCES INTEGER
);
0 rows inserted/updated/deleted
ij> ALTER TABLE JSL_DB.SIMULATION_RUN
ADD CONSTRAINT SR_NAME_EXP_UNIQUE UNIQUE (SIM_NAME, EXP_NAME);
0 rows inserted/updated/deleted
ij> -- MODEL_ELEMENT represents the model element hierarchy associated with
various
-- simulation runs, i.e. the model elements in the model and their parent/child
-- relationship. LEFT_COUNT and RIGHT_COUNT uses Joe Celko's SQL for Smarties
-- Advanced SQL Programming Chapter 36 to implement the nested set model for
-- the hierarchy. This allows statistics associated with hierarchical
aggregations
-- and subtrees of the model element hierarchy to be more easily queried.
CREATE TABLE JSL_DB.MODEL_ELEMENT (
SIM_RUN_ID_FK INTEGER NOT NULL,
ELEMENT_ID INTEGER NOT NULL,
ELEMENT_NAME VARCHAR(510) NOT NULL,
CLASS_NAME VARCHAR(510) NOT NULL,
PARENT_ID_FK INTEGER,
PARENT_NAME VARCHAR(510),
LEFT_COUNT INTEGER NOT NULL CHECK (LEFT_COUNT > 0),
RIGHT_COUNT INTEGER NOT NULL CHECK (RIGHT_COUNT > 1),
CONSTRAINT TRAVERSAL_ORDER_OKAY CHECK (LEFT_COUNT < RIGHT_COUNT)
);
0 rows inserted/updated/deleted
ij> ALTER TABLE JSL_DB.MODEL_ELEMENT
ADD CONSTRAINT ME_PRIM_KY PRIMARY KEY (SIM_RUN_ID_FK, ELEMENT_ID);
0 rows inserted/updated/deleted
ij> ALTER TABLE JSL_DB.MODEL_ELEMENT
ADD CONSTRAINT ME_NAME_UNIQUE UNIQUE (SIM_RUN_ID_FK, ELEMENT_NAME);
0 rows inserted/updated/deleted
ij> ALTER TABLE JSL_DB.MODEL_ELEMENT
ADD CONSTRAINT ME_SIMRUN_FK FOREIGN KEY (SIM_RUN_ID_FK) REFERENCES
JSL_DB.SIMULATION_RUN (ID) ON DELETE CASCADE;
0 rows inserted/updated/deleted
ij> CREATE INDEX ME_SIMRUN_FK_INDEX ON JSL_DB.MODEL_ELEMENT(SIM_RUN_ID_FK);
0 rows inserted/updated/deleted
WARNING 01504: 'ME_SIMRUN_FK_INDEX' index not created because it is a duplicate
of an existing index: 'SQL07-a666c073-0169-c691-93ab-07295718'.
ij> -- WITHIN_REP_STAT represents within replication statistics for each
replication of
-- each simulation for each response
CREATE TABLE JSL_DB.WITHIN_REP_STAT (
ID INTEGER NOT NULL PRIMARY KEY GENERATED ALWAYS AS IDENTITY (START
WITH 1 INCREMENT BY 1),
ELEMENT_ID_FK INTEGER NOT NULL,
SIM_RUN_ID_FK INTEGER NOT NULL,
REP_NUM INTEGER NOT NULL CHECK (REP_NUM >=1),
STAT_NAME VARCHAR(510),
STAT_COUNT DOUBLE PRECISION CHECK (STAT_COUNT >=0),
AVERAGE DOUBLE PRECISION,
MINIMUM DOUBLE PRECISION,
MAXIMUM DOUBLE PRECISION,
WEIGHTED_SUM DOUBLE PRECISION,
SUM_OF_WEIGHTS DOUBLE PRECISION,
WEIGHTED_SSQ DOUBLE PRECISION,
LAST_VALUE DOUBLE PRECISION,
LAST_WEIGHT DOUBLE PRECISION
);
0 rows inserted/updated/deleted
ij> ALTER TABLE JSL_DB.WITHIN_REP_STAT
ADD CONSTRAINT WRS_SIMRUN_FK FOREIGN KEY (SIM_RUN_ID_FK) REFERENCES
JSL_DB.SIMULATION_RUN (ID) ON DELETE CASCADE;
0 rows inserted/updated/deleted
ij> ALTER TABLE JSL_DB.WITHIN_REP_STAT
ADD CONSTRAINT WRS_UNIQUE_ELEMENT_SIMRUN_REPNUM UNIQUE (ELEMENT_ID_FK,
SIM_RUN_ID_FK, REP_NUM);
0 rows inserted/updated/deleted
ij> ALTER TABLE JSL_DB.WITHIN_REP_STAT
ADD CONSTRAINT WRS_MODEL_ELEMENT_FK FOREIGN KEY (SIM_RUN_ID_FK, ELEMENT_ID_FK)
REFERENCES JSL_DB.MODEL_ELEMENT (SIM_RUN_ID_FK, ELEMENT_ID) ON DELETE CASCADE;
0 rows inserted/updated/deleted
ij> CREATE INDEX WRS_ME_FK_INDEX ON JSL_DB.WITHIN_REP_STAT(SIM_RUN_ID_FK,
ELEMENT_ID_FK);
0 rows inserted/updated/deleted
WARNING 01504: 'WRS_ME_FK_INDEX' index not
[jira] [Commented] (DERBY-7039) DataSource classes removed from derby.jar
[ https://issues.apache.org/jira/browse/DERBY-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802877#comment-16802877 ] Rick Hillegas commented on DERBY-7039: -- Thanks for raising the issue with the maven poms. I have opened DERBY-7040 to track the work of aligning Derby's maven dependency descriptors with the hard dependencies in the module diagrams. Note, however, that this will not address your issue with applications failing to build against 10.15.1.3 because the DataSources moved into the tools jar. If your application uses DataSources, then it should explicitly depend on the tools jar. There is another reason for moving the embedded DataSource out of the engine jar: The DataSource api depends on the java.naming module. In the interests of keeping the smallest (embedded) configuration as lean as possible, we did not want to create a dependency between the engine module and java.naming. Via the java.sql.DriverManager api, it should be possible to run Derby on a resource-constrained device without pulling in java.naming. > DataSource classes removed from derby.jar > - > > Key: DERBY-7039 > URL: https://issues.apache.org/jira/browse/DERBY-7039 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.15.1.3 >Reporter: Andy Guibert >Priority: Major > > Between versions 10.14.X and 10.15.X the DataSource implementation classes > under the org.apache.derby.jdbc package were removed from the derby.jar. It > looks like the DataSource classes were moved to derbytools.jar, which has a > dependency on the derbynetwork.jar: > [https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.tools/module-summary.html] > This makes it impossible to use just a Derby Embedded DataSource, without > pulling in all of the Derby Network Client code too. > It appears this change was made for the sake of modularity, since split > packages are not allowed in JPMS modules, and the org.apache.derby.jdbc > package contains DataSource classes for both Embedded and Network usage. I am > not sure what the best way to untangle this dependency issue is, but ideally > it can be done in a way that doesn't require dependencies on Derby Embedded > and Network clients in order to use DataSource at all. > One possible suggestion is to introduce new DataSource classes in new > packages, such as: > org.apache.derby.jdbc.embedded // for Embedded DataSource classes > org.apache.derby.jdbc.network // for Network Client DataSources > Then, gut out the DataSource classes in org.apache.derby.jdbc and have them > extend from their respective embedded/network implementations. This will > allow existing users to add more dependencies and leave their code unchanged, > or it will allow users who just want to depend on Embedded or Network clients > to update the DataSource class name. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DERBY-7040) Add dependency stanzas to maven poms
Rick Hillegas created DERBY-7040: Summary: Add dependency stanzas to maven poms Key: DERBY-7040 URL: https://issues.apache.org/jira/browse/DERBY-7040 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.15.1.3 Reporter: Rick Hillegas Add hard dependencies (from the module diagrams) to the poms under maven2. The dependency stanza in the network server pom can be used as a template. In particular, dependencies on derbyshared.jar should be listed. This issue was raised by DERBY-7039. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7039) DataSource classes removed from derby.jar
[ https://issues.apache.org/jira/browse/DERBY-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802287#comment-16802287 ] Rick Hillegas commented on DERBY-7039: -- You are right, the DataSources moved up into the tools jar in order to preserve the backward compatibility of the Derby public API and to achieve the package partitioning required by JPMS. This move was discussed on DERBY-6945 beginning on 2017-12-28. The tools module does NOT have a hard dependency on either the engine or the client jars. I see that this may not be obvious simply from studying the module diagram at https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.tools/module-summary.html. That diagram follows the coloring conventions described at http://db.apache.org/derby/docs/10.15/publishedapi/index.html: light-gray-colored modules are optional dependencies. Blue- and black-colored modules are hard dependencies. You do NOT need the client jar in order to run Derby embedded. You only need the following: * The engine jar (derby.jar) * The shared jar (derbyshared.jar) If you want to access Derby via the embedded DataSources, you only need one additional jar file: * The tools jar (derbytools.jar). That, at least, is how things are supposed to work. Have you discovered a coupling between the engine and client jars which prevents you from running your application with just derby.jar, derbyshared.jar, and derbytools.jar? Thanks, -Rick > DataSource classes removed from derby.jar > - > > Key: DERBY-7039 > URL: https://issues.apache.org/jira/browse/DERBY-7039 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.15.1.3 >Reporter: Andy Guibert >Priority: Major > > Between versions 10.14.X and 10.15.X the DataSource implementation classes > under the org.apache.derby.jdbc package were removed from the derby.jar. It > looks like the DataSource classes were moved to derbytools.jar, which has a > dependency on the derbynetwork.jar: > [https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.tools/module-summary.html] > This makes it impossible to use just a Derby Embedded DataSource, without > pulling in all of the Derby Network Client code too. > It appears this change was made for the sake of modularity, since split > packages are not allowed in JPMS modules, and the org.apache.derby.jdbc > package contains DataSource classes for both Embedded and Network usage. I am > not sure what the best way to untangle this dependency issue is, but ideally > it can be done in a way that doesn't require dependencies on Derby Embedded > and Network clients in order to use DataSource at all. > One possible suggestion is to introduce new DataSource classes in new > packages, such as: > org.apache.derby.jdbc.embedded // for Embedded DataSource classes > org.apache.derby.jdbc.network // for Network Client DataSources > Then, gut out the DataSource classes in org.apache.derby.jdbc and have them > extend from their respective embedded/network implementations. This will > allow existing users to add more dependencies and leave their code unchanged, > or it will allow users who just want to depend on Embedded or Network clients > to update the DataSource class name. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7039) DataSource classes removed from derby.jar
[ https://issues.apache.org/jira/browse/DERBY-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7039: - Urgency: Normal (was: Urgent) > DataSource classes removed from derby.jar > - > > Key: DERBY-7039 > URL: https://issues.apache.org/jira/browse/DERBY-7039 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.15.1.3 >Reporter: Andy Guibert >Priority: Major > > Between versions 10.14.X and 10.15.X the DataSource implementation classes > under the org.apache.derby.jdbc package were removed from the derby.jar. It > looks like the DataSource classes were moved to derbytools.jar, which has a > dependency on the derbynetwork.jar: > [https://db.apache.org/derby/docs/10.15/publishedapi/org.apache.derby.tools/module-summary.html] > This makes it impossible to use just a Derby Embedded DataSource, without > pulling in all of the Derby Network Client code too. > It appears this change was made for the sake of modularity, since split > packages are not allowed in JPMS modules, and the org.apache.derby.jdbc > package contains DataSource classes for both Embedded and Network usage. I am > not sure what the best way to untangle this dependency issue is, but ideally > it can be done in a way that doesn't require dependencies on Derby Embedded > and Network clients in order to use DataSource at all. > One possible suggestion is to introduce new DataSource classes in new > packages, such as: > org.apache.derby.jdbc.embedded // for Embedded DataSource classes > org.apache.derby.jdbc.network // for Network Client DataSources > Then, gut out the DataSource classes in org.apache.derby.jdbc and have them > extend from their respective embedded/network implementations. This will > allow existing users to add more dependencies and leave their code unchanged, > or it will allow users who just want to depend on Embedded or Network clients > to update the DataSource class name. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7038) Upgrade ant version and re-write javadoc build targets to use improved task
[ https://issues.apache.org/jira/browse/DERBY-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7038: - Urgency: Normal > Upgrade ant version and re-write javadoc build targets to use improved > task > > > Key: DERBY-7038 > URL: https://issues.apache.org/jira/browse/DERBY-7038 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.16.0.0 >Reporter: Rick Hillegas >Assignee: Rick Hillegas >Priority: Major > > Version 1.10.6 of ant will enhance the task in order to understand > some of the module-aware switches introduced by Java 9. Currently, our > javadoc targets work around the limitations of the task by running > javadoc via the task. We should upgrade our version of ant and > re-write the javadoc targets to take advantage of the improvements introduced > by ant 1.10.16 (see > https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html). I > imagine this work will occur in 3 phases: > 1) Upgrade the Jenkins scripts to require ant 1.10.6. > 2) Upgrade our build scripts to require ant 1.10.6. > 3) Re-wire our javadoc targets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DERBY-7038) Upgrade ant version and re-write javadoc build targets to use improved task
Rick Hillegas created DERBY-7038: Summary: Upgrade ant version and re-write javadoc build targets to use improved task Key: DERBY-7038 URL: https://issues.apache.org/jira/browse/DERBY-7038 Project: Derby Issue Type: Improvement Components: Build tools Affects Versions: 10.16.0.0 Reporter: Rick Hillegas Assignee: Rick Hillegas Version 1.10.6 of ant will enhance the task in order to understand some of the module-aware switches introduced by Java 9. Currently, our javadoc targets work around the limitations of the task by running javadoc via the task. We should upgrade our version of ant and re-write the javadoc targets to take advantage of the improvements introduced by ant 1.10.16 (see https://dist.apache.org/repos/dist/dev/ant/RELEASE-NOTES-1.10.6.html). I imagine this work will occur in 3 phases: 1) Upgrade the Jenkins scripts to require ant 1.10.6. 2) Upgrade our build scripts to require ant 1.10.6. 3) Re-wire our javadoc targets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7037) NPEx at InternalTriggerExecutionContext.updateAICounters
[ https://issues.apache.org/jira/browse/DERBY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793611#comment-16793611 ] Rick Hillegas commented on DERBY-7037: -- Can you script a repro for this problem? > NPEx at InternalTriggerExecutionContext.updateAICounters > > > Key: DERBY-7037 > URL: https://issues.apache.org/jira/browse/DERBY-7037 > Project: Derby > Issue Type: Bug >Affects Versions: 10.12.1.1, 10.13.1.1, 10.14.2.0, 10.15.1.3 > Environment: Linux, openjdk 8 & 9 >Reporter: Piotr Zygielo >Priority: Major > > AFTER UPDATE trigger fails when the column of source table is autogenerated. > Bisected issue to fat commit > [a826375a|https://github.com/apache/derby/commit/a826375a5482ff797e90b93a83b12173964fd181] > (DERBY-6414). After that change NPEx is observed and update statement is > forcibly prevented with current connection being closed. > Logs from example executions: [at > Travis|https://travis-ci.org/pzrep/derby_npex_trigger/builds/505226771], with > simple SQLs available on GitHub. > Edit: as checked on [more complex > case|https://travis-ci.org/pzrep/derby_npex_trigger/builds/505297229], > reordering columns is not enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7037) NPEx at InternalTriggerExecutionContext.updateAICounters
[ https://issues.apache.org/jira/browse/DERBY-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793609#comment-16793609 ] Rick Hillegas commented on DERBY-7037: -- Thanks for the bug report. If your bisection is correct, then the bug was introduced by https://issues.apache.org/jira/browse/DERBY-6414?focusedCommentId=14138457&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14138457 at subversion 1625884. > NPEx at InternalTriggerExecutionContext.updateAICounters > > > Key: DERBY-7037 > URL: https://issues.apache.org/jira/browse/DERBY-7037 > Project: Derby > Issue Type: Bug >Affects Versions: 10.12.1.1, 10.13.1.1, 10.14.2.0, 10.15.1.3 > Environment: Linux, openjdk 8 & 9 >Reporter: Piotr Zygielo >Priority: Major > > AFTER UPDATE trigger fails when the column of source table is autogenerated. > Bisected issue to fat commit > [a826375a|https://github.com/apache/derby/commit/a826375a5482ff797e90b93a83b12173964fd181] > (DERBY-6414). After that change NPEx is observed and update statement is > forcibly prevented with current connection being closed. > Logs from example executions: [at > Travis|https://travis-ci.org/pzrep/derby_npex_trigger/builds/505226771], with > simple SQLs available on GitHub. > Edit: as checked on [more complex > case|https://travis-ci.org/pzrep/derby_npex_trigger/builds/505297229], > reordering columns is not enough. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792708#comment-16792708 ] Rick Hillegas commented on DERBY-7010: -- Commit derby-7010-25-aa-fixBrokenVerificationLinkOnWebsite.diff: source: 1855529 generated website: 1041845 > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff, > derby-7010-21-aa-updateSTATUSpage.diff, > derby-7010-22-aa-updateLinkToKEYS.diff, derby-7010-23-aa-updateKEYShref.diff, > derby-7010-24-aa-fixVerifyLink.diff, > derby-7010-25-aa-fixBrokenVerificationLinkOnWebsite.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7010: - Attachment: derby-7010-25-aa-fixBrokenVerificationLinkOnWebsite.diff > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff, > derby-7010-21-aa-updateSTATUSpage.diff, > derby-7010-22-aa-updateLinkToKEYS.diff, derby-7010-23-aa-updateKEYShref.diff, > derby-7010-24-aa-fixVerifyLink.diff, > derby-7010-25-aa-fixBrokenVerificationLinkOnWebsite.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[
https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792704#comment-16792704
]
Rick Hillegas commented on DERBY-7010:
--
Attaching derby-7010-25-aa-fixBrokenVerificationLinkOnWebsite.diff. This patch
fixes the broken "verify the integrity" link on the 10.15.1.3 download page.
Touches the following files:
{noformat}
X build/site
M src/documentation/content/xdocs/releases/release-10.15.1.3.html
M build/site/releases/release-10.15.1.3.html
{noformat}
> Tasks for creating a 10.15.1 release
>
>
> Key: DERBY-7010
> URL: https://issues.apache.org/jira/browse/DERBY-7010
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7010-01-aa-initialReleaseNotes.diff,
> derby-7010-02-aa-releaseNotesForExistingUsers.diff,
> derby-7010-03-aa-bumpTrunkTo10.16.diff,
> derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff,
> derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff,
> derby-7010-06-aa-backoutPreviousWebsiteChange.diff,
> derby-7010-07-aa-updateDocsCopyrightYear.diff,
> derby-7010-08-aa-releaseNotesFor10.15.1.1.diff,
> derby-7010-09-aa-releaseNotesFor10.15.1.2.diff,
> derby-7010-10-aa-releaseNotesFor10.15.1.3.diff,
> derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff,
> derby-7010-13-aa-changeChecksumNameOnWebsite.diff,
> derby-7010-14-aa-correctTypeInMavenInstructions.diff,
> derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff,
> derby-7010-15-aa-updateDOAP.diff,
> derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff,
> derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff,
> derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff,
> derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff,
> derby-7010-21-aa-updateSTATUSpage.diff,
> derby-7010-22-aa-updateLinkToKEYS.diff, derby-7010-23-aa-updateKEYShref.diff,
> derby-7010-24-aa-fixVerifyLink.diff,
> derby-7010-25-aa-fixBrokenVerificationLinkOnWebsite.diff
>
>
> This issue is a place holder for tasks related to producing a 10.15.1 release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7010: - Attachment: derby-7010-24-aa-fixVerifyLink.diff > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff, > derby-7010-21-aa-updateSTATUSpage.diff, > derby-7010-22-aa-updateLinkToKEYS.diff, derby-7010-23-aa-updateKEYShref.diff, > derby-7010-24-aa-fixVerifyLink.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[
https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792655#comment-16792655
]
Rick Hillegas commented on DERBY-7010:
--
Attaching derby-7010-24-aa-fixVerifyLink.diff. This patch fixes the broken
"verify the integrity" link generated by the release notes transformer.
Touches the following files:
{noformat}
M java/build/org/apache/derbyBuild/ReleaseNotesTransformer.java
{noformat}
> Tasks for creating a 10.15.1 release
>
>
> Key: DERBY-7010
> URL: https://issues.apache.org/jira/browse/DERBY-7010
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7010-01-aa-initialReleaseNotes.diff,
> derby-7010-02-aa-releaseNotesForExistingUsers.diff,
> derby-7010-03-aa-bumpTrunkTo10.16.diff,
> derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff,
> derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff,
> derby-7010-06-aa-backoutPreviousWebsiteChange.diff,
> derby-7010-07-aa-updateDocsCopyrightYear.diff,
> derby-7010-08-aa-releaseNotesFor10.15.1.1.diff,
> derby-7010-09-aa-releaseNotesFor10.15.1.2.diff,
> derby-7010-10-aa-releaseNotesFor10.15.1.3.diff,
> derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff,
> derby-7010-13-aa-changeChecksumNameOnWebsite.diff,
> derby-7010-14-aa-correctTypeInMavenInstructions.diff,
> derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff,
> derby-7010-15-aa-updateDOAP.diff,
> derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff,
> derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff,
> derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff,
> derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff,
> derby-7010-21-aa-updateSTATUSpage.diff,
> derby-7010-22-aa-updateLinkToKEYS.diff, derby-7010-23-aa-updateKEYShref.diff,
> derby-7010-24-aa-fixVerifyLink.diff
>
>
> This issue is a place holder for tasks related to producing a 10.15.1 release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791758#comment-16791758 ] Rick Hillegas commented on DERBY-7010: -- Committed derby-7010-23-aa-updateKEYShref.diff: website source 1855429 generated website pages 1041781 > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff, > derby-7010-21-aa-updateSTATUSpage.diff, > derby-7010-22-aa-updateLinkToKEYS.diff, derby-7010-23-aa-updateKEYShref.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7010: - Attachment: derby-7010-23-aa-updateKEYShref.diff > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff, > derby-7010-21-aa-updateSTATUSpage.diff, > derby-7010-22-aa-updateLinkToKEYS.diff, derby-7010-23-aa-updateKEYShref.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[
https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791754#comment-16791754
]
Rick Hillegas commented on DERBY-7010:
--
Attaching derby-7010-23-aa-updateKEYShref.diff. This patch updates release
page, changing the href to the KEYS file as infrastructure advised.
Touches the following files:
{noformat}
X build/site
M src/documentation/content/xdocs/releases/release-10.15.1.3.html
M build/site/releases/release-10.15.1.3.html
{noformat}
> Tasks for creating a 10.15.1 release
>
>
> Key: DERBY-7010
> URL: https://issues.apache.org/jira/browse/DERBY-7010
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7010-01-aa-initialReleaseNotes.diff,
> derby-7010-02-aa-releaseNotesForExistingUsers.diff,
> derby-7010-03-aa-bumpTrunkTo10.16.diff,
> derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff,
> derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff,
> derby-7010-06-aa-backoutPreviousWebsiteChange.diff,
> derby-7010-07-aa-updateDocsCopyrightYear.diff,
> derby-7010-08-aa-releaseNotesFor10.15.1.1.diff,
> derby-7010-09-aa-releaseNotesFor10.15.1.2.diff,
> derby-7010-10-aa-releaseNotesFor10.15.1.3.diff,
> derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff,
> derby-7010-13-aa-changeChecksumNameOnWebsite.diff,
> derby-7010-14-aa-correctTypeInMavenInstructions.diff,
> derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff,
> derby-7010-15-aa-updateDOAP.diff,
> derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff,
> derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff,
> derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff,
> derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff,
> derby-7010-21-aa-updateSTATUSpage.diff,
> derby-7010-22-aa-updateLinkToKEYS.diff, derby-7010-23-aa-updateKEYShref.diff
>
>
> This issue is a place holder for tasks related to producing a 10.15.1 release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[
https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791158#comment-16791158
]
Rick Hillegas commented on DERBY-7010:
--
Attaching derby-7010-22-aa-updateLinkToKEYS.diff. This patch updates the
location of the KEYS file in the xml source for the release page, per a new
directive from infrastructure.
Touches the following file:
{noformat}
M releaseSummary.xml
{noformat}
> Tasks for creating a 10.15.1 release
>
>
> Key: DERBY-7010
> URL: https://issues.apache.org/jira/browse/DERBY-7010
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7010-01-aa-initialReleaseNotes.diff,
> derby-7010-02-aa-releaseNotesForExistingUsers.diff,
> derby-7010-03-aa-bumpTrunkTo10.16.diff,
> derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff,
> derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff,
> derby-7010-06-aa-backoutPreviousWebsiteChange.diff,
> derby-7010-07-aa-updateDocsCopyrightYear.diff,
> derby-7010-08-aa-releaseNotesFor10.15.1.1.diff,
> derby-7010-09-aa-releaseNotesFor10.15.1.2.diff,
> derby-7010-10-aa-releaseNotesFor10.15.1.3.diff,
> derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff,
> derby-7010-13-aa-changeChecksumNameOnWebsite.diff,
> derby-7010-14-aa-correctTypeInMavenInstructions.diff,
> derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff,
> derby-7010-15-aa-updateDOAP.diff,
> derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff,
> derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff,
> derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff,
> derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff,
> derby-7010-21-aa-updateSTATUSpage.diff, derby-7010-22-aa-updateLinkToKEYS.diff
>
>
> This issue is a place holder for tasks related to producing a 10.15.1 release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7010: - Attachment: derby-7010-22-aa-updateLinkToKEYS.diff > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff, > derby-7010-21-aa-updateSTATUSpage.diff, derby-7010-22-aa-updateLinkToKEYS.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[
https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791149#comment-16791149
]
Rick Hillegas commented on DERBY-7010:
--
Attaching derby-7010-21-aa-updateSTATUSpage.diff. This patch updates the STATUS
file.
Touches the following file:
{noformat}
M STATUS
{noformat}
> Tasks for creating a 10.15.1 release
>
>
> Key: DERBY-7010
> URL: https://issues.apache.org/jira/browse/DERBY-7010
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7010-01-aa-initialReleaseNotes.diff,
> derby-7010-02-aa-releaseNotesForExistingUsers.diff,
> derby-7010-03-aa-bumpTrunkTo10.16.diff,
> derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff,
> derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff,
> derby-7010-06-aa-backoutPreviousWebsiteChange.diff,
> derby-7010-07-aa-updateDocsCopyrightYear.diff,
> derby-7010-08-aa-releaseNotesFor10.15.1.1.diff,
> derby-7010-09-aa-releaseNotesFor10.15.1.2.diff,
> derby-7010-10-aa-releaseNotesFor10.15.1.3.diff,
> derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff,
> derby-7010-13-aa-changeChecksumNameOnWebsite.diff,
> derby-7010-14-aa-correctTypeInMavenInstructions.diff,
> derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff,
> derby-7010-15-aa-updateDOAP.diff,
> derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff,
> derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff,
> derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff,
> derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff,
> derby-7010-21-aa-updateSTATUSpage.diff
>
>
> This issue is a place holder for tasks related to producing a 10.15.1 release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7010: - Attachment: derby-7010-21-aa-updateSTATUSpage.diff > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff, > derby-7010-21-aa-updateSTATUSpage.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790594#comment-16790594 ] Rick Hillegas commented on DERBY-7010: -- Commit derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff: repository: svn 1855329 generated web pages: svn 1041716 > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[
https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790575#comment-16790575
]
Rick Hillegas commented on DERBY-7010:
--
Attaching derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff. This changes
http: to https: in releaseSummary.xml so that future release notes will be more
secure.
Touches the following files:
{noformat}
M RELEASE-NOTES.html
M releaseSummary.xml
{noformat}
> Tasks for creating a 10.15.1 release
>
>
> Key: DERBY-7010
> URL: https://issues.apache.org/jira/browse/DERBY-7010
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7010-01-aa-initialReleaseNotes.diff,
> derby-7010-02-aa-releaseNotesForExistingUsers.diff,
> derby-7010-03-aa-bumpTrunkTo10.16.diff,
> derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff,
> derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff,
> derby-7010-06-aa-backoutPreviousWebsiteChange.diff,
> derby-7010-07-aa-updateDocsCopyrightYear.diff,
> derby-7010-08-aa-releaseNotesFor10.15.1.1.diff,
> derby-7010-09-aa-releaseNotesFor10.15.1.2.diff,
> derby-7010-10-aa-releaseNotesFor10.15.1.3.diff,
> derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff,
> derby-7010-13-aa-changeChecksumNameOnWebsite.diff,
> derby-7010-14-aa-correctTypeInMavenInstructions.diff,
> derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff,
> derby-7010-15-aa-updateDOAP.diff,
> derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff,
> derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff,
> derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff
>
>
> This issue is a place holder for tasks related to producing a 10.15.1 release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[
https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790586#comment-16790586
]
Rick Hillegas commented on DERBY-7010:
--
Attaching derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff. This
changes http: to https: on the website download page.
Touches the following files:
{noformat}
X build/site
M src/documentation/content/xdocs/releases/release-10.15.1.3.html
M build/site/releases/release-10.15.1.3.html
{noformat}
> Tasks for creating a 10.15.1 release
>
>
> Key: DERBY-7010
> URL: https://issues.apache.org/jira/browse/DERBY-7010
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7010-01-aa-initialReleaseNotes.diff,
> derby-7010-02-aa-releaseNotesForExistingUsers.diff,
> derby-7010-03-aa-bumpTrunkTo10.16.diff,
> derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff,
> derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff,
> derby-7010-06-aa-backoutPreviousWebsiteChange.diff,
> derby-7010-07-aa-updateDocsCopyrightYear.diff,
> derby-7010-08-aa-releaseNotesFor10.15.1.1.diff,
> derby-7010-09-aa-releaseNotesFor10.15.1.2.diff,
> derby-7010-10-aa-releaseNotesFor10.15.1.3.diff,
> derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff,
> derby-7010-13-aa-changeChecksumNameOnWebsite.diff,
> derby-7010-14-aa-correctTypeInMavenInstructions.diff,
> derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff,
> derby-7010-15-aa-updateDOAP.diff,
> derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff,
> derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff,
> derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff,
> derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff
>
>
> This issue is a place holder for tasks related to producing a 10.15.1 release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7010: - Attachment: derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff, > derby-7010-20-aa-changeHttpToHttpsOnWebsiteDownloadPage.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7010: - Attachment: derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff, > derby-7010-19-aa-changeHttpToHttpsInReleaseSummary.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (DERBY-7010) Tasks for creating a 10.15.1 release
[ https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-7010: - Attachment: derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff > Tasks for creating a 10.15.1 release > > > Key: DERBY-7010 > URL: https://issues.apache.org/jira/browse/DERBY-7010 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Affects Versions: 10.15.1.3 >Reporter: Rick Hillegas >Priority: Major > Attachments: derby-7010-01-aa-initialReleaseNotes.diff, > derby-7010-02-aa-releaseNotesForExistingUsers.diff, > derby-7010-03-aa-bumpTrunkTo10.16.diff, > derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff, > derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff, > derby-7010-06-aa-backoutPreviousWebsiteChange.diff, > derby-7010-07-aa-updateDocsCopyrightYear.diff, > derby-7010-08-aa-releaseNotesFor10.15.1.1.diff, > derby-7010-09-aa-releaseNotesFor10.15.1.2.diff, > derby-7010-10-aa-releaseNotesFor10.15.1.3.diff, > derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff, > derby-7010-13-aa-changeChecksumNameOnWebsite.diff, > derby-7010-14-aa-correctTypeInMavenInstructions.diff, > derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff, > derby-7010-15-aa-updateDOAP.diff, > derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff, > derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff > > > This issue is a place holder for tasks related to producing a 10.15.1 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DERBY-7010) Tasks for creating a 10.15.1 release
[
https://issues.apache.org/jira/browse/DERBY-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790565#comment-16790565
]
Rick Hillegas commented on DERBY-7010:
--
Attaching derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff. This will
change the links on future download pages from http: to https:
Touches the following file:
{noformat}
M java/build/org/apache/derbyBuild/ReleaseNotesTransformer.java
{noformat}
> Tasks for creating a 10.15.1 release
>
>
> Key: DERBY-7010
> URL: https://issues.apache.org/jira/browse/DERBY-7010
> Project: Derby
> Issue Type: Task
> Components: Miscellaneous
>Affects Versions: 10.15.1.3
>Reporter: Rick Hillegas
>Priority: Major
> Attachments: derby-7010-01-aa-initialReleaseNotes.diff,
> derby-7010-02-aa-releaseNotesForExistingUsers.diff,
> derby-7010-03-aa-bumpTrunkTo10.16.diff,
> derby-7010-04-aa-add10.16toWebsiteListOfBranches.diff,
> derby-7010-05-aa-updateReleaseNotesTo10.15.1.0.diff,
> derby-7010-06-aa-backoutPreviousWebsiteChange.diff,
> derby-7010-07-aa-updateDocsCopyrightYear.diff,
> derby-7010-08-aa-releaseNotesFor10.15.1.1.diff,
> derby-7010-09-aa-releaseNotesFor10.15.1.2.diff,
> derby-7010-10-aa-releaseNotesFor10.15.1.3.diff,
> derby-7010-11-aa-fixIssueSummary.diff, derby-7010-12-aa-updateWarPom.diff,
> derby-7010-13-aa-changeChecksumNameOnWebsite.diff,
> derby-7010-14-aa-correctTypeInMavenInstructions.diff,
> derby-7010-15-aa-addCommonsModuleToDeploymentPOM.diff,
> derby-7010-15-aa-updateDOAP.diff,
> derby-7010-16-aa-add10.15.1.3ToUpgradeTest.diff, derby-7010-17-aa-news.diff,
> derby-7010-18-aa-changeHttpToHttpsOnReleasePage.diff
>
>
> This issue is a place holder for tasks related to producing a 10.15.1 release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
