[jira] [Commented] (DERBY-6858) Apache Derby simple update statement performance becomes 1500% worse when adding one byte to a column

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15154152#comment-15154152
 ] 

Myrna van Lunteren commented on DERBY-6858:
---

darkassassin98/somebody,

Your frustration is clear as is the fact that it is a blocker for you.

Bryan and Rick have volunteered their time and agree there is a problem. 
They've not found an easy solution.

The maximum of escalation is to click on the 'vote for this issue' in JIRA.

Please look at this page: http://db.apache.org/derby/derby_comm.html
You can see there this: 
What is Apache not about?
To [...] demand someone else to fix your bugs.

The tenet of open source is that we all get wonderful software because everyone 
involved will address their own issues, and the combined result is a better 
product. And at no cost if you hit no issues.

So far no one has indicated they have time to work on this further. If you are 
not able to work on fixing this issue yourself either, perhaps you can find a 
friend to work on this issue for you. 
If you are volunteering your time to fix this yourself please start by looking 
at this page:
http://db.apache.org/derby/derby_comm.html#Contribute+Code+or+Documentation

> Apache Derby simple update statement performance becomes 1500% worse when 
> adding one byte to a column
> -
>
> Key: DERBY-6858
> URL: https://issues.apache.org/jira/browse/DERBY-6858
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.11.1.1, 10.12.1.1
> Environment: windows 7 64 bit
>Reporter: somebody
>Priority: Blocker
> Attachments: repro.java, repro.java, repro.java
>
>
> I have 2 tables as follows:
> ParentUpdate
> name varchar(255)
> value int not null
> primary key: name
> ChildUpdate
> parentName varchar(255)
> name varchar(255)
> value int
> data varchar(1000)
> primary key: name foreign key: parentName to ParentUpdate.name
> When I run the statement "update ChildUpdate set parentName = 'Parent 2' 
> where parentName = 'Parent 1'" with 2500 records in the ChildUpdate table and 
> 1 record in the ParentUpdate table with only a single byte difference in data 
> size in the ChildUpdate table, the performance decreases by 15 times.
> When the ChildUpdate data column has exactly 14 bytes of the same character 
> the runtime of the above query is about 500 milliseconds. When I add one more 
> byte to the data column of ChildUpdate the performance all of a sudden 
> becomes about 7500 milliseconds.
> If i then decrease the data size back to 14 from 15 it's fast again. When i 
> put it back to 15 it's slow again. This is reproducible every time.
> Can you please help me figure out how to get the same fast performance 
> without such seemingly random behaviour.
> The query plans are below for both cases.
> projection = true
> constructor time (milliseconds) = 0
> open time (milliseconds) = 0
> next time (milliseconds) = 16
> close time (milliseconds) = 16
> restriction time (milliseconds) = 0
> projection time (milliseconds) = 0
> optimizer estimated row count: 51.50
> optimizer estimated cost: 796.12
> Source result set:
> Table Scan ResultSet for CHILDUPDATE at read committed isolation 
> level using exclusive row locking chosen by the optimizer
> Number of opens = 1
> Rows seen = 2500
> Rows filtered = 0
> Fetch Size = 1
> constructor time (milliseconds) = 0
> open time (milliseconds) = 15
> next time (milliseconds) = 16
> close time (milliseconds) = 16
> next time in milliseconds/row = 0
> scan information:
> Bit set of columns fetched={0, 1}
> Number of columns fetched=2
> Number of pages visited=41
> Number of rows qualified=2500
> Number of rows visited=2500
> Scan type=heap
> start position:
> null
> stop position:
> null
> qualifiers:
> Column[0][0] Id: 0
> Operator: =
> Ordered nulls: false
> Unknown return value: false
> Negate comparison result: false
> optimizer estimated row count: 51.50
> optimizer estimated cost:

Re: [VOTE] 10.12.1.1 release

[Myrna van Lunteren]

+1 Thanks to everyone who contributed to this release.

On Thu, Oct 1, 2015 at 8:45 PM, Katherine Marsden <
kmarsdende...@sbcglobal.net> wrote:

> On 9/20/2015 10:14 AM, Richard Hillegas wrote:
>
>> Please test-drive the 10.12.1.1 candidate, then vote on whether to accept
>> it as a Derby release.
>>
> +1
>
> I ran suites.All and derbyall on Windows 7 IBM Java 8 and regression tests
> ran fine.  Thanks to all that contributed to the release.
>
> Kathey
>
>
>

Re: are there any daily public test results being published for derby any more?

[Myrna van Lunteren]

Hi Mike,

Indeed, the tests are no longer running at IBM. I've left the link thinking
it might be useful, perhaps.

I guess the same is true at Oracle...

There are still the Jenkins runs. Perhaps we should update that page to
include a link?

I usually go to the main apache jenkins environment and go to the dashboard
and search for 'Derby'.
Can you see the contents of this page? I think it likely requires a login.
https://builds.apache.org/view/Most%20Recent%20Builds/search/?q=Derby
Looks like someone added an entry for the 10.12 branch build, but doesn't
look like there's a suites.all run (yet).

Myrna


On Sun, Oct 4, 2015 at 7:00 PM, mike matrigali  wrote:

> I wanted to get a feel about history of test results on trunk for the
> upcoming release.  In the
> past I have gone to this page to find test results:
> https://db.apache.org/derby/derby_tests.html
>
> The oracle results give a bad link and the ibm results have not been
> updated since march.
> This is not surprising  given that both ibm and oracle have reduced or
> eliminated their derby support.
>
> Just checking if there is another place to find this info.  I know derby
> it tied into the per change
> build system.  maybe there are tests run also or could be?
>
> --
> email:Mike Matrigali - mikema...@gmail.com
> linkedin: https://www.linkedin.com/in/MikeMatrigali
>
>

Re: are there any daily public test results being published for derby any more?

[Myrna van Lunteren]

I added a Derby -10.12- suites.all jenkins job by copying from the Derby
10-11-suites.all job.

I didn't add a link to that tests page, waiting for input on what would be
a good reference. Plus it's an actual web page, not a wiki, we need to
rebuild the site to make changes, I think?

Myrna

[jira] [Updated] (DERBY-5466) Add support for SQL Standard statistics functions, such as STDDEV_POP, STDDEV_SAMP, VAR_POP, VAR_SAMP

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-5466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-5466:
--
Assignee: Scott Lewis

> Add support for SQL Standard statistics functions, such as STDDEV_POP, 
> STDDEV_SAMP, VAR_POP, VAR_SAMP
> -
>
> Key: DERBY-5466
> URL: https://issues.apache.org/jira/browse/DERBY-5466
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.8.1.2
>Reporter: Lukas Eder
>Assignee: Scott Lewis
>Priority: Minor
>  Labels: derby_triage10_10
> Fix For: 10.12.1.1
>
> Attachments: DERBY-5466.stats.patch, DERBY.5466.aggtest.patch, 
> derby-5466-01-aa-aggregatorClasses.diff, derby-5466-02-aa-bindLogic.diff, 
> derby-5466-02-ab-bindLogic.diff, derby-5466-03-aa-distinctError.diff, 
> var_pop_formulas.txt
>
>
> Any of these RDBMS support the SQL standard statistics functions STDDEV_POP, 
> STDDEV_SAMP, VAR_POP, VAR_SAMP:
> - DB2 (only STDDEV, VARIANE)
> - H2 
> - HSQLDB 
> - Ingres 
> - MySQL 
> - Oracle 
> - Postgres 
> - SQL Server (named STDEVP, STDEV, VARP, VAR)
> - Sybase ASE
> - Sybase SQL Anywhere
> These don't:
> - Derby
> - SQLite
> This would be a useful addition for Derby, I think.
> An even larger example list of possible statistics aggregate functions is 
> listed in the Postgres documentation:
> http://www.postgresql.org/docs/9.0/static/functions-aggregate.html#FUNCTIONS-AGGREGATE-STATISTICS-TABLE



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6830) Add user documentation for var_pop(), var_samp(), stddev_pop(), and stddev_samp()

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942905#comment-14942905
 ] 

Myrna van Lunteren commented on DERBY-6830:
---

Rick, this looks completed, or is there more work to be done?

> Add user documentation for var_pop(), var_samp(), stddev_pop(), and 
> stddev_samp()
> -
>
> Key: DERBY-6830
> URL: https://issues.apache.org/jira/browse/DERBY-6830
> Project: Derby
>  Issue Type: Improvement
>  Components: Documentation
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-6830-01-aa-refguide.diff, 
> derby-6830-01-aa-refguide.tar, derby-6830-01-ab-refguide.diff
>
>
> Add user documentation for the new aggregates added by DERBY-5466.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: 10.12.1.1 polls close tomorrow

[Myrna van Lunteren]

Hi Rick,

I am hoping to be done by tomorrow 5 pm PDT.
I kicked off one long (well, not very long) running test case, but will
need to analyze.
Also I wanted to take a quick look at the new functions from DERBY-5466.

Myrna

On Sun, Oct 4, 2015 at 10:54 AM, Rick Hillegas 
wrote:

> Gentle reminder that voting ends at 5:00 pm San Francisco time tomorrow.
> Let us know if you plan to vote but need more time to finish your testing.
>
> Thanks,
> -Rick
>

build failure because of jardriftcheck

[Myrna van Lunteren]

Hi,

I noticed a recent commit caused a build failure in the jardriftcheck.

I put that in because of DERBY-6471 (
https://issues.apache.org/jira/browse/DERBY-6471); Create a regression test
which will fail if classes from one Derby jar file leak into another jar
file.

At the time I tried to get input from the community, but there was no
response, so I went ahead and put it in as an 'always' check.
But if this check is too much work to run on the jars everytime we try to
add a file (e.g. a test), then we can of course remove it from the
buildjars target in build.xml, and for instance only run it before a
release.

Myrna

Re: Internal Derby Javadoc links on the website are broken

[Myrna van Lunteren]

I think that's reasonable, thanks Bryan.

Myrna

On Tue, May 19, 2015 at 8:45 PM, Bryan Pendleton bpendleton.de...@gmail.com
 wrote:

 On 5/19/2015 7:50 PM, Myrna van Lunteren wrote:

 I could see the output by going to the derby builds overview (
 https://builds.apache.org/view/A-D/view/Derby/)


 Thanks Myrna, that works for me, too.

 Perhaps the simplest thing to do is to change the links on

 http://db.apache.org/derby/manuals/index.html#javadoc

 to point to, e.g.,


 https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk/lastSuccessfulBuild/artifact/trunk/javadoc/

 If that seems like a reasonable approach, I can do that.

 bryan

Re: Internal Derby Javadoc links on the website are broken

[Myrna van Lunteren]

Interesting.
I could see the output by going to the derby builds overview (
https://builds.apache.org/view/A-D/view/Derby/) and drilling down into the
workspace, e.g.
https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk/ws/trunk/javadoc/engine/index.html
(note; you need to log on, I don't think everyone has access to this).

But there are no links from the top level.

I kicked off a trunk build, perhaps that will fix the issue.

Myrna


On Tue, May 19, 2015 at 6:32 PM, Bryan Pendleton bpendleton.de...@gmail.com
 wrote:

 Hi all,

 I was recently trying to chase down the online Javadoc on the web site,
 which is referenced here:

 http://db.apache.org/derby/manuals/index.html#javadoc

 These links point here:


 https://builds.apache.org/job/Derby-trunk/lastSuccessfulBuild/artifact/trunk/javadoc/engine/index.html


 https://builds.apache.org/job/Derby-trunk/lastSuccessfulBuild/artifact/trunk/javadoc/language/sqlgrammar.html


 https://builds.apache.org/job/Derby-trunk/lastSuccessfulBuild/artifact/trunk/javadoc/testing/index.html


 https://builds.apache.org/job/Derby-trunk/lastSuccessfulBuild/artifact/trunk/javadoc/tools/ij.html

 Is it known that these links are broken?

 Is there anything we can do to put them back online?

 thanks,

 bryan

Fwd: Derby dependencies on JDK-Internal APIs

[Myrna van Lunteren]

Hi folks,

I just got this message, probably because I'm still listed as the PMC
chair. I currently have no time to look into this, can anyone else free up
any time?

Myrna

-- Forwarded message --
From: Rory O'Donnell rory.odonn...@oracle.com
Date: Tue, May 19, 2015 at 1:50 AM
Subject: Derby dependencies on JDK-Internal APIs
To: m.v.lunte...@gmail.com
Cc: rory.odonn...@oracle.com, Dalibor Topic dalibor.to...@oracle.com,
Balchandra Vaidya balchandra.vai...@oracle.com



Hi Myrna,

My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead.

I'm contacting you because your open source project seems to be a very
popular dependency for other open source projects.
As part of the preparations for JDK 9, Oracle’s engineers have been
analyzing open source projects like yours to understand usage. One area of
concern involves identifying compatibility problems, such as reliance on
JDK-internal APIs.

Our engineers have already prepared guidance on migrating some of the more
common usage patterns of JDK-internal APIs to supported public interfaces.
The list is on the OpenJDK wiki [0].

As part of the ongoing development of JDK 9, I would like to inquire about
your usage of  JDK-internal APIs and to encourage migration towards
supported Java APIs if necessary.

The first step is to identify if your application(s) is leveraging internal
APIs.

  *Step 1: Download JDeps. *

Just download a preview release of JDK8(JDeps Download
https://jdk8.java.net/download.html). You do not need to actually test or
run your application on JDK8.  JDeps(Docs
http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html)
looks through JAR files and identifies which JAR files use internal APIs
and then lists those APIs.

  *Step 2: To run JDeps against an application*. The command looks like:

jdk8/bin/jdeps -P -jdkinternals *.jar  your-application.jdeps.txt

The output inside your-application.jdeps.txt will look like:

your.package (Filename.jar)
  - com.sun.corba.seJDK internal API (rt.jar)

*3rd party library using Internal APIs:*
If your analysis uncovers a third-party component that you rely on, you can
contact the provider and let them know of the upcoming changes. You can
then either work with the provider to get an updated library that won't
rely on Internal APIs, or you can find an alternative provider for the
capabilities that the offending library provides.

*Dynamic use of Internal APIs:*
JDeps can not detect dynamic use of internal APIs, for example through
reflection, service loaders and similar mechanisms.

Rgds,Rory

[0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[jira] [Closed] (DERBY-4944) Embedded Derby does not start when derby.jar is dynamically uploaded / added to the classpath

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-4944.
-
   Resolution: Fixed
Fix Version/s: 10.7.1.4
 Assignee: Dag H. Wanvik  (was: Myrna van Lunteren)

Closing again. Although the build at apache failed, that seemed to be because 
of a problem with ant, not with derby, and it worked fine in my environment 
when I ran suites.All.

 Embedded Derby does not start when derby.jar is dynamically uploaded / added 
 to the classpath
 -

 Key: DERBY-4944
 URL: https://issues.apache.org/jira/browse/DERBY-4944
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.6.2.1
 Environment: various windows versions, jdk1.6.0 and 1.5.0
Reporter: Michael Dobrovnik
Assignee: Dag H. Wanvik
Priority: Minor
 Fix For: 10.7.1.4, 10.8.1.2

 Attachments: BDFF.diff


 Hi, 
 For our workflow-system, we can use a variety of DBMS as the store engine. 
 Derby is one of them especially popular
 for test and development purposes. During setup of our system, we allow to 
 upload a jar file with the JDBC-Driver for the DBMS.
 In case of derby, we use the embedded mode and upload derby.jar. After that 
 we add the jar to the repositories of our class loader
 and call 
 Class drc = Class.forName(org.apache.derby.jdbc.EmbeddedDriver, true, 
 ourclassloader);
 Driver drv = (Driver)drc.newInstance();
 this worked perfectly for many years up to version 10.6.1.0, but ceased to 
 work in 10.6.2.1; 
 i assume the unreleased future versions are affected, too
 when derby.jar is placed in the classpath manually before starting our setup, 
 everything works fine regardless of the derby version.
 investigations lead to the following conclusion:
 - since rev. 982370 this is broken, in the immediate predecessor rev. 980035  
 it worked.
 - rev. 982370 in  the 
 org.apache.derby.impl.store.raw.data.BaseDataFileFactory class introduced a 
 new method
 private static String jarClassPath(final Class cls) which tries to find 
 the jarfile from which derby was loaded.
   it contains the following lines: 
 if ( cs == null )
   return null;
 URL result = cs.getLocation();
 return result.toString();
   but in the case, when we dynamically load derby, 
   cs is not null but cs.getLocation() is null. so i propose to change the 
 line with the if to:
 ...
 if ( cs == null || cs.getLocation()==null)
   return null;
 ...
 or maybe it would be better to surround the whole body of the method with a 
 try catch, since it is not essential, and a null 
 return value is also ok?
 thank you for your efforts concerning derby at large, 
 Michael



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6797) If a (machine/jvm) crash happens during hard upgrade, derby does not roll back the upgrade.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-6797:
--
Attachment: Prepare4Upgrade.java
HardUpgradeAbort.java
AfterUpgrade.java

attaching a few classes that could be used to manually test this.
Would require to change DD_version in the new version to that it does fail 
somewhere.
The programs are:
- Prepare4Upgrade: prepare (run with an older Derby version)
- HardUpgradeAbort: upgrade (with the modified newer version)
- AfterUpgrade: check (with the old version; if the failed upgrade would be 
correctly rolled back you should not get a connection (version upgraded).).

Note that when using trunk you need to pass the property 
derby.database.allowPreReleaseUpgrade=true to the program because trunk is 
always at alpha.

 If a (machine/jvm) crash happens during hard upgrade, derby does not roll 
 back the upgrade.
 ---

 Key: DERBY-6797
 URL: https://issues.apache.org/jira/browse/DERBY-6797
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.11.1.3, 10.12.0.0
Reporter: Myrna van Lunteren
 Attachments: AfterUpgrade.java, DERBY-6797.diff, 
 HardUpgradeAbort.java, Prepare4Upgrade.java


 When a crash happens during hard upgrade of derby, the upgrade -up to that 
 point - is not rolled back. Depending on where the crash happens this might 
 leave a broken database behind.
 This makes it extra important to create a backup before doing a hard upgrade.
 I have not tested this with a soft upgrade.
 I will attach a test case which uses the upgrade test suite framework and 
 uses a call of SanityManager.DEBUG_SET(upgrade_abort) to send a flag, and a 
 change in impl/sql/catalog/DD_version to listen for this flag.
 Thus, it's only a test that would run in a sane environment.
 But this test does show that even if we see the error during hard upgrade, 
 the resulting database appears to be in the newer version. I have manually 
 tested this with 10.11 (by modifying DD_version in 10.11 to throw the error 
 regardless of sanity manager or not) and with 10.12 by running my new test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14347368#comment-14347368
 ] 

Myrna van Lunteren commented on DERBY-6792:
---

It's been a while since we heard on this issue, is it still a problem?

 Could not execute JDBC batch update
 ---

 Key: DERBY-6792
 URL: https://issues.apache.org/jira/browse/DERBY-6792
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.8.3.3
 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux
Reporter: Raja
Priority: Critical
 Attachments: Derby_error.txt, derby.log, derbyserver.out

   Original Estimate: 72h
  Remaining Estimate: 72h

 We are using Derby v10.8.3.3 for our product CastIron. Our customer is 
 getting the following error in their production environment.
 SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] 
 [com.approuter.maestro.vm.Task] Internal error: 
 org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch 
 update
 org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch 
 update
   at 
 org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
   at 
 org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
   at 
 org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
   at 
 org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222)
   at 
 org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354)
   at 
 org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
   at 
 org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
   at 
 org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
   at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
   at 
 org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
   at 
 org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
   at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
   at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
   at 
 org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
   at 
 com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363)
   at com.approuter.maestro.vm.Task.commit(Task.java:1136)
   at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280)
   at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
   at java.lang.reflect.Method.invoke(Method.java:611)
   at 
 com.approuter.maestro.activities.Instruction.call(Instruction.java:45)
   at com.approuter.maestro.vm.Program.call(Program.java:596)
   at com.approuter.maestro.vm.Task.run(Task.java:692)
   at com.approuter.maestro.vm.Task.run(Task.java:631)
   at 
 com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
   at java.util.concurrent.FutureTask.run(FutureTask.java:149)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:217)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
   at java.lang.Thread.run(Thread.java:761)
 --
 Need quick analysis and solution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DERBY-6797) If a (machine/jvm) crash happens during hard upgrade, derby does not roll back the upgrade.

[Myrna van Lunteren (JIRA)]

Myrna van Lunteren created DERBY-6797:
-

 Summary: If a (machine/jvm) crash happens during hard upgrade, 
derby does not roll back the upgrade.
 Key: DERBY-6797
 URL: https://issues.apache.org/jira/browse/DERBY-6797
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.11.1.3, 10.12.0.0
Reporter: Myrna van Lunteren


When a crash happens during hard upgrade of derby, the upgrade -up to that 
point - is not rolled back. Depending on where the crash happens this might 
leave a broken database behind.

This makes it extra important to create a backup before doing a hard upgrade.

I have not tested this with a soft upgrade.

I will attach a test case which uses the upgrade test suite framework and uses 
a call of SanityManager.DEBUG_SET(upgrade_abort) to send a flag, and a change 
in impl/sql/catalog/DD_version to listen for this flag.
Thus, it's only a test that would run in a sane environment.

But this test does show that even if we see the error during hard upgrade, the 
resulting database appears to be in the newer version. I have manually tested 
this with 10.11 (by modifying DD_version in 10.11 to throw the error regardless 
of sanity manager or not) and with 10.12 by running my new test.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6797) If a (machine/jvm) crash happens during hard upgrade, derby does not roll back the upgrade.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-6797:
--
Attachment: DERBY-6797.diff

attaching a patch with a test.

 If a (machine/jvm) crash happens during hard upgrade, derby does not roll 
 back the upgrade.
 ---

 Key: DERBY-6797
 URL: https://issues.apache.org/jira/browse/DERBY-6797
 Project: Derby
  Issue Type: Bug
  Components: Store
Affects Versions: 10.11.1.3, 10.12.0.0
Reporter: Myrna van Lunteren
 Attachments: DERBY-6797.diff


 When a crash happens during hard upgrade of derby, the upgrade -up to that 
 point - is not rolled back. Depending on where the crash happens this might 
 leave a broken database behind.
 This makes it extra important to create a backup before doing a hard upgrade.
 I have not tested this with a soft upgrade.
 I will attach a test case which uses the upgrade test suite framework and 
 uses a call of SanityManager.DEBUG_SET(upgrade_abort) to send a flag, and a 
 change in impl/sql/catalog/DD_version to listen for this flag.
 Thus, it's only a test that would run in a sane environment.
 But this test does show that even if we see the error during hard upgrade, 
 the resulting database appears to be in the newer version. I have manually 
 tested this with 10.11 (by modifying DD_version in 10.11 to throw the error 
 regardless of sanity manager or not) and with 10.12 by running my new test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Commented] (DERBY-6791) Google Summer of Code 2015: Derby bug fixing

[Myrna van Lunteren]

I took another look, but I do not seem to have the option to add anyone to
any groups.

I did add Abhinav to another 'Role', the role of 'DEVELOPER', but I don't
know if that will do the trick. I will contact infra, unless someone else
on the list knows how to do this?

Myrna

On Wed, Feb 25, 2015 at 6:56 AM, Bryan Pendleton (JIRA) j...@apache.org
wrote:


 [
 https://issues.apache.org/jira/browse/DERBY-6791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336574#comment-14336574
 ]

 Bryan Pendleton commented on DERBY-6791:
 

 Indeed, when I look at your profile, I also only see jira-users.

 Myrna, can you have another look ? Click on Abhinav's comment on this
 issue, and under more, you can view the profile from there.


  Google Summer of Code 2015: Derby bug fixing
  
 
  Key: DERBY-6791
  URL: https://issues.apache.org/jira/browse/DERBY-6791
  Project: Derby
   Issue Type: Improvement
   Components: JDBC, SQL, Store
 Reporter: Bryan Pendleton
   Labels: Java, database, gsoc2015, jdbc
  Attachments: Capture.PNG, derby.PNG, derby1.PNG
 
 
  For the 2015 Google Summer of Code, I am offering to mentor a
  student for general bug fixing of the Derby database.
  The Derby JIRA has collected the community's knowledge about
  known bugs in Derby, and there are plenty of bugs for us to work on.
  If you take on this project, with assistance from me, you'll:
  - select Derby issues from the Derby issue to fix
  - reproduce those problems by writing and running tests
  - develop patches to address the problems
  - work with the community to get the patches reviewed
  - have your reviewed and accepted contributions committed to the next
 Derby release.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

Re: [jira] [Commented] (DERBY-6791) Google Summer of Code 2015: Derby bug fixing

[Myrna van Lunteren]

Hi again,

After some browsing I found that Apache has moved away from the group-based
authorization scheme.
(see:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=23332792)

Unfortunately, it seems that in the default scheme, assigning issues to
oneself (or others, apparently there's no difference) is now a task for a
committer/pmc/administrator role.

It doesn't seem as if there's a separate role from assigning to oneself vs
to others.

One thing we *can* do is request to have the alternative scheme listed for
our project. I think we have to put in a request to infra for that, doesn't
look like anything I can change, the link has a lock icon.

For now, Abhinav, please tell us which bug you want assigned and a
committer can do this for you.


Myrna


On Wed, Feb 25, 2015 at 8:26 AM, Myrna van Lunteren m.v.lunte...@gmail.com
wrote:

 I took another look, but I do not seem to have the option to add anyone to
 any groups.

 I did add Abhinav to another 'Role', the role of 'DEVELOPER', but I don't
 know if that will do the trick. I will contact infra, unless someone else
 on the list knows how to do this?

 Myrna

 On Wed, Feb 25, 2015 at 6:56 AM, Bryan Pendleton (JIRA) j...@apache.org
 wrote:


 [
 https://issues.apache.org/jira/browse/DERBY-6791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14336574#comment-14336574
 ]

 Bryan Pendleton commented on DERBY-6791:
 

 Indeed, when I look at your profile, I also only see jira-users.

 Myrna, can you have another look ? Click on Abhinav's comment on this
 issue, and under more, you can view the profile from there.


  Google Summer of Code 2015: Derby bug fixing
  
 
  Key: DERBY-6791
  URL: https://issues.apache.org/jira/browse/DERBY-6791
  Project: Derby
   Issue Type: Improvement
   Components: JDBC, SQL, Store
 Reporter: Bryan Pendleton
   Labels: Java, database, gsoc2015, jdbc
  Attachments: Capture.PNG, derby.PNG, derby1.PNG
 
 
  For the 2015 Google Summer of Code, I am offering to mentor a
  student for general bug fixing of the Derby database.
  The Derby JIRA has collected the community's knowledge about
  known bugs in Derby, and there are plenty of bugs for us to work on.
  If you take on this project, with assistance from me, you'll:
  - select Derby issues from the Derby issue to fix
  - reproduce those problems by writing and running tests
  - develop patches to address the problems
  - work with the community to get the patches reviewed
  - have your reviewed and accepted contributions committed to the next
 Derby release.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)

Re: Request for getting included in derby-dev list on JIRA.

[Myrna van Lunteren]

I tried to add your name, it seemed JIRA wanted to go by email address -
can you please try it and see whether you can assign yourself issues now?

Myrna

On Sat, Feb 21, 2015 at 2:09 AM, Abhinav Gupta abhinavgupta2...@gmail.com
wrote:

 Hi,

 My Jira id is mac777 and I would like to contribute in Derby. Could you
 please add me to the derby-developers list on jira ?

 Thank you,

 Abhinav

Re: Gsoc2015 and suite runall file not found for few suites.

[Myrna van Lunteren]

On Wed, Feb 11, 2015 at 10:46 AM, Abhinav Gupta abhinavgupta2...@gmail.com
wrote:

 Also I intend to participate in gsoc2015. Apache Derby interests me and I
 would like to work on Derby-6791. Could you please guide me on how to
 participate, fix patches and write a proposal ?


Bryan has volunteered to mentor a project for GSoC2015. Please refer to the
JIRA issue created for this, it has a number of useful links.

https://issues.apache.org/jira/browse/DERBY-6791

Regards,
Myrna

[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14314463#comment-14314463
 ] 

Myrna van Lunteren commented on DERBY-6792:
---

If there is no space issue then this is likely related to the other report we 
had of a similar error.

So it is possible this started due to a bug, but we don't know for sure 
until/unless we can have an idea of what the sequence of events is that trigger 
this. There is no fix, nor a way to fix it.

Even if we had a fix for the possible bug, it would not fix the database.

I can see the following choices for you/your customer:
a. continue to limp with the database as is. It will not get better.
b. attempt to use the off line compress routine as I described before. There is 
a possibility this would repair the database, but that is not guaranteed.
c. use a back-up. 
d. create a new database. 

at d: You *might* be able to salvage data from the old database by exporting 
data from the database, or manually (e.g. using ij, or by writing a program) 
selecting data from each table.


 Could not execute JDBC batch update
 ---

 Key: DERBY-6792
 URL: https://issues.apache.org/jira/browse/DERBY-6792
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.8.3.3
 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux
Reporter: Raja
Priority: Critical
 Attachments: Derby_error.txt, derby.log, derbyserver.out

   Original Estimate: 72h
  Remaining Estimate: 72h

 We are using Derby v10.8.3.3 for our product CastIron. Our customer is 
 getting the following error in their production environment.
 SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] 
 [com.approuter.maestro.vm.Task] Internal error: 
 org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch 
 update
 org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch 
 update
   at 
 org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
   at 
 org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
   at 
 org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
   at 
 org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222)
   at 
 org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354)
   at 
 org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
   at 
 org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
   at 
 org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
   at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
   at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
   at 
 org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
   at 
 org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
   at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
   at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
   at 
 org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
   at 
 com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363)
   at com.approuter.maestro.vm.Task.commit(Task.java:1136)
   at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280)
   at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
   at java.lang.reflect.Method.invoke(Method.java:611)
   at 
 com.approuter.maestro.activities.Instruction.call(Instruction.java:45)
   at com.approuter.maestro.vm.Program.call(Program.java:596)
   at com.approuter.maestro.vm.Task.run(Task.java:692)
   at com.approuter.maestro.vm.Task.run(Task.java:631)
   at 
 com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
   at java.util.concurrent.FutureTask.run(FutureTask.java:149)
   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301

Re: Suit runall file not found for a few suits.

[Myrna van Lunteren]

On Mon, Feb 9, 2015 at 12:31 PM, Abhinav Gupta abhinavgupta2...@gmail.com
wrote:

 Hi,

 I was running Derby test and I was executing the test suites, but for
 derbynetmats, jdbcapi, jdbc20, jdbc4, jdk14, nist,  the message that I get
 is* **suit runall file not found *

 I have got No failures for most of the other tests. What can I do for the
 list of suits above ?

 Thank you very much :)

 Abhinav.


Hi,

The runall files are part of the 'old', master based testing harness as
described in the README.htm file under java/testing.
But the majority of the tests are now in junit format, and there the suites
are typically, but not always, part of the package and called _Suite.

What command exactly did you use to run those suites?

Please refer to http://wiki.apache.org/db-derby/DerbyJUnitTesting, and
http://wiki.apache.org/db-derby/DerbyTopLevelJunitTests

As Bryan suggested, If you are able to build (ant all) you should also be
able to run
ant junit-system-mini

This will just run a subset of the tests; ant junit-all will run all tests.
Note also that running individual package suite files will not always work,
ant junit-all
does some additional setup to make things work and runs all tests in
sequence.

Regards,
Myrna

[jira] [Commented] (DERBY-6793) Stream or LOG value cannot be retrieved more than once

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313029#comment-14313029
 ] 

Myrna van Lunteren commented on DERBY-6793:
---

Kristian worked on DERBY-5489, and it was noted in the release note that this 
change would possibly cause incompatibility for applications retrieving the 
same blob twice.

It seems this is documented incompatibility resulting from a necessary fix (the 
alternative was incorrect data retrieval). Perhaps Kristian can add more 
details. Or perhaps you have suggestions for a better approach...

 Stream or LOG value cannot be retrieved more than once
 --

 Key: DERBY-6793
 URL: https://issues.apache.org/jira/browse/DERBY-6793
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.11.1.1
 Environment: does not matter
Reporter: Sergey Zolotaryov
 Attachments: derby-bug.tar.gz


 Since migrating from derby 10.7.1.1 to 10.11.1.1 really innocent code stopped 
 working: retrieving resultset column data using column names if resultset 
 contains blobs stopped working.
 I am attaching a maven project with a unit test which proves the issue. If in 
 pom.xml you change the version to 10.7.1.1 the test will pass. We are using 
 spring-jdbc' queryForMap() which traverses resultset metadata and queries 
 attributes by their column labels. Used to work before.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

GSoC 2015 project

[Myrna van Lunteren]

Thanks Bryan for volunteering to mentor the project!
Please alert us if there is anything we can do to help this through the
process.

Myrna

[jira] [Commented] (DERBY-6792) Could not execute JDBC batch update

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14308279#comment-14308279
 ] 

Myrna van Lunteren commented on DERBY-6792:
---

That was my first idea too.

However, I did a search and found DERBY-6766, which has the same error.
Note that there was no fix for that situation, and the problem would reoccur. 
Mike had some ideas but no clear solution.
DERBY-6766 refers to an earlier issue which did get fixed, DERBY-4923, but 
looks like the build that you are on (10.8.3.3 - (1557911)) already has this 
fix.(was backported to the 10.8 branch with revision 1535576). 

I talked to Mike (because he commented on DERBY-6766) off-line about this issue 
and he said:
 In the past when this type of error has happened the page is kind of stuck 
in that state, so same error will happen over and over again if nothing else on 
the page changes.  From the stack it looks like the problem page is the base 
page of a row.  The  locking system of derby requires that updates to base page 
of a row leave the front of the row on the page.
If the update adds more data than fits what is supposed to happen is there 
should always be enough space in the row so that at worst you just leave a 
small pointer there and then link to other pages - that pointer is something on 
order of 16 bytes.  What is weird is that there is relatively a lot of free 
space on the page in this case freeSpace: 601, so not sure what is going on.  
If it can be reproduced likely would be easy to fix.

He also suggested that the problem would only be fixed for new data. So if the 
database was created with a previous build of 10.8.3.3, the problem could have 
gotten in and be still there.

So, follow up questions are:
- as Rick said, is the disk full (or was it full at one point?)
- does the problem reoccur, i.e. like Mike suggested, is the database 'stuck'?
- is the problem reproducible, i.e. going back to a backup or clean database, 
does the problem reoccur? Not sure if it's feasible to start with a clean 
database - this seemed to be happening for the folks of DERBY-6766.
- Does the CastIron application log also show the query that caused the 
problem? Is it similar to DERBY-6766 where there is a combination of updates 
and inserts?

One experiment that might possibly fix the current situation is to run offline 
compress on the affected table.
The table name can be found using the container id mentioned in the error 
message Rick quoted, so it's container (table, in this case, index would be a 
1) with id 1328. To get the table name, use a query like this:
SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME  FROM 
SYS.SYSCONGLOMERATES C, sys.sysschemas s  WHERE CONGLOMERATENUMBER = 1328 AND 
s.schemaid = C.schemaid ;
(documented on this page: 
http://wiki.apache.org/db-derby/DatabaseConsistencyCheck)

Information/syntax on how to run off line compress (call 
SYSCS_UTIL.SYSCS_COMPRESS_TABLE) can be found in the manuals (see: 
http://db.apache.org/derby/manuals/index.html#docs_10.8, Reference guide is a 
good starting point) but it's also mentioned on that same 
DatabaseConsistencyCheck wiki page mentioned above.

Of course, before doing anything with the database you should make a backup, or 
copy, so we can possibly analyze it.
On that note, is there a backup process in place?


 Could not execute JDBC batch update
 ---

 Key: DERBY-6792
 URL: https://issues.apache.org/jira/browse/DERBY-6792
 Project: Derby
  Issue Type: Bug
  Components: JDBC
Affects Versions: 10.8.3.3
 Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux
Reporter: Raja
Priority: Critical
 Attachments: Derby_error.txt, derby.log, derbyserver.out

   Original Estimate: 72h
  Remaining Estimate: 72h

 We are using Derby v10.8.3.3 for our product CastIron. Our customer is 
 getting the following error in their production environment.
 SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82] 
 [com.approuter.maestro.vm.Task] Internal error: 
 org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch 
 update
 org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch 
 update
   at 
 org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
   at 
 org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
   at 
 org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
   at 
 org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
   at 
 org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement

[jira] [Comment Edited] (DERBY-3005) Document possibility to specify method signature in EXTERNAL NAME when creating a procedure/function

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14292574#comment-14292574
 ] 

Myrna van Lunteren edited comment on DERBY-3005 at 1/26/15 10:59 PM:
-

updates are in the latest alpha manuals. resolving.


was (Author: myrna):
results are in the latest alpha manuals. resolving.

 Document possibility to specify method signature in EXTERNAL NAME when 
 creating a procedure/function
 

 Key: DERBY-3005
 URL: https://issues.apache.org/jira/browse/DERBY-3005
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.4.1.3
Reporter: Kristian Waagan
Assignee: Myrna van Lunteren
 Fix For: 10.12.0.0

 Attachments: DERBY-3005.diff, DERBY-3005_2.diff, 
 rrefsqljexternalname.html, rrefsqljexternalname.html


 In some cases it might be necessary to specify the method signature of the 
 external method used as a function or procedure in Derby (using CREATE 
 FUNCTION or CREATE PROCEDURE).
 This possibility is not documented in the manuals, but there is an entry in 
 the FAQ (http://db.apache.org/derby/faq.html#null_args):
 Either declare the function with RETURNS NULL ON NULL INPUT or define the 
 Java method signature in the external name clause. See the Create function 
 problem  derby-user mail list topic.
 The mail thread: 
 http://mail-archives.apache.org/mod_mbox/db-derby-user/200602.mbox/%3c4404e53d.1050...@apache.org%3e
 The relevant sections in the manuals should be updated to describe the 
 feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-3005) Document possibility to specify method signature in EXTERNAL NAME when creating a procedure/function

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren resolved DERBY-3005.
---
   Resolution: Fixed
Fix Version/s: 10.12.0.0

results are in the latest alpha manuals. resolving.

 Document possibility to specify method signature in EXTERNAL NAME when 
 creating a procedure/function
 

 Key: DERBY-3005
 URL: https://issues.apache.org/jira/browse/DERBY-3005
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.4.1.3
Reporter: Kristian Waagan
Assignee: Myrna van Lunteren
 Fix For: 10.12.0.0

 Attachments: DERBY-3005.diff, DERBY-3005_2.diff, 
 rrefsqljexternalname.html, rrefsqljexternalname.html


 In some cases it might be necessary to specify the method signature of the 
 external method used as a function or procedure in Derby (using CREATE 
 FUNCTION or CREATE PROCEDURE).
 This possibility is not documented in the manuals, but there is an entry in 
 the FAQ (http://db.apache.org/derby/faq.html#null_args):
 Either declare the function with RETURNS NULL ON NULL INPUT or define the 
 Java method signature in the external name clause. See the Create function 
 problem  derby-user mail list topic.
 The mail thread: 
 http://mail-archives.apache.org/mod_mbox/db-derby-user/200602.mbox/%3c4404e53d.1050...@apache.org%3e
 The relevant sections in the manuals should be updated to describe the 
 feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: want to start contributing

[Myrna van Lunteren]

Hi,

Welcome!

If you haven't already familiarized yourself with how to build and test
Derby, you should take a look at the Derby wiki (
http://wiki.apache.org/db-derby/ ) and, in particular, at the guidance for
newcomers ( http://wiki.apache.org/db-derby/DerbyDev ).
Also, a few years ago Siddharth Srivastava, then a Google Summer of Code
contributor, set up a wiki page that might help:
http://wiki.apache.org/db-derby/siddharthsrivastava/QuickStartGuide_NewDevelopers

If you are not familiar with JDBC, the following primers may help:
http://www.oracle.com/technetwork/java/javase/jdbc/index.html
http://www.herongyang.com/JDBC/
http://www.tecnun.es/asignaturas/InteInfo/Recursos/JDBC/JDBCShortCourse.pdf

The following issues have been marked as good for newcomers:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hiderequestId=12315169

Pose any general questions to the derby-dev mailing list. Questions on
specific issues posted in JIRA also are forwarded to the list.

Myrna



One good place is a wiki page set up a few years ago by

On Fri, Jan 23, 2015 at 7:26 AM, Yash Swarnkar yash01071...@gmail.com
wrote:

 hello! i am new here and want to start contributing to derby. I know
 c++ and core java. Can ANYONE GET ME STARTED?

[jira] [Assigned] (DERBY-5219) Make it possible to set the classpath of the Derby tests using the -cp command line arg instead of setting the CLASSPATH environment variable.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-5219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren reassigned DERBY-5219:
-

Assignee: (was: Jayaram Subramanian)

Unassigning - there has been no activity in a year - maybe someone else is 
interested in doing this.

 Make it possible to set the classpath of the Derby tests using the -cp 
 command line arg instead of setting the CLASSPATH environment variable.
 --

 Key: DERBY-5219
 URL: https://issues.apache.org/jira/browse/DERBY-5219
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.9.1.0
Reporter: Rick Hillegas

 The instructions for running Derby tests say that you need to set the 
 CLASSPATH environment variable. This rule is described here: 
 http://svn.apache.org/viewvc/db/derby/code/trunk/java/testing/README.htm?view=co#2.1_running_with_derby_classes_
  If, instead, you set the classpath using the -cp command line argument, the 
 classpath won't be properly set in the subprocesses which the test harness 
 spawns. It should be possible for the harness to introspect its classpath and 
 pass that information to subprocesses.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-5835) OOM failure in 10.3 DerbyNetClient/derbynetmats/multi/stress.multi

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-5835.
-
Resolution: Won't Fix

The test has been rewritten and I do not think I have seen this type of failure 
with the StressMultiTest. Closing as won't fix (for the older branches will 
continue to show intermittent failures like this when tests are run.)

 OOM failure in 10.3 DerbyNetClient/derbynetmats/multi/stress.multi
 --

 Key: DERBY-5835
 URL: https://issues.apache.org/jira/browse/DERBY-5835
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.3.3.1
 Environment: Windows XP, ibm 1.5 sr13 and ibm 1.6 sr10
Reporter: Myrna van Lunteren
  Labels: derby_triage10_10
 Attachments: heapdump.20120623.024831.10020.0001.phd, 
 heapdump.20120623.024837.10020.0004.phd, 
 javacore.20120623.024831.10020.0002.txt, 
 javacore.20120623.024837.10020.0005.txt


 Since June 8, the nightly tests for 10.3 are hitting an OOM with both ibm 1.5 
 and ibm 1.6.
 No changes went in prior to the June 8 test run.
 Here is an example stack trace:
 (with ibm 1.6 against revision 1348302)
 *** Start: stress jdk1.6.0 DerbyNetClient derbynetmats:multi 2012-06-09 
 02:57:22 ***
 4 del
  ...stopping testers
 5 del
  ...waiting for testers to complete
 6 del
  TEST CASE SUMMARY: normal termination
 7 del
  ...running last checks via final.sql
 7 add
  JVMDUMP039I Processing dump event systhrow, detail 
  java/lang/OutOfMemoryError at 2012/06/09 03:03:26 - please wait.
  JVMDUMP032I JVM requested Heap dump using 
  'E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\heapdump.20120609.030326.5592.0001.phd'
   in response to an event
  JVMDUMP010I Heap dump written to 
  E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\heapdump.20120609.030326.5592.0001.phd
  JVMDUMP032I JVM requested Java dump using 
  'E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\javacore.20120609.030326.5592.0002.txt'
   in response to an event
  UTE430: can't allocate buffer
  UTE437: Unable to load formatStrings for j9mm
  JVMDUMP010I Java dump written to 
  E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\javacore.20120609.030326.5592.0002.txt
  JVMDUMP032I JVM requested Snap dump using 
  'E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\Snap.20120609.030326.5592.0003.trc'
   in response to an event
  UTE001: Error starting trace thread for Snap Dump Thread: -1
  JVMDUMP010I Snap dump written to 
  E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\Snap.20120609.030326.5592.0003.trc
  JVMDUMP013I Processed dump event systhrow, detail 
  java/lang/OutOfMemoryError.
  JVMDUMP039I Processing dump event systhrow, detail 
  java/lang/OutOfMemoryError at 2012/06/09 03:03:30 - please wait.
  JVMDUMP032I JVM requested Heap dump using 
  'E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\heapdump.20120609.030330.5592.0004.phd'
   in response to an event
  JVMDUMP010I Heap dump written to 
  E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\heapdump.20120609.030330.5592.0004.phd
  JVMDUMP032I JVM requested Java dump using 
  'E:\cloudtst\jartest\JarResults.2012-06-08\ibm16_derbyall\javacore.20120609.030330.5592.0005.txt'
   in response to an event
 Test Failed.
 See also these links:
 http://people.apache.org/~myrnavl/derby_test_results/v10_3/windows/testSummary-1348302.html
 http://people.apache.org/~myrnavl/derby_test_results/v10_3/windows/testSummary-1350843.html
 http://people.apache.org/~myrnavl/derby_test_results/v10_3/windows/testSummary-1353062.html
 There are older bugs referring to similar OOMs in stress.multi, not sure if 
 it's the same thing. (e.g. DERBY-4744)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-6012) Print thread dump and dump javacore if NetworkServerTestSetup has to kill off the Network Server start up process due to timeout

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren resolved DERBY-6012.
---
Resolution: Won't Fix

Resolving this as won't fix now. 
If there is a reproducible situation the server can be instrumented and more 
information can be obtained that way. But for intermittent test aggrevation to 
dump more information it seems the options for getting information are too 
involved.

 Print thread dump and dump javacore if NetworkServerTestSetup has to kill off 
 the Network Server start up  process due to timeout
 -

 Key: DERBY-6012
 URL: https://issues.apache.org/jira/browse/DERBY-6012
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.8.3.0
 Environment: 
Reporter: Kathey Marsden
 Fix For: 10.10.2.0

 Attachments: DERBY6012_patch1_diff.txt, DERBY6012_patch2_diff.txt, 
 derby-6012-1a-error_reporting.diff


 If Network Server startup hangs or times out as in DERBY-5991, we should 
 generate a javacore or a thread dump so the cause of the problem can be more 
 easily diagnosed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-2916) Change/error? in 'Ordered null semantics' output from 'SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS()' in lang/wisconsin.java

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-2916:
--
Component/s: (was: Test)
 SQL
 Services
   Assignee: (was: Daniel John Debrunner)
 Labels: derby_triage10_12 derby_triage10_8  (was: derby_triage10_8)

I don't think Dan is working on this anymore.
Also, it seems this is no longer an issue dealing with the Tests, although it 
initially showed up as a change in the test. Changing components.

 Change/error? in 'Ordered null semantics' output from 
 'SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS()' in lang/wisconsin.java
 ---

 Key: DERBY-2916
 URL: https://issues.apache.org/jira/browse/DERBY-2916
 Project: Derby
  Issue Type: Bug
  Components: Services, SQL
Affects Versions: 10.4.1.3
 Environment: OS: All
 JVM: All
Reporter: Ole Solberg
Priority: Minor
  Labels: derby_triage10_12, derby_triage10_8

 SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS() on
 'Statement Text: 
   select * from TENKTUP1
   left outer join TENKTUP2 on
   (
   TENKTUP1.unique1 = TENKTUP2.unique1
   )
   left outer join ONEKTUP on
   (
   TENKTUP2.unique2 = ONEKTUP.unique2
   )
   left outer join BPRIME on
   (
   ONEKTUP.onePercent = BPRIME.onePercent
   )
 '
 now returns extra 0 in
 ' Ordered null semantics on the following columns: 
 0 
   stop position: 
on first 1 column(s).
   Ordered null semantics on the following columns: 
 0 
 '



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-4862) Store version info in derbyTesting.jar and report its version with sysinfo, maybe with a warning that it should not be deployed

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-4862.
-
Resolution: Duplicate
  Assignee: Myrna van Lunteren  (was: Siddharth Srivastava)

 Store version info in derbyTesting.jar and report its version with sysinfo, 
 maybe with a warning that it should  not be deployed
 

 Key: DERBY-4862
 URL: https://issues.apache.org/jira/browse/DERBY-4862
 Project: Derby
  Issue Type: Improvement
  Components: Test, Tools
Affects Versions: 10.5.3.0, 10.6.2.1, 10.7.1.1
Reporter: Kathey Marsden
Assignee: Myrna van Lunteren
Priority: Minor

 derbyTesting.jar is put in a separate directory for releases, which is good 
 in that it tends to deter folks from accidentally deploying it, but sometimes 
 for people that do run tests, this means that it might accidentally get 
 separated or mismatched with the product jars. It would be nice if sysinfo 
 reported derbyTesting.jar and its version if present and could also print a 
 warning that derbyTesting.jar should never be deployed in production.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-4816) There are quite a few instances in Derby plan exporter and test code where PrivilegedActionException is thrown instead of the unwrapped exception

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-4816:
--
Component/s: (was: Test)

Removing Test component as we don't want to make mods to the tests as Knut 
Anders pointed out.

 There are quite a few instances in Derby plan exporter  and test code where 
 PrivilegedActionException is thrown instead of the unwrapped exception
 --

 Key: DERBY-4816
 URL: https://issues.apache.org/jira/browse/DERBY-4816
 Project: Derby
  Issue Type: Bug
  Components: Tools
Affects Versions: 10.7.1.1
Reporter: Kathey Marsden
  Labels: derby_triage10_8

 In working on DERBY-4812, I noticed the plan exporter tool and some tests 
 also throw PrivilegedActionException instead of the underlying exception.   
 These should be examined, but I think generally we should throw the unwrapped 
 exception.
 grep 'throws PrivilegedActionException' `find java -name '*.java'`
 ava/testing/org/apache/derbyTesting/functionTests/tests/lang/XplainStatisticsTe
 st.java: * @throws PrivilegedActionException
 java/testing/org/apache/derbyTesting/functionTests/util/CanonTestCase.java:
 * @throws PrivilegedActionException
 java/testing/org/apache/derbyTesting/functionTests/util/FTFileUtil.java:
 throws PrivilegedActionException
 java/testing/org/apache/derbyTesting/functionTests/util/FTFileUtil.java:
 throws PrivilegedActionException
 java/testing/org/apache/derbyTesting/functionTests/util/TestRoutines.java: * 
 @th
 rows PrivilegedActionException
 java/testing/org/apache/derbyTesting/functionTests/util/TestRoutines.java:
 th
 rows PrivilegedActionException, IOException
 java/testing/org/apache/derbyTesting/junit/BaseJDBCTestCase.java: * 
 @throws
 PrivilegedActionException
 java/testing/org/apache/derbyTesting/junit/BaseTestCase.java:throws 
 Priv
 ilegedActionException
 java/testing/org/apache/derbyTesting/junit/SupportFilesSetup.java:
 protected
 void setUp() throws PrivilegedActionException, IOException
 java/testing/org/apache/derbyTesting/junit/SupportFilesSetup.java:throws 
 Pri
 vilegedActionException
 java/testing/org/apache/derbyTesting/junit/SupportFilesSetup.java:
 throws
  PrivilegedActionException, IOException
 java/testing/org/apache/derbyTesting/junit/SystemPropertyTestSetup.java:
 throws PrivilegedActionException
 java/testing/org/apache/derbyTesting/junit/TestConfiguration.java: * 
 @throws
  PrivilegedActionException
 java/tools/org/apache/derby/impl/tools/planexporter/CreateXMLFile.java: * 
 @t
 hrows PrivilegedActionException
 java/tools/org/apache/derby/impl/tools/planexporter/CreateXMLFile.java: * 
 @t
 hrows PrivilegedActionException



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-4862) Store version info in derbyTesting.jar and report its version with sysinfo, maybe with a warning that it should not be deployed

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-4862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288484#comment-14288484
 ] 

Myrna van Lunteren commented on DERBY-4862:
---

DERBY-6468 added version info to derbyTesting.jar and reported that version in 
sysinfo.
It seems to me that if derbyTesting.jar gets included in a product it would do 
little harm - and the name is a fairly good indication of the purpose. So I 
don't think we should complicate sysinfo output with further warnings about 
this.
Marking as duplicate.

 Store version info in derbyTesting.jar and report its version with sysinfo, 
 maybe with a warning that it should  not be deployed
 

 Key: DERBY-4862
 URL: https://issues.apache.org/jira/browse/DERBY-4862
 Project: Derby
  Issue Type: Improvement
  Components: Test, Tools
Affects Versions: 10.5.3.0, 10.6.2.1, 10.7.1.1
Reporter: Kathey Marsden
Assignee: Myrna van Lunteren
Priority: Minor

 derbyTesting.jar is put in a separate directory for releases, which is good 
 in that it tends to deter folks from accidentally deploying it, but sometimes 
 for people that do run tests, this means that it might accidentally get 
 separated or mismatched with the product jars. It would be nice if sysinfo 
 reported derbyTesting.jar and its version if present and could also print a 
 warning that derbyTesting.jar should never be deployed in production.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-5997) Data source serialization tests use checked in binaries instead of using the normal upgrade test framework

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren resolved DERBY-5997.
---
Resolution: Duplicate

Marking duplicate of DERBY-5446

 Data source serialization tests use checked in binaries instead of using the 
 normal upgrade test framework
 --

 Key: DERBY-5997
 URL: https://issues.apache.org/jira/browse/DERBY-5997
 Project: Derby
  Issue Type: Improvement
  Components: Test
Reporter: Dag H. Wanvik

 The method of testing that Derby can deserialize serialized data sources from 
 older releases preserving upward compatibility, uses a set of checked in 
 binary files, cf.

 java/testing/org/apache/derbyTesting/functionTests/testData/serializedDataSources/*.ser
 files. These have not been added to or updated since 10.3, it seems. It would 
 be good to use the only source principle in the repo in this case too, and 
 integrate this checking into the general upgrade test framework we have. 
 Presently, one has to generate these files manually using the tool 
 SerializeDataSource manually for each release and check in the results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-3873) Intermittent failures in 'ttestSetPortPriority(o.a.dT.fT.tests.derbynet.ServerPropertiesTest)'

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-3873.
-
Resolution: Cannot Reproduce

I am closing this as cannot reproduce.
There is no longer access to the links mentioned in this issue, so difficult to 
be sure, but I do not believe we have seen this recently.

We have made various changes to the test to make it retry connections, and also 
added support for changing the timeout to run the test on slow machines.


 Intermittent failures in 
 'ttestSetPortPriority(o.a.dT.fT.tests.derbynet.ServerPropertiesTest)'
 --

 Key: DERBY-3873
 URL: https://issues.apache.org/jira/browse/DERBY-3873
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.4.2.1, 10.5.1.1
 Environment: trunk - 1.6 - sles, lin, sol
 trunk - 1.5 - lin
 10.4 - 1.6 - lin
Reporter: Ole Solberg
Priority: Minor
  Labels: derby_triage10_8

 a) 
 ttestSetPortPriority(org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest)junit.framework.AssertionFailedError:
  Can not ping server specified with -p
 and
 b) 
 ttestSetPortPriority(org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest)junit.framework.AssertionFailedError:
  Can still ping server specified with -p
 First seen  608645 2008-01-03 
 http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/608645-org.apache.derbyTesting.functionTests.suites.All_diff.txt
 Then mistakenly(?) linked to DERBY-3088.
 See http://dbtg.thresher.com/derby/test/stats_newest.html for occurences.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-3632) Replication tests must ensure stable replication state has been reached before attempting further connection or new replication commands.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-3632.
-
   Resolution: Fixed
Fix Version/s: 10.6.1.0

I am marking this issue as Fixed in 10.6. It seems from looking over the linked 
issues that most of these received fixes by that date.
Also changes were applied for this issue in 2009.

Very occassionally replication tests still fail - there are (or should be) 
separate issues for that.

 Replication tests must ensure stable replication state has been reached 
 before attempting further connection or new replication commands.
 -

 Key: DERBY-3632
 URL: https://issues.apache.org/jira/browse/DERBY-3632
 Project: Derby
  Issue Type: Task
  Components: Replication, Test
Affects Versions: 10.4.2.0, 10.5.1.1
 Environment: All
Reporter: Ole Solberg
Assignee: Ole Solberg
Priority: Minor
 Fix For: 10.4.2.1, 10.6.1.0

 Attachments: derby-3632_p1.diff.txt, derby-3632_p1.stat.txt


 When executing replication commands (startslave, startmaster, stopmaster, 
 stopslave, failover) tests must make sure that correct replication state has 
 been reached before attempting further connection to the master and slave 
 databases.
 This causes intermittent errors in replication tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-1402) Make checkerror command in protocol.tests that is used in derbynet/testProtocol.java to be able to fail gracefully

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-1402.
-
Resolution: Won't Fix

Marking won't fix - the test has been converted to junit.

 Make checkerror command in protocol.tests that is used in 
 derbynet/testProtocol.java to be able to fail gracefully
 --

 Key: DERBY-1402
 URL: https://issues.apache.org/jira/browse/DERBY-1402
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.2.1.6
Reporter: Sunitha Kambhampati
Priority: Trivial
  Labels: derby_triage10_8

 checkerror that is used to check error cases and conditions in protocol.tests 
 does not fail gracefully if it does not receive the expected codepoint.  This 
 can cause problems as I noticed when working on DERBY-959.   Make changes so 
 that the checkerror case in case of failures will fail and then proceed to 
 the next testcase.
 This is a trivial fix, but I am opening a separate jira for this and not 
 fixing this as part of DERBY-959 since I would want this fix to be backported 
 to 10.1 at some point.. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-5987) Tasks for 10.9.2 maintenance release

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-5987.
-
Resolution: Won't Fix
  Assignee: (was: Lily Wei)

I think it is clear we are not making a 10.9 release.

 Tasks for 10.9.2 maintenance release
 

 Key: DERBY-5987
 URL: https://issues.apache.org/jira/browse/DERBY-5987
 Project: Derby
  Issue Type: Task
  Components: Miscellaneous
Reporter: Lily Wei
 Attachments: RELEASE-NOTES.html


 Tracking issue for commits, etc for the 10.9.2 relese
 Release wiki will be at:
 http://wiki.apache.org/db-derby/DerbyTenNineTwoRelease



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (DERBY-5987) Tasks for 10.9.2 maintenance release

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-5987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288545#comment-14288545
 ] 

Myrna van Lunteren edited comment on DERBY-5987 at 1/23/15 1:24 AM:


I think it is clear we are not making a 10.9.2 release.


was (Author: myrna):
I think it is clear we are not making a 10.9 release.

 Tasks for 10.9.2 maintenance release
 

 Key: DERBY-5987
 URL: https://issues.apache.org/jira/browse/DERBY-5987
 Project: Derby
  Issue Type: Task
  Components: Miscellaneous
Reporter: Lily Wei
 Attachments: RELEASE-NOTES.html


 Tracking issue for commits, etc for the 10.9.2 relese
 Release wiki will be at:
 http://wiki.apache.org/db-derby/DerbyTenNineTwoRelease



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-3005) Document possibility to specify method signature in EXTERNAL NAME when creating a procedure/function

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-3005:
--
Attachment: DERBY-3005_2.diff
rrefsqljexternalname.html

Thanks for the review Kim!

Attaching a new patch; I was not pleased with the attempt to describe the use 
of the signatures in the external name as given as a solution to passing SQL 
NULLs to primitive types in the referenced user list thread and FAQ. After some 
thought I decided to just leave that section out, I felt it only looked 
confusing.
I also thought about commenting that although you can specify signatures, you 
still cannot overload a SQL function in Derby (i.e., you cannot use the same 
name for two different functions) but decided against that too, better to 
document what *is* supported.

I did fix up the little issues.
I intend to commit this second patch soon. As always further changes can always 
be made later.

 Document possibility to specify method signature in EXTERNAL NAME when 
 creating a procedure/function
 

 Key: DERBY-3005
 URL: https://issues.apache.org/jira/browse/DERBY-3005
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.4.1.3
Reporter: Kristian Waagan
Assignee: Myrna van Lunteren
 Attachments: DERBY-3005.diff, DERBY-3005_2.diff, 
 rrefsqljexternalname.html, rrefsqljexternalname.html


 In some cases it might be necessary to specify the method signature of the 
 external method used as a function or procedure in Derby (using CREATE 
 FUNCTION or CREATE PROCEDURE).
 This possibility is not documented in the manuals, but there is an entry in 
 the FAQ (http://db.apache.org/derby/faq.html#null_args):
 Either declare the function with RETURNS NULL ON NULL INPUT or define the 
 Java method signature in the external name clause. See the Create function 
 problem  derby-user mail list topic.
 The mail thread: 
 http://mail-archives.apache.org/mod_mbox/db-derby-user/200602.mbox/%3c4404e53d.1050...@apache.org%3e
 The relevant sections in the manuals should be updated to describe the 
 feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-4277) ReplicationRun_Local and ReplicationRun_Local_StateTest_part1 failed after testing fix of 4268

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren resolved DERBY-4277.
---
   Resolution: Fixed
Fix Version/s: 10.6.1.0
 Assignee: Ole Solberg

I applied the suggested change and committed (no patch) so I think that 
concludes the work on this issue. Setting back to Ole as he did the actual 
work. Setting to be fixed in 10.6.1.0 as the version for the original check-in.

 ReplicationRun_Local and ReplicationRun_Local_StateTest_part1 failed after 
 testing fix of 4268
 --

 Key: DERBY-4277
 URL: https://issues.apache.org/jira/browse/DERBY-4277
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.6.1.0
Reporter: Lily Wei
Assignee: Ole Solberg
Priority: Minor
  Labels: derby_triage10_5_2
 Fix For: 10.6.1.0

 Attachments: DERBY-4277_diff-p1.txt, DERBY-4277_stat-p1.txt, 
 derby-log.zipx, error-stacktrace-ReplicationRun_Local.out, 
 error-stacktrace-ReplicationRun_Local_StateTest_part1.out


 When testing the fix for bug 4268, ReplicationRun_Local and 
 ReplicationRun_Local_StateTest_part1 failed. This is after revision: 785298. 
 $ cat error-stacktrace.out
 [Error/failure logged at Tue Jun 16 22:15:46 PDT 2009]
 junit.framework.ComparisonFailure: Unexpected SQL state. expected:...20 but 
 wa
 s:...07
 at junit.framework.Assert.assertEquals(Assert.java:81)
 at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
 CTestCase.java:762)
 at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
 CTestCase.java:811)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver_direct(ReplicationRun.java:1381)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver(ReplicationRun.java:1302)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun_Local.testReplication_Local_existingTestsAsReplLoad(ReplicationRun_Local.
 java:148)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at junit.framework.TestCase.runTest(TestCase.java:154)
 at junit.framework.TestCase.runBare(TestCase.java:127)
 at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
 106)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:118)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.textui.TestRunner.doRun(TestRunner.java:116)
 at junit.textui.TestRunner.start(TestRunner.java:172)
 at junit.textui.TestRunner.main(TestRunner.java:138)
 Caused by: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 
 XRE07,
  SQLERRMC: Could not perform operation because the database is not in 
 replicatio
 n master mode.
 at 
 org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLE
 xceptionFactory40.java:96)
 at 
 org.apache.derby.client.am.SqlException.getSQLException(SqlException.
 java:358)
 at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
 at java.sql.DriverManager.getConnection(Unknown Source)
 at java.sql.DriverManager.getConnection(Unknown Source)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver_direct(ReplicationRun.java:1368)
 ... 28 more
 Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: 
 -1
 , SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the database

[jira] [Closed] (DERBY-4277) ReplicationRun_Local and ReplicationRun_Local_StateTest_part1 failed after testing fix of 4268

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-4277.
-

 ReplicationRun_Local and ReplicationRun_Local_StateTest_part1 failed after 
 testing fix of 4268
 --

 Key: DERBY-4277
 URL: https://issues.apache.org/jira/browse/DERBY-4277
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.6.1.0
Reporter: Lily Wei
Assignee: Ole Solberg
Priority: Minor
  Labels: derby_triage10_5_2
 Fix For: 10.6.1.0

 Attachments: DERBY-4277_diff-p1.txt, DERBY-4277_stat-p1.txt, 
 derby-log.zipx, error-stacktrace-ReplicationRun_Local.out, 
 error-stacktrace-ReplicationRun_Local_StateTest_part1.out


 When testing the fix for bug 4268, ReplicationRun_Local and 
 ReplicationRun_Local_StateTest_part1 failed. This is after revision: 785298. 
 $ cat error-stacktrace.out
 [Error/failure logged at Tue Jun 16 22:15:46 PDT 2009]
 junit.framework.ComparisonFailure: Unexpected SQL state. expected:...20 but 
 wa
 s:...07
 at junit.framework.Assert.assertEquals(Assert.java:81)
 at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
 CTestCase.java:762)
 at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
 CTestCase.java:811)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver_direct(ReplicationRun.java:1381)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver(ReplicationRun.java:1302)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun_Local.testReplication_Local_existingTestsAsReplLoad(ReplicationRun_Local.
 java:148)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at junit.framework.TestCase.runTest(TestCase.java:154)
 at junit.framework.TestCase.runBare(TestCase.java:127)
 at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
 106)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:118)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.textui.TestRunner.doRun(TestRunner.java:116)
 at junit.textui.TestRunner.start(TestRunner.java:172)
 at junit.textui.TestRunner.main(TestRunner.java:138)
 Caused by: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 
 XRE07,
  SQLERRMC: Could not perform operation because the database is not in 
 replicatio
 n master mode.
 at 
 org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLE
 xceptionFactory40.java:96)
 at 
 org.apache.derby.client.am.SqlException.getSQLException(SqlException.
 java:358)
 at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
 at java.sql.DriverManager.getConnection(Unknown Source)
 at java.sql.DriverManager.getConnection(Unknown Source)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver_direct(ReplicationRun.java:1368)
 ... 28 more
 Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: 
 -1
 , SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the database 
 is
  not in replication master mode.
 at 
 org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2
 075)
 at 
 org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(N
 etConnectionReply.java:540)
 at 
 org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Ne

[jira] [Commented] (DERBY-6533) Add a quiet mode to NsTest

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286327#comment-14286327
 ] 

Myrna van Lunteren commented on DERBY-6533:
---

Rick, it seems that this task has been completed?

 Add a quiet mode to NsTest
 --

 Key: DERBY-6533
 URL: https://issues.apache.org/jira/browse/DERBY-6533
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.11.1.1
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Attachments: derby-6533-01-aa-quietMode.diff, 
 derby-6533-02-aa-sequencesAndMoreStats.diff, 
 derby-6533-02-aa-sequencesAndMoreStats.out, derby-6533-03-timerThread.diff, 
 derby-6533-04-outOfMemory.diff, derby-6533-05-aa-dieQuickly.diff, 
 derby-6533-07-aa-moreDefensiveCode.diff, derby-6533-08-aa-sortErrors.diff, 
 derby-6533-aa-anotherNPE.diff, nstest.out, nstest.out, nstest.out, 
 nstest.out, nstest.out, nstest.out, nstest.out, nstest.out, nstest.out, 
 nstest.out, nstest.out, nstest.out, nstest.out, nstest.out


 Right now NsTest produces an enormous log file. This may be useful for 
 tracking down some errors. However, this can also make it hard to find the 
 signal in the noise. It would be good to turn off the chatty diagnostics 
 which report the result of every insert, update, delete, and select. A 
 summary at the end may be good enough, including a summary of the number of 
 times each kind of error (SQLState) was seen. While I'm in there, I plan to 
 make other smallish changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-232) Open Invitation to add a Question and Answer to Derby FAQs

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286360#comment-14286360
 ] 

Myrna van Lunteren commented on DERBY-232:
--

From a workflow point of view, this issue will never get resolved.
I propose to close this issue, and replace the FAQ web page with a wiki page 
with the same information.
Anyone can request to be added to the list of things to go on a wiki page, 
whereas updates to the web pages require a committer. 

Any suggestions / thoughts?

 Open Invitation to add a Question and Answer to Derby FAQs
 --

 Key: DERBY-232
 URL: https://issues.apache.org/jira/browse/DERBY-232
 Project: Derby
  Issue Type: Task
  Components: Web Site
Reporter: Jean T. Anderson
Assignee: Jean T. Anderson
Priority: Trivial
 Attachments: limit-rownumber.diff


 Add a comment to this Jira issue with the FAQ entry (both the question and 
 the answer) you would like to be added to 
 http://db.apache.org/derby/faq.html, and the assignee will add it. Setting 
 the Patch Available flag is a great way to keep a new FAQ on the radar 
 until committed, even if the text of the FAQ is in a comment instead of in an 
 actual patch.
 Indicate in your comment if the FAQ belongs in the Developing Derby or 
 Using Derby section.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DERBY-4090) Provide the ability to run tests concurrently on the same machine

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren reassigned DERBY-4090:
-

Assignee: Myrna van Lunteren  (was: Tiago R. Espinha)

 Provide the ability to run tests concurrently on the same machine
 -

 Key: DERBY-4090
 URL: https://issues.apache.org/jira/browse/DERBY-4090
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.5.1.1
Reporter: Kathey Marsden
Assignee: Myrna van Lunteren

 Because the network server tests use port 1527 for their testing, you cannot 
 currently run concurrent test runs on a single machine.  This is very 
 inconvenient, especially on multiple cpu machines where  running tests in 
 parallel might be faster than serial runs.  I think the things that need to 
 be done for this task are:
 - Convert the remaining network server tests.  as of 3/11/2009 this appear to 
 be
 derbynet/dblook_test_net.java
 derbynet/dblook_test_net_territory.java
 derbynet/DerbyNetAutoStart.java
 [x] - derbynet/runtimeinfo.java
 derbynet/testProtocol.java
 lang/holdCursorIJ.sql
 lang/wisconsin.java
 [x] - lang/ShutdownDatabase.java
 [x] - store/holdCursorExternalSortJDBC30.sql
 [x] - store/holdCursorJDBC30.sql
 - Make the default port for the suites.All run configurable with a system 
 property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-4090) Provide the ability to run tests concurrently on the same machine

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-4090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286393#comment-14286393
 ] 

Myrna van Lunteren commented on DERBY-4090:
---

I changed the assignee on this to myself - it seems unlikely Tiago is working 
on this.
There are 4 tests remaining in the derbynetclientmats:
derbynet/dblook_test_net.java
derbynet/dblook_test_net_territory.java
lang/wisconsin.java
(via encoding suite):
derbynet/TestEnc.java

 Provide the ability to run tests concurrently on the same machine
 -

 Key: DERBY-4090
 URL: https://issues.apache.org/jira/browse/DERBY-4090
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.5.1.1
Reporter: Kathey Marsden
Assignee: Myrna van Lunteren

 Because the network server tests use port 1527 for their testing, you cannot 
 currently run concurrent test runs on a single machine.  This is very 
 inconvenient, especially on multiple cpu machines where  running tests in 
 parallel might be faster than serial runs.  I think the things that need to 
 be done for this task are:
 - Convert the remaining network server tests.  as of 3/11/2009 this appear to 
 be
 derbynet/dblook_test_net.java
 derbynet/dblook_test_net_territory.java
 derbynet/DerbyNetAutoStart.java
 [x] - derbynet/runtimeinfo.java
 derbynet/testProtocol.java
 lang/holdCursorIJ.sql
 lang/wisconsin.java
 [x] - lang/ShutdownDatabase.java
 [x] - store/holdCursorExternalSortJDBC30.sql
 [x] - store/holdCursorJDBC30.sql
 - Make the default port for the suites.All run configurable with a system 
 property.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6741) User code can get the ContextManager from an EmbedConnection

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286333#comment-14286333
 ] 

Myrna van Lunteren commented on DERBY-6741:
---

Is there more work needed for this issue?

 User code can get the ContextManager from an EmbedConnection
 

 Key: DERBY-6741
 URL: https://issues.apache.org/jira/browse/DERBY-6741
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Services
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Attachments: derby-6741-01-aa-usederbyinternals.diff


 EmbedConnection.getContextManager() is a public method. Exposing internals 
 like the ContextManager is a security risk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-4026) Improve description of the replication tests

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-4026:
--
Assignee: (was: Ole Solberg)

 Improve description of the replication tests
 

 Key: DERBY-4026
 URL: https://issues.apache.org/jira/browse/DERBY-4026
 Project: Derby
  Issue Type: Improvement
  Components: Replication, Test
Affects Versions: 10.5.1.1
 Environment: All
Reporter: Ole Solberg
Priority: Minor

 The description of the replication tests (DERBY-3161) needs improvement.
 The current README files were written with distributed testing as focus, 
 while the normal regression testing of replication is now done in a standard 
 Derby  test context, that is on one single test host with master and slave 
 replication servers on that test host.
 Description of each test also needs improvement to better explain the purpose 
 of each test.
 ( http://www.nabble.com/How-to-run-the-replication-tests-tt21508208.html )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-4277) ReplicationRun_Local and ReplicationRun_Local_StateTest_part1 failed after testing fix of 4268

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286494#comment-14286494
 ] 

Myrna van Lunteren commented on DERBY-4277:
---

Looks like this work was mostly done but Knut had a comment that can still be 
resolved.


 ReplicationRun_Local and ReplicationRun_Local_StateTest_part1 failed after 
 testing fix of 4268
 --

 Key: DERBY-4277
 URL: https://issues.apache.org/jira/browse/DERBY-4277
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.6.1.0
Reporter: Lily Wei
Priority: Minor
  Labels: derby_triage10_5_2
 Attachments: DERBY-4277_diff-p1.txt, DERBY-4277_stat-p1.txt, 
 derby-log.zipx, error-stacktrace-ReplicationRun_Local.out, 
 error-stacktrace-ReplicationRun_Local_StateTest_part1.out


 When testing the fix for bug 4268, ReplicationRun_Local and 
 ReplicationRun_Local_StateTest_part1 failed. This is after revision: 785298. 
 $ cat error-stacktrace.out
 [Error/failure logged at Tue Jun 16 22:15:46 PDT 2009]
 junit.framework.ComparisonFailure: Unexpected SQL state. expected:...20 but 
 wa
 s:...07
 at junit.framework.Assert.assertEquals(Assert.java:81)
 at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
 CTestCase.java:762)
 at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
 CTestCase.java:811)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver_direct(ReplicationRun.java:1381)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver(ReplicationRun.java:1302)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun_Local.testReplication_Local_existingTestsAsReplLoad(ReplicationRun_Local.
 java:148)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at junit.framework.TestCase.runTest(TestCase.java:154)
 at junit.framework.TestCase.runBare(TestCase.java:127)
 at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
 106)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:118)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.textui.TestRunner.doRun(TestRunner.java:116)
 at junit.textui.TestRunner.start(TestRunner.java:172)
 at junit.textui.TestRunner.main(TestRunner.java:138)
 Caused by: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 
 XRE07,
  SQLERRMC: Could not perform operation because the database is not in 
 replicatio
 n master mode.
 at 
 org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLE
 xceptionFactory40.java:96)
 at 
 org.apache.derby.client.am.SqlException.getSQLException(SqlException.
 java:358)
 at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
 at java.sql.DriverManager.getConnection(Unknown Source)
 at java.sql.DriverManager.getConnection(Unknown Source)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver_direct(ReplicationRun.java:1368)
 ... 28 more
 Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: 
 -1
 , SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the database 
 is
  not in replication master mode.
 at 
 org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2
 075)
 at 
 org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(N
 etConnectionReply.java:540

[jira] [Updated] (DERBY-6533) Add a quiet mode to NsTest

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-6533:
--
Fix Version/s: 10.11.1.1

 Add a quiet mode to NsTest
 --

 Key: DERBY-6533
 URL: https://issues.apache.org/jira/browse/DERBY-6533
 Project: Derby
  Issue Type: Improvement
  Components: Test
Affects Versions: 10.11.1.1
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Fix For: 10.11.1.1

 Attachments: derby-6533-01-aa-quietMode.diff, 
 derby-6533-02-aa-sequencesAndMoreStats.diff, 
 derby-6533-02-aa-sequencesAndMoreStats.out, derby-6533-03-timerThread.diff, 
 derby-6533-04-outOfMemory.diff, derby-6533-05-aa-dieQuickly.diff, 
 derby-6533-07-aa-moreDefensiveCode.diff, derby-6533-08-aa-sortErrors.diff, 
 derby-6533-aa-anotherNPE.diff, nstest.out, nstest.out, nstest.out, 
 nstest.out, nstest.out, nstest.out, nstest.out, nstest.out, nstest.out, 
 nstest.out, nstest.out, nstest.out, nstest.out, nstest.out


 Right now NsTest produces an enormous log file. This may be useful for 
 tracking down some errors. However, this can also make it hard to find the 
 signal in the noise. It would be good to turn off the chatty diagnostics 
 which report the result of every insert, update, delete, and select. A 
 summary at the end may be good enough, including a summary of the number of 
 times each kind of error (SQLState) was seen. While I'm in there, I plan to 
 make other smallish changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-4026) Improve description of the replication tests

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-4026:
--
Labels: Newcomer derby_triage10_12  (was: )

 Improve description of the replication tests
 

 Key: DERBY-4026
 URL: https://issues.apache.org/jira/browse/DERBY-4026
 Project: Derby
  Issue Type: Improvement
  Components: Replication, Test
Affects Versions: 10.5.1.1
 Environment: All
Reporter: Ole Solberg
Priority: Minor
  Labels: Newcomer, derby_triage10_12

 The description of the replication tests (DERBY-3161) needs improvement.
 The current README files were written with distributed testing as focus, 
 while the normal regression testing of replication is now done in a standard 
 Derby  test context, that is on one single test host with master and slave 
 replication servers on that test host.
 Description of each test also needs improvement to better explain the purpose 
 of each test.
 ( http://www.nabble.com/How-to-run-the-replication-tests-tt21508208.html )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-4026) Improve description of the replication tests

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286486#comment-14286486
 ] 

Myrna van Lunteren commented on DERBY-4026:
---

unassigned, it doesn't look like Ole is working on this.
Perhaps an improved documentation can be achieved on the basis of the test plan 
attached to DERBY-3161, and by reading the source code.
Marking Newcomer.
triaged for 10.12


 Improve description of the replication tests
 

 Key: DERBY-4026
 URL: https://issues.apache.org/jira/browse/DERBY-4026
 Project: Derby
  Issue Type: Improvement
  Components: Replication, Test
Affects Versions: 10.5.1.1
 Environment: All
Reporter: Ole Solberg
Priority: Minor
  Labels: Newcomer, derby_triage10_12

 The description of the replication tests (DERBY-3161) needs improvement.
 The current README files were written with distributed testing as focus, 
 while the normal regression testing of replication is now done in a standard 
 Derby  test context, that is on one single test host with master and slave 
 replication servers on that test host.
 Description of each test also needs improvement to better explain the purpose 
 of each test.
 ( http://www.nabble.com/How-to-run-the-replication-tests-tt21508208.html )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-2343) sysinfo API only returns correct information for the first jar file on the classpath

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-2343:
--
Issue Type: Improvement  (was: Sub-task)
Parent: (was: DERBY-6164)

 sysinfo API only returns correct information for the first jar file on the 
 classpath
 

 Key: DERBY-2343
 URL: https://issues.apache.org/jira/browse/DERBY-2343
 Project: Derby
  Issue Type: Improvement
  Components: Tools
Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4
Reporter: Andrew McIntyre
Assignee: ahsan shamsudeen
Priority: Trivial
  Labels: derby_triage10_5_2, gsoc2013

 While updating the sysinfo_api test to our current JUnit usage, I 
 rediscovered the problem which has kept this test from running on a regular 
 basis: when running the test from jar files, only the first jar file on the 
 classpath properly reports its information through the sysinfo API.
 It is not a security manager issue, as disabling the security manager did not 
 solve the problem. There may be jar-sealing issues involved, but I haven't 
 looked into the issue very deeply. Just noting the issue here for later 
 investigation.
 I will commit a patch which updates the current sysinfo_api test to be called 
 SysinfoAPITest, and also add a note to tools._Suite about the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-4026) Improve description of the replication tests

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-4026:
--
Description: 
The description of the replication tests (DERBY-3161) needs improvement.

The current README files were written with distributed testing as focus, while 
the normal regression testing of replication is now done in a standard Derby  
test context, that is on one single test host with master and slave replication 
servers on that test host.

Description of each test also needs improvement to better explain the purpose 
of each test.


( 
http://apache-database.10148.n7.nabble.com/How-to-run-the-replication-tests-tt68800.html#a68802
 )

  was:
The description of the replication tests (DERBY-3161) needs improvement.

The current README files were written with distributed testing as focus, while 
the normal regression testing of replication is now done in a standard Derby  
test context, that is on one single test host with master and slave replication 
servers on that test host.

Description of each test also needs improvement to better explain the purpose 
of each test.


( http://www.nabble.com/How-to-run-the-replication-tests-tt21508208.html )


 Improve description of the replication tests
 

 Key: DERBY-4026
 URL: https://issues.apache.org/jira/browse/DERBY-4026
 Project: Derby
  Issue Type: Improvement
  Components: Replication, Test
Affects Versions: 10.5.1.1
 Environment: All
Reporter: Ole Solberg
Priority: Minor
  Labels: Newcomer, derby_triage10_12

 The description of the replication tests (DERBY-3161) needs improvement.
 The current README files were written with distributed testing as focus, 
 while the normal regression testing of replication is now done in a standard 
 Derby  test context, that is on one single test host with master and slave 
 replication servers on that test host.
 Description of each test also needs improvement to better explain the purpose 
 of each test.
 ( 
 http://apache-database.10148.n7.nabble.com/How-to-run-the-replication-tests-tt68800.html#a68802
  )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6741) User code can get the ContextManager from an EmbedConnection

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-6741:
--
Fix Version/s: 10.12.0.0

 User code can get the ContextManager from an EmbedConnection
 

 Key: DERBY-6741
 URL: https://issues.apache.org/jira/browse/DERBY-6741
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Services
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Fix For: 10.12.0.0

 Attachments: derby-6741-01-aa-usederbyinternals.diff


 EmbedConnection.getContextManager() is a public method. Exposing internals 
 like the ContextManager is a security risk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6748) Localize messages introduced or changed in 10.11.1

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-6748:
--
Fix Version/s: 10.12.0.0
   10.11.1.3

 Localize messages introduced or changed in 10.11.1
 --

 Key: DERBY-6748
 URL: https://issues.apache.org/jira/browse/DERBY-6748
 Project: Derby
  Issue Type: Improvement
  Components: Localization
Affects Versions: 10.11.1.3, 10.12.0.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Fix For: 10.11.1.3, 10.12.0.0

 Attachments: changes.html, 
 derby-6748-01-aa-engineMessageChanges.diff, 
 derby-6748-01-ab-engineAndToolsMessageChanges.diff


 Localize these changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-6164) Improve Derby's Code Coverage - GSoC 2013 Project

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-6164.
-
   Resolution: Fixed
Fix Version/s: 10.11.1.1

I moved the one remaining issue into a separate issue rather than a subtask 
(DERBY-6164), so this issue can now be closed.

 Improve Derby's Code Coverage - GSoC 2013 Project
 -

 Key: DERBY-6164
 URL: https://issues.apache.org/jira/browse/DERBY-6164
 Project: Derby
  Issue Type: Task
  Components: Test
Reporter: Bryan Pendleton
Assignee: ahsan shamsudeen
Priority: Minor
  Labels: gsoc2013
 Fix For: 10.11.1.1


 This year's edition of Google Summer of Code includes, once again, the Apache 
 Software Foundation.
 For the Derby project, I'm offering to mentor a student on the tasks 
 described here.
 For this project, you are required to have some basic knowledge of JUnit and 
 of how code coverage works.
 Currently some packages of Derby have poor code coverage. Emma defines the 
 minimum acceptable code coverage as 70% and some engineers suggest a minimum 
 of 80% is desired. 
 Students are invited to look at [1] to get familiar with Emma's code coverage 
 reports on Derby. 
 The Derby project conducted this effort last year, and substantial 
 improvements were made.
 We are looking to continue this process this year, as there are still areas 
 of the Derby code base where code coverage could be substantially improved.
 The candidate students are also expected to come up with their own schedule 
 for the tests they plan on creating and to discuss this schedule publicly on 
 the mailing list. 
 After a student applies, a small interview will be conducted via email as 
 part of the ASF's evaluation process. 
 [1] - http://dbtg.foundry.sun.com/derby/test/coverage/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-4277) ReplicationRun_Local and ReplicationRun_Local_StateTest_part1 failed after testing fix of 4268

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-4277:
--
Assignee: (was: Ole Solberg)

 ReplicationRun_Local and ReplicationRun_Local_StateTest_part1 failed after 
 testing fix of 4268
 --

 Key: DERBY-4277
 URL: https://issues.apache.org/jira/browse/DERBY-4277
 Project: Derby
  Issue Type: Bug
  Components: Replication
Affects Versions: 10.6.1.0
Reporter: Lily Wei
Priority: Minor
  Labels: derby_triage10_5_2
 Attachments: DERBY-4277_diff-p1.txt, DERBY-4277_stat-p1.txt, 
 derby-log.zipx, error-stacktrace-ReplicationRun_Local.out, 
 error-stacktrace-ReplicationRun_Local_StateTest_part1.out


 When testing the fix for bug 4268, ReplicationRun_Local and 
 ReplicationRun_Local_StateTest_part1 failed. This is after revision: 785298. 
 $ cat error-stacktrace.out
 [Error/failure logged at Tue Jun 16 22:15:46 PDT 2009]
 junit.framework.ComparisonFailure: Unexpected SQL state. expected:...20 but 
 wa
 s:...07
 at junit.framework.Assert.assertEquals(Assert.java:81)
 at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
 CTestCase.java:762)
 at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDB
 CTestCase.java:811)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver_direct(ReplicationRun.java:1381)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver(ReplicationRun.java:1302)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun_Local.testReplication_Local_existingTestsAsReplLoad(ReplicationRun_Local.
 java:148)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at junit.framework.TestCase.runTest(TestCase.java:154)
 at junit.framework.TestCase.runBare(TestCase.java:127)
 at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
 106)
 at junit.framework.TestResult$1.protect(TestResult.java:106)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.framework.TestResult.run(TestResult.java:109)
 at junit.framework.TestCase.run(TestCase.java:118)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.framework.TestResult.runProtected(TestResult.java:124)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.framework.TestSuite.runTest(TestSuite.java:208)
 at junit.framework.TestSuite.run(TestSuite.java:203)
 at junit.textui.TestRunner.doRun(TestRunner.java:116)
 at junit.textui.TestRunner.start(TestRunner.java:172)
 at junit.textui.TestRunner.main(TestRunner.java:138)
 Caused by: java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 
 XRE07,
  SQLERRMC: Could not perform operation because the database is not in 
 replicatio
 n master mode.
 at 
 org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLE
 xceptionFactory40.java:96)
 at 
 org.apache.derby.client.am.SqlException.getSQLException(SqlException.
 java:358)
 at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
 at java.sql.DriverManager.getConnection(Unknown Source)
 at java.sql.DriverManager.getConnection(Unknown Source)
 at 
 org.apache.derbyTesting.functionTests.tests.replicationTests.Replicat
 ionRun.failOver_direct(ReplicationRun.java:1368)
 ... 28 more
 Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: 
 -1
 , SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the database 
 is
  not in replication master mode.
 at 
 org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2
 075)
 at 
 org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(N
 etConnectionReply.java:540)
 at 
 org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Ne
 tConnectionReply.java:433

[jira] [Commented] (DERBY-6748) Localize messages introduced or changed in 10.11.1

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286330#comment-14286330
 ] 

Myrna van Lunteren commented on DERBY-6748:
---

Rick, is there more work expected here?

 Localize messages introduced or changed in 10.11.1
 --

 Key: DERBY-6748
 URL: https://issues.apache.org/jira/browse/DERBY-6748
 Project: Derby
  Issue Type: Improvement
  Components: Localization
Affects Versions: 10.11.1.3, 10.12.0.0
Reporter: Rick Hillegas
Assignee: Rick Hillegas
 Attachments: changes.html, 
 derby-6748-01-aa-engineMessageChanges.diff, 
 derby-6748-01-ab-engineAndToolsMessageChanges.diff


 Localize these changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-6789) intermittent test failure in test case testNetworkServerSecurityMechanism in NSSecurityMechanismTest with Oracle Java 1.8

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren resolved DERBY-6789.
---
   Resolution: Fixed
Fix Version/s: 10.12.0.0

I have not seen the failure again - resolving. If there are still things not 
right with the workaround we can deal with it when it happens again.

 intermittent test failure in test case testNetworkServerSecurityMechanism in 
 NSSecurityMechanismTest with Oracle Java 1.8
 -

 Key: DERBY-6789
 URL: https://issues.apache.org/jira/browse/DERBY-6789
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.12.0.0
 Environment: Windows 2008 on vmware; Oracle Java 8 1.8.0_20-b26.
Reporter: Myrna van Lunteren
Assignee: Myrna van Lunteren
 Fix For: 10.12.0.0


 The following failure was seen with Oracle's Java 8:
 1) 
 testNetworkServerSecurityMechanism(org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest)junit.framework.AssertionFailedError:
  The expected SQL state must be five characters long
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:876)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:943)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:589)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionsUsingDriverManager(NSSecurityMechanismTest.java:438)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.testNetworkServerSecurityMechanism(NSSecurityMechanismTest.java:292)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
 Caused by: java.sql.SQLException: Java exception: 'Unexpected CryptoAPI 
 failure generating seed: java.lang.InternalError'.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
   at java.sql.DriverManager.getConnection(DriverManager.java:664)
   at java.sql.DriverManager.getConnection(DriverManager.java:270)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:542)
   ... 37 more
 Caused by: ERROR XJ001: Java exception: 'Unexpected CryptoAPI failure 
 generating seed: java.lang.InternalError'.
   at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.init(Unknown Source)
   at 
 org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(Unknown
  Source)
   ... 41 more
 Caused by: java.lang.InternalError: Unexpected CryptoAPI failure generating 
 seed
   at 
 sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62)
   at 
 sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
   at 
 sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:128)
   at java.security.SecureRandom.generateSeed(SecureRandom.java:522)
   at org.apache.derby.client.am.EncryptionManager.generateSeed(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnection.initializeClientSeed(Unknown Source)
   at 
 org.apache.derby.client.net.NetConnection.flowUSRSSBPWDconnect(Unknown Source)
   ... 44 more
 This has happened only on trunk (e.g. built at revision level 1649991), but 
 then I'm only running jdk 1.8 testing on trunk, and only on a windows machine.
 The nightly

[jira] [Updated] (DERBY-3005) Document possibility to specify method signature in EXTERNAL NAME when creating a procedure/function

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-3005:
--
Attachment: rrefsqljexternalname.html
DERBY-3005.diff

Attaching a patch which attempts to address this issue. I took the example from 
the thread from the user's list.
Review will be appreciated.

 Document possibility to specify method signature in EXTERNAL NAME when 
 creating a procedure/function
 

 Key: DERBY-3005
 URL: https://issues.apache.org/jira/browse/DERBY-3005
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.4.1.3
Reporter: Kristian Waagan
Assignee: Myrna van Lunteren
 Attachments: DERBY-3005.diff, rrefsqljexternalname.html


 In some cases it might be necessary to specify the method signature of the 
 external method used as a function or procedure in Derby (using CREATE 
 FUNCTION or CREATE PROCEDURE).
 This possibility is not documented in the manuals, but there is an entry in 
 the FAQ (http://db.apache.org/derby/faq.html#null_args):
 Either declare the function with RETURNS NULL ON NULL INPUT or define the 
 Java method signature in the external name clause. See the Create function 
 problem  derby-user mail list topic.
 The mail thread: 
 http://mail-archives.apache.org/mod_mbox/db-derby-user/200602.mbox/%3c4404e53d.1050...@apache.org%3e
 The relevant sections in the manuals should be updated to describe the 
 feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DERBY-3005) Document possibility to specify method signature in EXTERNAL NAME when creating a procedure/function

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren reassigned DERBY-3005:
-

Assignee: Myrna van Lunteren

 Document possibility to specify method signature in EXTERNAL NAME when 
 creating a procedure/function
 

 Key: DERBY-3005
 URL: https://issues.apache.org/jira/browse/DERBY-3005
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.4.1.3
Reporter: Kristian Waagan
Assignee: Myrna van Lunteren

 In some cases it might be necessary to specify the method signature of the 
 external method used as a function or procedure in Derby (using CREATE 
 FUNCTION or CREATE PROCEDURE).
 This possibility is not documented in the manuals, but there is an entry in 
 the FAQ (http://db.apache.org/derby/faq.html#null_args):
 Either declare the function with RETURNS NULL ON NULL INPUT or define the 
 Java method signature in the external name clause. See the Create function 
 problem  derby-user mail list topic.
 The mail thread: 
 http://mail-archives.apache.org/mod_mbox/db-derby-user/200602.mbox/%3c4404e53d.1050...@apache.org%3e
 The relevant sections in the manuals should be updated to describe the 
 feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

JIRA maintenance...

[Myrna van Lunteren]

Hi,

I moved all JIRA issues that had been resolved, but not changed since June
1, 2014, into the 'closed' state. This applied to 172 issues.

If you find any issue that should not have gotten closed, feel free to
reopen.

Regards,
Myrna

Bug triage and cleanup

[Myrna van Lunteren]

Hi,

It has been almost a year since I last posted about bug triage.
I created a new page:
https://wiki.apache.org/db-derby/DerbyTenTwelveBugTriage

There are currently 1145 issues; this is 48 issues fewer than the last time
we did triage:
https://issues.apache.org/jira/browse/DERBY/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel
Of course, this does mean that we only closed 48 issues during the last
triage, new issues have been created and closed since.

But it would be good to bring this open list down again, or at least review
it.

Instructions for participating in the triage are on the page.

In addition, there are a number of issues assigned to various people that
have not seen any activity for considerable time. I will look through those
and either unassign them or make other appropriate steps to move these
issues forward.

I you have an issue, have not updated it for the last 6 months, but are
still working on it, please let me know.

Myrna

[jira] [Comment Edited] (DERBY-6789) intermittent test failure in test case testNetworkServerSecurityMechanism in NSSecurityMechanismTest with Oracle Java 1.8

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278862#comment-14278862
 ] 

Myrna van Lunteren edited comment on DERBY-6789 at 1/15/15 4:07 PM:


This looks similar to DERBY-6702, which we decided was a jvm issue.


was (Author: myrna):
This looks similar to DERBY-6702, which we assumed was a jvm issue, but now I'm 
seeing it with Oracle's jvm.

 intermittent test failure in test case testNetworkServerSecurityMechanism in 
 NSSecurityMechanismTest with Oracle Java 1.8
 -

 Key: DERBY-6789
 URL: https://issues.apache.org/jira/browse/DERBY-6789
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.12.0.0
 Environment: Windows 2008 on vmware; Oracle Java 8 1.8.0_20-b26.
Reporter: Myrna van Lunteren

 The following failure was seen with Oracle's Java 8:
 1) 
 testNetworkServerSecurityMechanism(org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest)junit.framework.AssertionFailedError:
  The expected SQL state must be five characters long
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:876)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:943)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:589)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionsUsingDriverManager(NSSecurityMechanismTest.java:438)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.testNetworkServerSecurityMechanism(NSSecurityMechanismTest.java:292)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
 Caused by: java.sql.SQLException: Java exception: 'Unexpected CryptoAPI 
 failure generating seed: java.lang.InternalError'.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
   at java.sql.DriverManager.getConnection(DriverManager.java:664)
   at java.sql.DriverManager.getConnection(DriverManager.java:270)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:542)
   ... 37 more
 Caused by: ERROR XJ001: Java exception: 'Unexpected CryptoAPI failure 
 generating seed: java.lang.InternalError'.
   at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.init(Unknown Source)
   at 
 org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(Unknown
  Source)
   ... 41 more
 Caused by: java.lang.InternalError: Unexpected CryptoAPI failure generating 
 seed
   at 
 sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62)
   at 
 sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
   at 
 sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:128)
   at java.security.SecureRandom.generateSeed(SecureRandom.java:522)
   at org.apache.derby.client.am.EncryptionManager.generateSeed(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnection.initializeClientSeed(Unknown Source)
   at 
 org.apache.derby.client.net.NetConnection.flowUSRSSBPWDconnect(Unknown Source)
   ... 44 more
 This has happened only on trunk (e.g. built at revision level 1649991), but 
 then I'm only running jdk 1.8 testing on trunk, and only

[jira] [Commented] (DERBY-6789) intermittent test failure in test case testNetworkServerSecurityMechanism in NSSecurityMechanismTest with Oracle Java 1.8

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278862#comment-14278862
 ] 

Myrna van Lunteren commented on DERBY-6789:
---

This looks similar to DERBY-6702, which we assumed was a jvm issue, but now I'm 
seeing it with Oracle's jvm.

 intermittent test failure in test case testNetworkServerSecurityMechanism in 
 NSSecurityMechanismTest with Oracle Java 1.8
 -

 Key: DERBY-6789
 URL: https://issues.apache.org/jira/browse/DERBY-6789
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.12.0.0
 Environment: Windows 2008 on vmware; Oracle Java 8 1.8.0_20-b26.
Reporter: Myrna van Lunteren

 The following failure was seen with Oracle's Java 8:
 1) 
 testNetworkServerSecurityMechanism(org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest)junit.framework.AssertionFailedError:
  The expected SQL state must be five characters long
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:876)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:943)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:589)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionsUsingDriverManager(NSSecurityMechanismTest.java:438)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.testNetworkServerSecurityMechanism(NSSecurityMechanismTest.java:292)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
 Caused by: java.sql.SQLException: Java exception: 'Unexpected CryptoAPI 
 failure generating seed: java.lang.InternalError'.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
   at java.sql.DriverManager.getConnection(DriverManager.java:664)
   at java.sql.DriverManager.getConnection(DriverManager.java:270)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:542)
   ... 37 more
 Caused by: ERROR XJ001: Java exception: 'Unexpected CryptoAPI failure 
 generating seed: java.lang.InternalError'.
   at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.init(Unknown Source)
   at 
 org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(Unknown
  Source)
   ... 41 more
 Caused by: java.lang.InternalError: Unexpected CryptoAPI failure generating 
 seed
   at 
 sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62)
   at 
 sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
   at 
 sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:128)
   at java.security.SecureRandom.generateSeed(SecureRandom.java:522)
   at org.apache.derby.client.am.EncryptionManager.generateSeed(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnection.initializeClientSeed(Unknown Source)
   at 
 org.apache.derby.client.net.NetConnection.flowUSRSSBPWDconnect(Unknown Source)
   ... 44 more
 This has happened only on trunk (e.g. built at revision level 1649991), but 
 then I'm only running jdk 1.8 testing on trunk, and only on a windows machine.
 The nightly testing at Oracle or on Apache machines has never shown this 
 problem.
 I run multiple jvms on the same machine

[jira] [Assigned] (DERBY-6789) intermittent test failure in test case testNetworkServerSecurityMechanism in NSSecurityMechanismTest with Oracle Java 1.8

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren reassigned DERBY-6789:
-

Assignee: Myrna van Lunteren

 intermittent test failure in test case testNetworkServerSecurityMechanism in 
 NSSecurityMechanismTest with Oracle Java 1.8
 -

 Key: DERBY-6789
 URL: https://issues.apache.org/jira/browse/DERBY-6789
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.12.0.0
 Environment: Windows 2008 on vmware; Oracle Java 8 1.8.0_20-b26.
Reporter: Myrna van Lunteren
Assignee: Myrna van Lunteren

 The following failure was seen with Oracle's Java 8:
 1) 
 testNetworkServerSecurityMechanism(org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest)junit.framework.AssertionFailedError:
  The expected SQL state must be five characters long
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:876)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:943)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:589)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionsUsingDriverManager(NSSecurityMechanismTest.java:438)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.testNetworkServerSecurityMechanism(NSSecurityMechanismTest.java:292)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
 Caused by: java.sql.SQLException: Java exception: 'Unexpected CryptoAPI 
 failure generating seed: java.lang.InternalError'.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
   at java.sql.DriverManager.getConnection(DriverManager.java:664)
   at java.sql.DriverManager.getConnection(DriverManager.java:270)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:542)
   ... 37 more
 Caused by: ERROR XJ001: Java exception: 'Unexpected CryptoAPI failure 
 generating seed: java.lang.InternalError'.
   at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.init(Unknown Source)
   at 
 org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(Unknown
  Source)
   ... 41 more
 Caused by: java.lang.InternalError: Unexpected CryptoAPI failure generating 
 seed
   at 
 sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62)
   at 
 sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
   at 
 sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:128)
   at java.security.SecureRandom.generateSeed(SecureRandom.java:522)
   at org.apache.derby.client.am.EncryptionManager.generateSeed(Unknown 
 Source)
   at 
 org.apache.derby.client.net.NetConnection.initializeClientSeed(Unknown Source)
   at 
 org.apache.derby.client.net.NetConnection.flowUSRSSBPWDconnect(Unknown Source)
   ... 44 more
 This has happened only on trunk (e.g. built at revision level 1649991), but 
 then I'm only running jdk 1.8 testing on trunk, and only on a windows machine.
 The nightly testing at Oracle or on Apache machines has never shown this 
 problem.
 I run multiple jvms on the same machine, and I have only seen this failure 
 when the Oracle 1.8 jvm was the last one to get

[jira] [Commented] (DERBY-6789) intermittent test failure in test case testNetworkServerSecurityMechanism in NSSecurityMechanismTest with Oracle Java 1.8

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278898#comment-14278898
 ] 

Myrna van Lunteren commented on DERBY-6789:
---

I think my workaround of DERBY-6702 failed, because in the workaround I looked 
for:
bq.if (!sw.toString().contains(
java.lang.InternalError: unexpected CryptoAPI failure))
But the stack trace contains this string: 
bq.'java.lang.InternalError: Unexpected CryptoAPI failure'
In other words, the 'u' in 'unexpected' should be uppercase.

I'll commit that change without making a patch, will reset my environment to 
the previous situation and will monitor.


 intermittent test failure in test case testNetworkServerSecurityMechanism in 
 NSSecurityMechanismTest with Oracle Java 1.8
 -

 Key: DERBY-6789
 URL: https://issues.apache.org/jira/browse/DERBY-6789
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.12.0.0
 Environment: Windows 2008 on vmware; Oracle Java 8 1.8.0_20-b26.
Reporter: Myrna van Lunteren
Assignee: Myrna van Lunteren

 The following failure was seen with Oracle's Java 8:
 1) 
 testNetworkServerSecurityMechanism(org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest)junit.framework.AssertionFailedError:
  The expected SQL state must be five characters long
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:876)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:943)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:589)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionsUsingDriverManager(NSSecurityMechanismTest.java:438)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.testNetworkServerSecurityMechanism(NSSecurityMechanismTest.java:292)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
 Caused by: java.sql.SQLException: Java exception: 'Unexpected CryptoAPI 
 failure generating seed: java.lang.InternalError'.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
   at java.sql.DriverManager.getConnection(DriverManager.java:664)
   at java.sql.DriverManager.getConnection(DriverManager.java:270)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:542)
   ... 37 more
 Caused by: ERROR XJ001: Java exception: 'Unexpected CryptoAPI failure 
 generating seed: java.lang.InternalError'.
   at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.init(Unknown Source)
   at 
 org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(Unknown
  Source)
   ... 41 more
 Caused by: java.lang.InternalError: Unexpected CryptoAPI failure generating 
 seed
   at 
 sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62)
   at 
 sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
   at 
 sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:128)
   at java.security.SecureRandom.generateSeed(SecureRandom.java:522)
   at org.apache.derby.client.am.EncryptionManager.generateSeed(Unknown 
 Source

[jira] [Comment Edited] (DERBY-6789) intermittent test failure in test case testNetworkServerSecurityMechanism in NSSecurityMechanismTest with Oracle Java 1.8

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14278898#comment-14278898
 ] 

Myrna van Lunteren edited comment on DERBY-6789 at 1/15/15 4:26 PM:


I think my workaround of DERBY-6702 failed, because in the workaround I looked 
for:
bq.if (!sw.toString().contains(
bq.java.lang.InternalError: unexpected CryptoAPI failure))
But the stack trace contains this string: 
bq.'java.lang.InternalError: Unexpected CryptoAPI failure'
In other words, the 'u' in 'unexpected' should be uppercase.

I'll commit that change without making a patch, will reset my environment to 
the previous situation and will monitor.



was (Author: myrna):
I think my workaround of DERBY-6702 failed, because in the workaround I looked 
for:
bq.if (!sw.toString().contains(
java.lang.InternalError: unexpected CryptoAPI failure))
But the stack trace contains this string: 
bq.'java.lang.InternalError: Unexpected CryptoAPI failure'
In other words, the 'u' in 'unexpected' should be uppercase.

I'll commit that change without making a patch, will reset my environment to 
the previous situation and will monitor.


 intermittent test failure in test case testNetworkServerSecurityMechanism in 
 NSSecurityMechanismTest with Oracle Java 1.8
 -

 Key: DERBY-6789
 URL: https://issues.apache.org/jira/browse/DERBY-6789
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.12.0.0
 Environment: Windows 2008 on vmware; Oracle Java 8 1.8.0_20-b26.
Reporter: Myrna van Lunteren
Assignee: Myrna van Lunteren

 The following failure was seen with Oracle's Java 8:
 1) 
 testNetworkServerSecurityMechanism(org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest)junit.framework.AssertionFailedError:
  The expected SQL state must be five characters long
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:876)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:943)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:589)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionsUsingDriverManager(NSSecurityMechanismTest.java:438)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.testNetworkServerSecurityMechanism(NSSecurityMechanismTest.java:292)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at 
 org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
   at 
 org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
   at 
 org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
   at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
   at junit.extensions.TestSetup.run(TestSetup.java:25)
 Caused by: java.sql.SQLException: Java exception: 'Unexpected CryptoAPI 
 failure generating seed: java.lang.InternalError'.
   at 
 org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
 Source)
   at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
   at java.sql.DriverManager.getConnection(DriverManager.java:664)
   at java.sql.DriverManager.getConnection(DriverManager.java:270)
   at 
 org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:542)
   ... 37 more
 Caused by: ERROR XJ001: Java exception: 'Unexpected CryptoAPI failure 
 generating seed: java.lang.InternalError'.
   at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
   at org.apache.derby.client.net.NetConnection.init(Unknown Source)
   at 
 org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection

[jira] [Created] (DERBY-6789) intermittent test failure in test case testNetworkServerSecurityMechanism in NSSecurityMechanismTest with Oracle Java 1.8

[Myrna van Lunteren (JIRA)]

Myrna van Lunteren created DERBY-6789:
-

 Summary: intermittent test failure in test case 
testNetworkServerSecurityMechanism in NSSecurityMechanismTest with Oracle Java 
1.8
 Key: DERBY-6789
 URL: https://issues.apache.org/jira/browse/DERBY-6789
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.12.0.0
 Environment: Windows 2008 on vmware; Oracle Java 8 1.8.0_20-b26.
Reporter: Myrna van Lunteren


The following failure was seen with Oracle's Java 8:

1) 
testNetworkServerSecurityMechanism(org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest)junit.framework.AssertionFailedError:
 The expected SQL state must be five characters long
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:876)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:943)
at 
org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:589)
at 
org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionsUsingDriverManager(NSSecurityMechanismTest.java:438)
at 
org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.testNetworkServerSecurityMechanism(NSSecurityMechanismTest.java:292)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:443)
at 
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:460)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at 
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:58)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: java.sql.SQLException: Java exception: 'Unexpected CryptoAPI failure 
generating seed: java.lang.InternalError'.
at 
org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:270)
at 
org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest.assertConnectionUsingDriverManager(NSSecurityMechanismTest.java:542)
... 37 more
Caused by: ERROR XJ001: Java exception: 'Unexpected CryptoAPI failure 
generating seed: java.lang.InternalError'.
at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.init(Unknown Source)
at 
org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(Unknown
 Source)
... 41 more
Caused by: java.lang.InternalError: Unexpected CryptoAPI failure generating seed
at 
sun.security.provider.NativeSeedGenerator.getSeedBytes(NativeSeedGenerator.java:62)
at 
sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
at 
sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:128)
at java.security.SecureRandom.generateSeed(SecureRandom.java:522)
at org.apache.derby.client.am.EncryptionManager.generateSeed(Unknown 
Source)
at 
org.apache.derby.client.net.NetConnection.initializeClientSeed(Unknown Source)
at 
org.apache.derby.client.net.NetConnection.flowUSRSSBPWDconnect(Unknown Source)
... 44 more

This has happened only on trunk (e.g. built at revision level 1649991), but 
then I'm only running jdk 1.8 testing on trunk, and only on a windows machine.
The nightly testing at Oracle or on Apache machines has never shown this 
problem.
I run multiple jvms on the same machine, and I have only seen this failure when 
the Oracle 1.8 jvm was the last one to get started.
This does mean it starts with -Dderby.tests.basePort=3500.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren resolved DERBY-2238.
---
   Resolution: Fixed
Fix Version/s: 10.12.0.0

Thanks for the reviews and input Mamta and Kim.
Resolving.

 Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery 
 --

 Key: DERBY-2238
 URL: https://issues.apache.org/jira/browse/DERBY-2238
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.2.0
 Environment: 
 http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Assignee: Myrna van Lunteren
  Labels: derby_triage10_11
 Fix For: 10.12.0.0

 Attachments: DERBY-2238.diff, DERBY-2238_2.diff, 
 rrefscalarsubquery.html, rrefscalarsubquery.html


 In the page, I found next example.
 -- Introduce a way of generating new data values,
 -- using a query which selects from a VALUES clause (which is an
 -- alternate form of a fullselect).
 -- This query shows how a table can be derived called X having
 -- 2 columns R1 and R2 and 1 row of data.
 SELECT R1,R2
 FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
 I think this is not ScalarSubquery because the result have two columns.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14274009#comment-14274009
 ] 

Myrna van Lunteren commented on DERBY-2238:
---

Thanks for the review, Mamta. I'll work on this...

 Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery 
 --

 Key: DERBY-2238
 URL: https://issues.apache.org/jira/browse/DERBY-2238
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.2.0
 Environment: 
 http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Assignee: Myrna van Lunteren
  Labels: derby_triage10_11

 In the page, I found next example.
 -- Introduce a way of generating new data values,
 -- using a query which selects from a VALUES clause (which is an
 -- alternate form of a fullselect).
 -- This query shows how a table can be derived called X having
 -- 2 columns R1 and R2 and 1 row of data.
 SELECT R1,R2
 FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
 I think this is not ScalarSubquery because the result have two columns.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren reassigned DERBY-2238:
-

Assignee: Myrna van Lunteren

 Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery 
 --

 Key: DERBY-2238
 URL: https://issues.apache.org/jira/browse/DERBY-2238
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.2.0
 Environment: 
 http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Assignee: Myrna van Lunteren
  Labels: derby_triage10_11

 In the page, I found next example.
 -- Introduce a way of generating new data values,
 -- using a query which selects from a VALUES clause (which is an
 -- alternate form of a fullselect).
 -- This query shows how a table can be derived called X having
 -- 2 columns R1 and R2 and 1 row of data.
 SELECT R1,R2
 FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
 I think this is not ScalarSubquery because the result have two columns.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-2238:
--
Attachment: rrefscalarsubquery.html
DERBY-2238.diff

Attaching a patch which removes the second, incorrect, example.

 Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery 
 --

 Key: DERBY-2238
 URL: https://issues.apache.org/jira/browse/DERBY-2238
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.2.0
 Environment: 
 http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Assignee: Myrna van Lunteren
  Labels: derby_triage10_11
 Attachments: DERBY-2238.diff, rrefscalarsubquery.html


 In the page, I found next example.
 -- Introduce a way of generating new data values,
 -- using a query which selects from a VALUES clause (which is an
 -- alternate form of a fullselect).
 -- This query shows how a table can be derived called X having
 -- 2 columns R1 and R2 and 1 row of data.
 SELECT R1,R2
 FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
 I think this is not ScalarSubquery because the result have two columns.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-2238:
--
Attachment: DERBY-2238_2.diff
rrefscalarsubquery.html

Thanks for the modified example Mamta.
I'm attaching a new patch with this example.
I'll commit this shortly (as always, if I've missed something further 
improvements can be made later).

 Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery 
 --

 Key: DERBY-2238
 URL: https://issues.apache.org/jira/browse/DERBY-2238
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.2.0
 Environment: 
 http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Assignee: Myrna van Lunteren
  Labels: derby_triage10_11
 Attachments: DERBY-2238.diff, DERBY-2238_2.diff, 
 rrefscalarsubquery.html, rrefscalarsubquery.html


 In the page, I found next example.
 -- Introduce a way of generating new data values,
 -- using a query which selects from a VALUES clause (which is an
 -- alternate form of a fullselect).
 -- This query shows how a table can be derived called X having
 -- 2 columns R1 and R2 and 1 row of data.
 SELECT R1,R2
 FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
 I think this is not ScalarSubquery because the result have two columns.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (DERBY-2238) Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14274469#comment-14274469
 ] 

Myrna van Lunteren edited comment on DERBY-2238 at 1/13/15 12:25 AM:
-

Thanks for the modified example Mamta.
I'm attaching a new patch with this example.
The 'values' clause acts as a kind of subquery in this case.
I'll commit this shortly (as always, if I've missed something further 
improvements can be made later).


was (Author: myrna):
Thanks for the modified example Mamta.
I'm attaching a new patch with this example.
I'll commit this shortly (as always, if I've missed something further 
improvements can be made later).

 Example of ScalarSubquery in Derby Reference Manual is not ScalarSubquery 
 --

 Key: DERBY-2238
 URL: https://issues.apache.org/jira/browse/DERBY-2238
 Project: Derby
  Issue Type: Bug
  Components: Documentation
Affects Versions: 10.2.2.0
 Environment: 
 http://db.apache.org/derby/docs/dev/ref/rrefscalarsubquery.html
Reporter: Tomohito Nakayama
Assignee: Myrna van Lunteren
  Labels: derby_triage10_11
 Attachments: DERBY-2238.diff, DERBY-2238_2.diff, 
 rrefscalarsubquery.html, rrefscalarsubquery.html


 In the page, I found next example.
 -- Introduce a way of generating new data values,
 -- using a query which selects from a VALUES clause (which is an
 -- alternate form of a fullselect).
 -- This query shows how a table can be derived called X having
 -- 2 columns R1 and R2 and 1 row of data.
 SELECT R1,R2
 FROM (VALUES('GROUP 1','GROUP 2')) AS X(R1,R2)
 I think this is not ScalarSubquery because the result have two columns.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6725) Add a system function which returns the name of the database.

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14273860#comment-14273860
 ] 

Myrna van Lunteren commented on DERBY-6725:
---

Re refreshjardriftcheck; It looks as though you're missing JDBC 4.2 classes, so 
I suspect you're not building with a Java 8 JVM.

 Add a system function which returns the name of the database.
 -

 Key: DERBY-6725
 URL: https://issues.apache.org/jira/browse/DERBY-6725
 Project: Derby
  Issue Type: Improvement
  Components: SQL
Affects Versions: 10.12.0.0
Reporter: Rick Hillegas
Assignee: Mamta A. Satoor
 Attachments: DERBY6725_getdbname_patch1_diff.txt, 
 DERBY6725_getdbname_patch1_stat.txt


 Got this request in private conversation with a user. Other databases provide 
 this functionality. Seems straightforward to add.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-3195) Describe if default security manager policy is installed or not on each of the mechanisms to start the network server.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-3195.
-

 Describe if default security manager  policy is installed or not on each of 
 the mechanisms to start the network server.
 

 Key: DERBY-3195
 URL: https://issues.apache.org/jira/browse/DERBY-3195
 Project: Derby
  Issue Type: Improvement
  Components: Documentation, Javadoc
Affects Versions: 10.3.1.4
Reporter: Daniel John Debrunner
Assignee: Myrna van Lunteren
Priority: Minor
 Fix For: 10.12.0.0

 Attachments: DERBY-3195.diff, DERBY-3195_2.diff, DERBY-3195_doc.diff, 
 DERBY-3195_doc_2.diff, NetworkServerControl.html, NetworkServerControl.html, 
 cadminov825266.html, cadminov825266.html, tadmincbdjhhfd.html, 
 tadmincbdjhhfd.html


 The explicit mechanisms to start the network server make no mention of if 
 they install a default security manager and policy or not.
 These are at least:
 NetworkServerControl javadoc
summary - start command on command line
main() method
start() method
 derby.drda.startNetworkServerProperty
 Each start mechanism should clearly state if they install or do not install 
 the default security manager and policy.
 (Other starts commands are)
 java -jar derbynet.jar
 java -jar derbyrun.jar server start
 I didn't look to see if these document the default policy or not, not sure 
 where they are documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-3195) Describe if default security manager policy is installed or not on each of the mechanisms to start the network server.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren resolved DERBY-3195.
---
   Resolution: Fixed
Fix Version/s: 10.12.0.0

I reviewed the finished javadoc, and it looks good to me
However, I realized that the javadoc in NetworkServerControl does not put 
paragraph tags or breaks, and thus in two places, what looks like title or 
header in the .java file, came out e.g. like this:
'Start a Network Server This method [...]'.
So I added a period in two places, without bothering with a patch.

I also reviewed the latest alpha docs and the changes are now in the admin 
guide.

Resolving.



 Describe if default security manager  policy is installed or not on each of 
 the mechanisms to start the network server.
 

 Key: DERBY-3195
 URL: https://issues.apache.org/jira/browse/DERBY-3195
 Project: Derby
  Issue Type: Improvement
  Components: Documentation, Javadoc
Affects Versions: 10.3.1.4
Reporter: Daniel John Debrunner
Assignee: Myrna van Lunteren
Priority: Minor
 Fix For: 10.12.0.0

 Attachments: DERBY-3195.diff, DERBY-3195_2.diff, DERBY-3195_doc.diff, 
 DERBY-3195_doc_2.diff, NetworkServerControl.html, NetworkServerControl.html, 
 cadminov825266.html, cadminov825266.html, tadmincbdjhhfd.html, 
 tadmincbdjhhfd.html


 The explicit mechanisms to start the network server make no mention of if 
 they install a default security manager and policy or not.
 These are at least:
 NetworkServerControl javadoc
summary - start command on command line
main() method
start() method
 derby.drda.startNetworkServerProperty
 Each start mechanism should clearly state if they install or do not install 
 the default security manager and policy.
 (Other starts commands are)
 java -jar derbynet.jar
 java -jar derbyrun.jar server start
 I didn't look to see if these document the default policy or not, not sure 
 where they are documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6124) Marshalling error in JDBCDriverTest as part of CompatibilityTest

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252043#comment-14252043
 ] 

Myrna van Lunteren commented on DERBY-6124:
---

I agree with Mike, this seems a different problem from this JIRA. 
I looked over older references to marshalling errors in JIRA and it seems they 
may pop up in combination with network server client classpath issues (e.g. in 
DERBY-5852 a situation is described where a marshalling error occurs if 
derby.jar is not in the classpath; during work on DERBY-1482 someone ran into a 
problem with accessing system tables in a client connection when only 
derbyclient.jar was in the classpath; in DERBY-4688 also a problem occurred 
with only derbyclient.jar and derbytools.jar.). 
So...are you opening a network server connection?
As you have a working situation with 10.11.1.1 but not 10.10.2.0 I suggest you 
compare the classpath settings for the two environments.

If the environment/classpath settings are the same, and you still have a 
problem, you should log a new issue and describe exactly what you are trying to 
do and provide the information in derby.log. If you do, please also explain 
what you mean by 'the same driver' (what is this driver?). Also, if you do log 
a new issue, please clarify why you need a fix for 10.10.2.0 when things work 
with the later version (10.11.1.1).

 Marshalling error in JDBCDriverTest as part of CompatibilityTest
 

 Key: DERBY-6124
 URL: https://issues.apache.org/jira/browse/DERBY-6124
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.10.1.1
 Environment: Java SE 1.7.0-b147, Solaris 11, x86
 - Derby Information 
 [/localhome/tendril4.2/work/run/27358744/jars/sane/derby.jar] 10.10.1.1 - 
 (1458268)
 [/localhome/tendril4.2/work/run/27358744/jars/sane/derbytools.jar] 10.10.1.1 
 - (1458268)
 [/localhome/tendril4.2/work/run/27358744/jars/sane/derbynet.jar] 10.10.1.1 - 
 (1458268)
 [/localhome/tendril4.2/work/run/27358744/jars/sane/derbyclient.jar] 10.10.1.1 
 - (1458268)
Reporter: Dag H. Wanvik
Assignee: Rick Hillegas
 Fix For: 10.10.2.0, 10.11.1.1

 Attachments: Screen Shot 2014-12-17 at 4.50.26 PM.png, 
 derby-6124-01-aa-givePriceAserialVersionUID.diff


 Internal Oracle testing of RC 2 testing of 10.10 (Tendril Request 5574239 
 Tendril Task  3614491 ):
 * Diff file 
 derbyall/derbynetclientmats/DerbyNetClient/encodingTests/TestEnc.diff
 *** Start: TestEnc jdk1.7.0 DerbyNetClient derbynetclientmats:encodingTests 
 2013-03-21 14:55:59 ***
 derbyTesting.encoding can only be used with jdk15, skipping test
 *** End:   TestEnc jdk1.7.0 DerbyNetClient derbynetclientmats:encodingTests 
 2013-03-21 14:55:59 ***
 * Diff file 
 derbyall/derbynetclientmats/DerbyNetClient/derbynetclientmats/CompatibilityTest.diff
 *** Start: CompatibilityTest jdk1.7.0 DerbyNetClient 
 derbynetclientmats:derbynetclientmats 2013-03-21 14:55:59 ***
 0 add
  .E.
  There was 1 error:
  1) 
  testJDBCDriver(org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.JDBCDriverTest)java.sql.SQLException:
   Error marshalling or unmarshalling a user defined type: 
  org.apache.derbyTesting.functionTests.tests.lang.Price; local class 
  incompatible: stream classdesc serialVersionUID = 102726277789621992, local 
  class serialVersionUID = 1827170030595550895
  Caused by: org.apache.derby.client.am.SqlException: Error marshalling or 
  unmarshalling a user defined type: 
  org.apache.derbyTesting.functionTests.tests.lang.Price; local class 
  incompatible: stream classdesc serialVersionUID = 102726277789621992, local 
  class serialVersionUID = 1827170030595550895
  ... 22 more
  Caused by: java.io.InvalidClassException: 
  org.apache.derbyTesting.functionTests.tests.lang.Price; local class 
  incompatible: stream classdesc serialVersionUID = 102726277789621992, local 
  class serialVersionUID = 1827170030595550895
  ... 25 more
  FAILURES!!!
  Tests run: 2,  Failures: 0,  Errors: 1
 Test Failed.
 *** End:   CompatibilityTest jdk1.7.0 DerbyNetClient 
 derbynetclientmats:derbynetclientmats 2013-03-21
  14:56:04 ***
 Looking at the Price class I see it doesn't have an explicit 
 serialVersionUID. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6124) Marshalling error in JDBCDriverTest as part of CompatibilityTest

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252133#comment-14252133
 ] 

Myrna van Lunteren commented on DERBY-6124:
---

Please log a new issue and add these comments again there. Thanks!

 Marshalling error in JDBCDriverTest as part of CompatibilityTest
 

 Key: DERBY-6124
 URL: https://issues.apache.org/jira/browse/DERBY-6124
 Project: Derby
  Issue Type: Bug
  Components: Test
Affects Versions: 10.10.1.1
 Environment: Java SE 1.7.0-b147, Solaris 11, x86
 - Derby Information 
 [/localhome/tendril4.2/work/run/27358744/jars/sane/derby.jar] 10.10.1.1 - 
 (1458268)
 [/localhome/tendril4.2/work/run/27358744/jars/sane/derbytools.jar] 10.10.1.1 
 - (1458268)
 [/localhome/tendril4.2/work/run/27358744/jars/sane/derbynet.jar] 10.10.1.1 - 
 (1458268)
 [/localhome/tendril4.2/work/run/27358744/jars/sane/derbyclient.jar] 10.10.1.1 
 - (1458268)
Reporter: Dag H. Wanvik
Assignee: Rick Hillegas
 Fix For: 10.10.2.0, 10.11.1.1

 Attachments: Screen Shot 2014-12-17 at 4.50.26 PM.png, 
 derby-6124-01-aa-givePriceAserialVersionUID.diff, derby.log, exception.txt, 
 log.zip


 Internal Oracle testing of RC 2 testing of 10.10 (Tendril Request 5574239 
 Tendril Task  3614491 ):
 * Diff file 
 derbyall/derbynetclientmats/DerbyNetClient/encodingTests/TestEnc.diff
 *** Start: TestEnc jdk1.7.0 DerbyNetClient derbynetclientmats:encodingTests 
 2013-03-21 14:55:59 ***
 derbyTesting.encoding can only be used with jdk15, skipping test
 *** End:   TestEnc jdk1.7.0 DerbyNetClient derbynetclientmats:encodingTests 
 2013-03-21 14:55:59 ***
 * Diff file 
 derbyall/derbynetclientmats/DerbyNetClient/derbynetclientmats/CompatibilityTest.diff
 *** Start: CompatibilityTest jdk1.7.0 DerbyNetClient 
 derbynetclientmats:derbynetclientmats 2013-03-21 14:55:59 ***
 0 add
  .E.
  There was 1 error:
  1) 
  testJDBCDriver(org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.JDBCDriverTest)java.sql.SQLException:
   Error marshalling or unmarshalling a user defined type: 
  org.apache.derbyTesting.functionTests.tests.lang.Price; local class 
  incompatible: stream classdesc serialVersionUID = 102726277789621992, local 
  class serialVersionUID = 1827170030595550895
  Caused by: org.apache.derby.client.am.SqlException: Error marshalling or 
  unmarshalling a user defined type: 
  org.apache.derbyTesting.functionTests.tests.lang.Price; local class 
  incompatible: stream classdesc serialVersionUID = 102726277789621992, local 
  class serialVersionUID = 1827170030595550895
  ... 22 more
  Caused by: java.io.InvalidClassException: 
  org.apache.derbyTesting.functionTests.tests.lang.Price; local class 
  incompatible: stream classdesc serialVersionUID = 102726277789621992, local 
  class serialVersionUID = 1827170030595550895
  ... 25 more
  FAILURES!!!
  Tests run: 2,  Failures: 0,  Errors: 1
 Test Failed.
 *** End:   CompatibilityTest jdk1.7.0 DerbyNetClient 
 derbynetclientmats:derbynetclientmats 2013-03-21
  14:56:04 ***
 Looking at the Price class I see it doesn't have an explicit 
 serialVersionUID. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-3195) Describe if default security manager policy is installed or not on each of the mechanisms to start the network server.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-3195:
--
Attachment: DERBY-3195_doc_2.diff
tadmincbdjhhfd.html
cadminov825266.html
DERBY-3195_2.diff
NetworkServerControl.html

Thanks for the review Kim!
Attaching new versions of the patches in which I've addressed the comments.
I also went back into NetworkServerControl.java and modified various 
occurrences of 'network server' to say 'Network Server', for consistency. Also 
fixed up the 'retreive' to say 'retrieve'.
And in one of the doc pages I also added a codeph tag for the template.policy 
file.
I will commit these changes shortly, if further tweaking is called for that can 
happen in a subsequent patch.

 Describe if default security manager  policy is installed or not on each of 
 the mechanisms to start the network server.
 

 Key: DERBY-3195
 URL: https://issues.apache.org/jira/browse/DERBY-3195
 Project: Derby
  Issue Type: Improvement
  Components: Documentation, Javadoc
Affects Versions: 10.3.1.4
Reporter: Daniel John Debrunner
Assignee: Myrna van Lunteren
Priority: Minor
 Attachments: DERBY-3195.diff, DERBY-3195_2.diff, DERBY-3195_doc.diff, 
 DERBY-3195_doc_2.diff, NetworkServerControl.html, NetworkServerControl.html, 
 cadminov825266.html, cadminov825266.html, tadmincbdjhhfd.html, 
 tadmincbdjhhfd.html


 The explicit mechanisms to start the network server make no mention of if 
 they install a default security manager and policy or not.
 These are at least:
 NetworkServerControl javadoc
summary - start command on command line
main() method
start() method
 derby.drda.startNetworkServerProperty
 Each start mechanism should clearly state if they install or do not install 
 the default security manager and policy.
 (Other starts commands are)
 java -jar derbynet.jar
 java -jar derbyrun.jar server start
 I didn't look to see if these document the default policy or not, not sure 
 where they are documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DERBY-3195) Describe if default security manager policy is installed or not on each of the mechanisms to start the network server.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren reassigned DERBY-3195:
-

Assignee: Myrna van Lunteren

 Describe if default security manager  policy is installed or not on each of 
 the mechanisms to start the network server.
 

 Key: DERBY-3195
 URL: https://issues.apache.org/jira/browse/DERBY-3195
 Project: Derby
  Issue Type: Improvement
  Components: Documentation, Javadoc
Affects Versions: 10.3.1.4
Reporter: Daniel John Debrunner
Assignee: Myrna van Lunteren
Priority: Minor

 The explicit mechanisms to start the network server make no mention of if 
 they install a default security manager and policy or not.
 These are at least:
 NetworkServerControl javadoc
summary - start command on command line
main() method
start() method
 derby.drda.startNetworkServerProperty
 Each start mechanism should clearly state if they install or do not install 
 the default security manager and policy.
 (Other starts commands are)
 java -jar derbynet.jar
 java -jar derbyrun.jar server start
 I didn't look to see if these document the default policy or not, not sure 
 where they are documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-3195) Describe if default security manager policy is installed or not on each of the mechanisms to start the network server.

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-3195:
--
Attachment: NetworkServerControl.html
DERBY-3195.diff
tadmincbdjhhfd.html
cadminov825266.html
DERBY-3195_doc.diff

I am attaching two patches to address this issue.
One patch is for the adminguide - server section, to add that a security 
manager is started when network server is started.
The other patch is for the javadoc of NetworkServerControl, to add comments to 
the summary and start method sections.

I decided not to add details to NetworkServerControl's 'main' method because 
it's only on start that the security manager is installed. 
I decided not to add anything to the derby.drda.startNetworkServer section 
because I believe that when you start Derby it automatically uses a security 
manager - so it's not unexpected that it does the same for network Server.
If a change here is needed I think it makes more sense to add a reference to 
the main section about networkserver, rather than repeat information here.

I could not see a logical way to document anything regarding java -jar. I think 
using java -jar to start the main class identified in the jar's manifest file 
(in this case, NetworkServerControl is listed as the main class in 
derbynet.jar) is default java functionality, and I already changed the 
information re 'start' for NetworkServerControl.

Review will be appreciated.

 Describe if default security manager  policy is installed or not on each of 
 the mechanisms to start the network server.
 

 Key: DERBY-3195
 URL: https://issues.apache.org/jira/browse/DERBY-3195
 Project: Derby
  Issue Type: Improvement
  Components: Documentation, Javadoc
Affects Versions: 10.3.1.4
Reporter: Daniel John Debrunner
Assignee: Myrna van Lunteren
Priority: Minor
 Attachments: DERBY-3195.diff, DERBY-3195_doc.diff, 
 NetworkServerControl.html, cadminov825266.html, tadmincbdjhhfd.html


 The explicit mechanisms to start the network server make no mention of if 
 they install a default security manager and policy or not.
 These are at least:
 NetworkServerControl javadoc
summary - start command on command line
main() method
start() method
 derby.drda.startNetworkServerProperty
 Each start mechanism should clearly state if they install or do not install 
 the default security manager and policy.
 (Other starts commands are)
 java -jar derbynet.jar
 java -jar derbyrun.jar server start
 I didn't look to see if these document the default policy or not, not sure 
 where they are documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

FYI: ApacheCon NA 2015 travel assistance.

[Myrna van Lunteren]

Dear all,

There will be an ApacheCon North America, in Austin, TX, April 13-17, 2015.

For more information see:
http://apachecon.com/
and
http://events.linuxfoundation.org/events/apachecon-north-america

The Call for Papers closes Sunday, 1 February 2015.

There is travel assistance available subject to the usual rules, see:
http://www.apache.org/travel/
The closing date for travel assistance applications is Friday, 6 February
2015.

Regards,
Myrna van Lunteren
(Apache DB Project chair)

[jira] [Commented] (DERBY-6779) Provide subclass of SQLException for duplicate key insertions

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241825#comment-14241825
 ] 

Myrna van Lunteren commented on DERBY-6779:
---

There was a discussion about this issue on the user and dev lists which may 
contain further useful or background information:
user list: 
http://apache-database.10148.n7.nabble.com/Duplicate-key-feature-request-tt143327.html
dev spin off: 
http://apache-database.10148.n7.nabble.com/Fwd-Duplicate-key-feature-request-tt143371.html

 Provide subclass of SQLException for duplicate key insertions
 -

 Key: DERBY-6779
 URL: https://issues.apache.org/jira/browse/DERBY-6779
 Project: Derby
  Issue Type: Improvement
  Components: JDBC, SQL
Reporter: John English
Priority: Minor

 A commonly-occurring situation is to take some special action when an insert 
 fails due to a duplicate key; for example, to update the existing row or to 
 retry the insert with a new key (e.g. mutate Name into Name(1), Name(2) 
 etc. until a unique key is found). At present this requires code similar to:
 {noformat}
 try {
//... insert new row
 }
 catch (SQLException e) {
 if (e.getSQLState().equals(DUPLICATE_KEY)) {
 // ... take recovery action
 }
 else {
 throw e;
 }
 }
 {noformat}
 It would be more convenient if a subclass of SQLException were used to report 
 this precise error. The SQLIntegrityConstraintViolationException that is 
 currently thrown will also be thrown in other case where a constraint is 
 violated. A new exception subclass for this specific situation would not 
 affect any existing code, and would allow the code above to be simplified to 
 this:
 {noformat}
 try {
 //... insert new row
 }
 catch (DuplicateKeyException e) {// or some other suitable name
 // ... take recovery action
 }
 {noformat}
 This would allow a more elegant, more O-O solution to what is, in my 
 experience, a common use case without having to discriminate based on the 
 value of getSQLState().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren resolved DERBY-6753.
---
   Resolution: Fixed
Fix Version/s: 10.12.0.0

The changes are showing up in the latest alpha docs build. Resolving.

 Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return 
 value will be impacted by single row UPDATE of identity column
 --

 Key: DERBY-6753
 URL: https://issues.apache.org/jira/browse/DERBY-6753
 Project: Derby
  Issue Type: Task
  Components: Documentation
Affects Versions: 10.12.0.0
 Environment: Changes for DERBY-6742 will now make the newly generated 
 value for a single row UPDATE statement available through 
 IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement 
 changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very 
 localized and from my search, the changes need to go only in the reference 
 manual. 
 Basically, DERBY-6414 now allows an identity column's value to be updated 
 using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no 
 way of updating an identity column). This updated value is available through 
 IDENTITY_VAL_LOCAL if only one row was updated of a table with identity 
 column AND identity column was updated as part of that UPDATE with DEFAULT 
 clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. 
 The rules for INSERT are already documented in the reference manual.
Reporter: Mamta A. Satoor
Assignee: Myrna van Lunteren
 Fix For: 10.12.0.0

 Attachments: DERBY-6753.diff, DERBY-6753.diff_2, 
 crefjavstateautogen.html, crefjavstateautogen.html, 
 rrefidentityvallocal.html, rrefidentityvallocal.html






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-6753:
--
Attachment: DERBY-6753.diff_2
rrefidentityvallocal.html
crefjavstateautogen.html

Thanks for the thorough review, Mamta.
Attaching a second version of the patch that addresses the comments.
I will commit this shortly (any further comments  can be dealt with in a 
separate commit).

 Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return 
 value will be impacted by single row UPDATE of identity column
 --

 Key: DERBY-6753
 URL: https://issues.apache.org/jira/browse/DERBY-6753
 Project: Derby
  Issue Type: Task
  Components: Documentation
Affects Versions: 10.12.0.0
 Environment: Changes for DERBY-6742 will now make the newly generated 
 value for a single row UPDATE statement available through 
 IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement 
 changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very 
 localized and from my search, the changes need to go only in the reference 
 manual. 
 Basically, DERBY-6414 now allows an identity column's value to be updated 
 using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no 
 way of updating an identity column). This updated value is available through 
 IDENTITY_VAL_LOCAL if only one row was updated of a table with identity 
 column AND identity column was updated as part of that UPDATE with DEFAULT 
 clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. 
 The rules for INSERT are already documented in the reference manual.
Reporter: Mamta A. Satoor
Assignee: Myrna van Lunteren
 Attachments: DERBY-6753.diff, DERBY-6753.diff_2, 
 crefjavstateautogen.html, crefjavstateautogen.html, 
 rrefidentityvallocal.html, rrefidentityvallocal.html






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14237309#comment-14237309
 ] 

Myrna van Lunteren commented on DERBY-6753:
---

Note that in the new version I did *not* refer to the 'SET' clause because 
that's implied with the UPDATE statement and would only make the sentences 
longer and more confusing.

 Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return 
 value will be impacted by single row UPDATE of identity column
 --

 Key: DERBY-6753
 URL: https://issues.apache.org/jira/browse/DERBY-6753
 Project: Derby
  Issue Type: Task
  Components: Documentation
Affects Versions: 10.12.0.0
 Environment: Changes for DERBY-6742 will now make the newly generated 
 value for a single row UPDATE statement available through 
 IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement 
 changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very 
 localized and from my search, the changes need to go only in the reference 
 manual. 
 Basically, DERBY-6414 now allows an identity column's value to be updated 
 using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no 
 way of updating an identity column). This updated value is available through 
 IDENTITY_VAL_LOCAL if only one row was updated of a table with identity 
 column AND identity column was updated as part of that UPDATE with DEFAULT 
 clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. 
 The rules for INSERT are already documented in the reference manual.
Reporter: Mamta A. Satoor
Assignee: Myrna van Lunteren
 Attachments: DERBY-6753.diff, DERBY-6753.diff_2, 
 crefjavstateautogen.html, crefjavstateautogen.html, 
 rrefidentityvallocal.html, rrefidentityvallocal.html






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Fwd: Duplicate key feature request

[Myrna van Lunteren]

Moving this discussion to derby-dev...

Forgive my ignorance in this area...

I had a look at the Derby source code and we do not currently seem to have
any subclasses of SQLException, except SQLExceptionWrapper.

(There are some client exceptions that extend SqlException, but that one
extends Exception, not SQLException).

I wonder why this was not done before - presumably there was no need
before? Are there negatives connected to extending java.sql.SQLException?
Does anyone have insights on this?

Myrna


On Thu, Dec 4, 2014 at 1:44 PM, Rick Hillegas rick.hille...@gmail.com
wrote:

 On 12/4/14 2:26 AM, John English wrote:

 On 02/12/2014 00:30, Rick Hillegas wrote:

 On 12/1/14 4:08 AM, John English wrote:

 However, why not in any case consider deriving a separate subclass of
 SQLException for the duplicate key case? It wouldn't break any existing
 code,
 it's presumably easy to identify the code sites which should throw it,
 and it
 would clarify exception handling in some cases.

 Hi John,

 Note that the SQLException which is thrown is already a refined subclass
 of
 SQLException. The failed insert will throw a
 java.sql.SQLIntegrityConstraintViolationException. That may help you
 code this
 approach to the problem.


 But wouldn't this also be thrown by other causes such as a check
 constraint or foreign key violation? In such cases, an if statement would
 still be needed to check the actual cause.

 Hi John,

 Yes, that's true. You're welcome to log an enhancement request for this
 behavior.

 Regards,
 -Rick

[jira] [Commented] (DERBY-526) Network Client URL cannot take the IP Address as host name for IPV6 machines

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233166#comment-14233166
 ] 

Myrna van Lunteren commented on DERBY-526:
--

This issue has not yet been fixed...

 Network Client URL cannot take the IP Address as host name for IPV6 machines
 

 Key: DERBY-526
 URL: https://issues.apache.org/jira/browse/DERBY-526
 Project: Derby
  Issue Type: Improvement
  Components: Network Client
Affects Versions: 10.1.1.0
Reporter: Kathey Marsden

 Network Client  can not take the ip adrress as host name for 
 IPV6 machines, sicne the ip address for those machines is of the format
 xx:xx:xx:xx:xx:xx:xx:xx:. 
 The colons create a problem with our  hostname:1527 format. 
 The workaround is to use the  host name for the server machine instead of the 
 ip address



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6414) Incorrect handling when using an UPDATE to SET an identity column to DEFAULT

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-6414:
--
Fix Version/s: 10.12.0.0

 Incorrect handling when using an UPDATE to SET an identity column to DEFAULT
 

 Key: DERBY-6414
 URL: https://issues.apache.org/jira/browse/DERBY-6414
 Project: Derby
  Issue Type: Bug
  Components: SQL
Affects Versions: 10.2.2.1, 10.10.1.1
Reporter: Rick Hillegas
Assignee: Mamta A. Satoor
  Labels: derby_backport_reject_10_10
 Fix For: 10.12.0.0

 Attachments: DERBY6414_patch1_diff.txt, 
 DERBY6414_patch1_notReadyForCommit_diff.txt, DERBY6414_patch1_stat.txt, 
 DERBY6414_patch2_diff.txt, DERBY6414_patch2_stat.txt, 
 d6414-reduce-visibility.diff, releaseNote.html


 Derby violates the SQL Standard when an UPDATE statement SETs an identity 
 column to the value DEFAULT. Derby does the right thing for INSERTs, however.
 For INSERTs, the 2011 Standard defines the meaning of DEFAULT in part 2, 
 section 15.10 (Effect of inserting tables into base tables), general rule 2. 
 For INSERTs, the DEFAULT value is the next value of the sequence generator 
 which defines the identity column.
 For UPDATEs, the 2011 Standard defines the meaning of DEFAULT in part 2, 
 section 15.13 (Effect of replacing rows in base tables), general rule 5. For 
 UPDATEs, the DEFAULT value is also the next value of the sequence generator 
 which defines the identity column.
 Note also that the 2011 Standard says that a GENERATED ALWAYS identity column 
 can be SET to DEFAULT. Furthermore, that is the only explicit value accepted. 
 See the 2011 Standard, part 2, section 14.15 (set clause list), syntax rule 5:
 {
 If set clause SC specifies an object column that references a column of 
 which some underlying column is either a generated column or an identity 
 column whose descriptor indicates that values are always generated, then the 
 update source specified in SC shall consist of a default specification.
 }
 What Derby actually does for UPDATEs is the following:
 1) If the column was declared GENERATED ALWAYS, then Derby raises a 
 compile-time error saying that the value of an identity column can't be 
 overridden.
 2) If the column was declared GENERATED BY DEFAULT, then Derby raises an 
 execution time-error when trying to stuff a null into the column.
 Correcting this bug would result in backwardly incompatible behavior. 
 However, I think that the incompatibility is minor: it would mean the 
 successful run of statements which previously raised errors.
 I tripped across this problem while implementing the UPDATE action of the 
 MERGE statement (DERBY-3155). If we decide to fix this bug, we will want to 
 make sure that the UPDATE actions of MERGE statements also correctly handle 
 DEFAULT values for identity columns.
 The following script shows this problem:
 connect 'jdbc:derby:memory:db;create=true';
 create table t1( a int generated always as identity, b int );
 create table t2( a int generated by default as identity, b int );
 insert into t1( a, b ) values ( default, 100 );
 insert into t2( a, b ) values ( default, 100 );
 update t1 set a = default;
 update t2 set a = default;
 select * from t1;
 select * from t2;



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (DERBY-1690) DOCS - Complete the reltable for the Reference Manual

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren reopened DERBY-1690:
---

 DOCS - Complete the reltable for the Reference Manual
 -

 Key: DERBY-1690
 URL: https://issues.apache.org/jira/browse/DERBY-1690
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.3.1.4
Reporter: Laura Stewart

 A relationship table was added to the Ref Manual in 10.2 to document the new 
 SQL statements.
 However none of the other topics are listed in the reltable.  The reltable 
 for the Ref Manual needs to be
 completed so that related links can appear for each topic.
 This is a usability significant issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-1690) DOCS - Complete the reltable for the Reference Manual

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233325#comment-14233325
 ] 

Myrna van Lunteren commented on DERBY-1690:
---

Thanks Kim, now it makes more sense. 
This type of information doesn't come through in the PDF file, but it's what 
shows at the bottom of each of the html pages as 'related reference'.
The reference manual reltable is not empty anymore, but likely a complete 
re-evaluation of the reltable in refderby.ditamap would be useful...
But like you said, a ton of work. 
I will just reopen this and leave it like that. 

 DOCS - Complete the reltable for the Reference Manual
 -

 Key: DERBY-1690
 URL: https://issues.apache.org/jira/browse/DERBY-1690
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.3.1.4
Reporter: Laura Stewart

 A relationship table was added to the Ref Manual in 10.2 to document the new 
 SQL statements.
 However none of the other topics are listed in the reltable.  The reltable 
 for the Ref Manual needs to be
 completed so that related links can appear for each topic.
 This is a usability significant issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-6764) analyze impact of poodle security alert on Derby client - server ssl support

[Myrna van Lunteren (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1428#comment-1428
 ] 

Myrna van Lunteren commented on DERBY-6764:
---

The check-in into 10.8 caused a failure with ibm 1.4.2 in the SSLTest, see:
http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm142/1643050-suites.All_diff.txt
and
http://people.apache.org/~myrnavl/derby_test_results/v10_8/linux/testlog/ibm142/1643044-suites.All_diff.txt

I know 1.4.2 is very old now, but we were supporting that with 10.8 when it 
came out...

 analyze impact of poodle security alert on Derby client - server ssl support
 

 Key: DERBY-6764
 URL: https://issues.apache.org/jira/browse/DERBY-6764
 Project: Derby
  Issue Type: Task
Affects Versions: 10.8.3.0, 10.9.1.0, 10.10.2.0, 10.11.1.1, 10.12.0.0
Reporter: Myrna van Lunteren
Assignee: Mamta A. Satoor
 Fix For: 10.8.3.3, 10.9.2.2, 10.10.2.1, 10.11.1.3, 10.12.0.0

 Attachments: DERBY6764_10_8_backport_patch1_diff.txt, 
 DERBY6764_backport10_11_patch1_diff.txt, DERBY6764_patch1_diff.txt, 
 DERBY6764_patch1_stat.txt


 Recently, a security weakness was found in SSLv3, POODLE: SSLv3 vulnerability 
 (CVE-2014-3566)
 Derby supports ssl between the client and network server.
 We should investigate this and decide if we need to change our product, e.g. 
 to eliminate support for SSL in favor of its successor TLS.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren updated DERBY-6753:
--
Attachment: rrefidentityvallocal.html
crefjavstateautogen.html
DERBY-6753.diff

Attaching a patch that adds 'or update' wherever 'insert statement' was 
mentioned previously. 
Also adds links to the 'reltable' in the refderby.ditamap.
$ svn stat -q
M   src\ref\rrefidentityvallocal.dita
M   src\ref\crefjavstateautogen.dita
M   src\ref\refderby.ditamap
Patch ready for review.

 Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return 
 value will be impacted by single row UPDATE of identity column
 --

 Key: DERBY-6753
 URL: https://issues.apache.org/jira/browse/DERBY-6753
 Project: Derby
  Issue Type: Task
  Components: Documentation
Affects Versions: 10.12.0.0
 Environment: Changes for DERBY-6742 will now make the newly generated 
 value for a single row UPDATE statement available through 
 IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement 
 changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very 
 localized and from my search, the changes need to go only in the reference 
 manual. 
 Basically, DERBY-6414 now allows an identity column's value to be updated 
 using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no 
 way of updating an identity column). This updated value is available through 
 IDENTITY_VAL_LOCAL if only one row was updated of a table with identity 
 column AND identity column was updated as part of that UPDATE with DEFAULT 
 clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. 
 The rules for INSERT are already documented in the reference manual.
Reporter: Mamta A. Satoor
 Attachments: DERBY-6753.diff, crefjavstateautogen.html, 
 rrefidentityvallocal.html






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (DERBY-6753) Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return value will be impacted by single row UPDATE of identity column

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren reassigned DERBY-6753:
-

Assignee: Myrna van Lunteren

 Docs for IDENTITY_VAL_LOCAL needs to be updated to indicate that the return 
 value will be impacted by single row UPDATE of identity column
 --

 Key: DERBY-6753
 URL: https://issues.apache.org/jira/browse/DERBY-6753
 Project: Derby
  Issue Type: Task
  Components: Documentation
Affects Versions: 10.12.0.0
 Environment: Changes for DERBY-6742 will now make the newly generated 
 value for a single row UPDATE statement available through 
 IDENTITY_VAL_LOCAL(). Current documentation mentions only INSERT statement 
 changing the value of IDENTITY_VAL_LOCAL(). The changes in the doc are very 
 localized and from my search, the changes need to go only in the reference 
 manual. 
 Basically, DERBY-6414 now allows an identity column's value to be updated 
 using DEFAULT clause in UPDATE statement(prior to DERBY-6414, there was no 
 way of updating an identity column). This updated value is available through 
 IDENTITY_VAL_LOCAL if only one row was updated of a table with identity 
 column AND identity column was updated as part of that UPDATE with DEFAULT 
 clause. The rules for UPDATE are same as for INSERT for IDENTITY_VAL_LOCAL. 
 The rules for INSERT are already documented in the reference manual.
Reporter: Mamta A. Satoor
Assignee: Myrna van Lunteren
 Attachments: DERBY-6753.diff, crefjavstateautogen.html, 
 rrefidentityvallocal.html






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DERBY-1690) DOCS - Complete the reltable for the Reference Manual

[Myrna van Lunteren (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Myrna van Lunteren closed DERBY-1690.
-
Resolution: Invalid

I am marking this as invalid. 
It's unclear what was intended here.
Looking back at the 10.2 release notes, perhaps the 'new SQL statements' were 
'Grant' and 'Revoke', but even so, it is not clear which 'relationship table' 
(which source page?) is referred to here, or which 'other topics' are supposed 
to be listed in it, and at least in the latest alpha manuals there are numerous 
links.

 DOCS - Complete the reltable for the Reference Manual
 -

 Key: DERBY-1690
 URL: https://issues.apache.org/jira/browse/DERBY-1690
 Project: Derby
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 10.3.1.4
Reporter: Laura Stewart

 A relationship table was added to the Ref Manual in 10.2 to document the new 
 SQL statements.
 However none of the other topics are listed in the reltable.  The reltable 
 for the Ref Manual needs to be
 completed so that related links can appear for each topic.
 This is a usability significant issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)