date:20060202

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12365041 ] 

Daniel John Debrunner commented on DERBY-856:
-

It would be possible to replace the CLOB in the current error message with 
CLOB(x) where x is the correct size. In this case it would be:

CLOB(2147483647)

This would be by using 

preparedStatement.getParameterTypes()[parameterIndex-1].getSQLstring()

instead of

getEmbedParameterSetMetaData().getParameterTypeName(
  parameterIndex)


> modify setCharacterStreamInternal to take a long for the length, and perform 
> the > max int check in the method
> --
>
>  Key: DERBY-856
>  URL: http://issues.apache.org/jira/browse/DERBY-856
>  Project: Derby
> Type: Improvement
>   Components: JDBC
> Versions: 10.2.0.0
>  Environment: All Environments
> Reporter: V.Narayanan
> Assignee: V.Narayanan
> Priority: Minor
>  Attachments: setCharacterStreamInternal.diff, 
> setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, 
> setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat
>
> A similar change to setBinaryStreamInternal is being handled as part of 
> DERBY-599. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [VOTE] Bryan Pendleton as a committer

Kathey Marsden wrote:

> This vote is for establishing Bryan Pendleton  as a committer for Derby. 

+1 great example for others

Dan.

Re: [jira] Updated: (DERBY-683) Use correct encoding for ClobOutputStream on client

Deepa Remesh (JIRA) wrote:

> * Adds derbyTesting.encoding=UTF-16 to encodingTests.properties file. Adds 
> excludes for all jvms except Sun jdk1.5. 

What's the reason for not running this test on other JDKs? Seems like it
would run on JDK 1.3 and JDK 1.4.

Dan.

[jira] Updated: (DERBY-683) Use correct encoding for ClobOutputStream on client

2006-02-02 Thread Deepa Remesh (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-683?page=all ]

Deepa Remesh updated DERBY-683:
---

Attachment: derby-683_tests.diff
derby-683_tests.status

I am attaching a patch 'derby-683_tests.diff' which adds testing for this 
issue. The patch changes the harness to enable running tests/suites using an 
encoding different from the default system encoding. 


Background: 

To test DERBY-683, I wanted to run an existing test (jdbcapi/lobStreams.java) 
using an encoding which will have different representation for ASCII 
characters. I found that UTF-16 uses more number of bits and different 
representation for ASCII characters than the US-ASCII encoding. Also, UTF-16 is 
in the list of standard charsets supported by all jvms specified at 
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/charset/Charset.html 

For this, I first tried using 'jvmflags' property in the test harness. Harness 
uses this property to launch the jvm process to run tests. So it is possible to 
do this only when useprocess=true. I could run the test by specifying 
"jvmflags=-Dfile.encoding=UTF-16" in _app.properties file. However, the 
test output gets written using UTF-16 encoding and it appears in strange 
format. To read the output, harness needs to know what encoding the test jvm 
used. For this, it has to parse the jvmflags, look for "-Dfile.encoding=", get 
and store the encoding specified, launch the jvm using the encoding, and later 
use that encoding to read the test output. Since jvmflags property is used by 
harness for other purposes, I added a new property 'derbyTesting.encoding' to 
the harness. Harness will read this property to get the encoding and internally 
change jvmflags before launching the jvm to run tests. As mentioned before, all 
this is possible only when useprocess=true. 

I don't think my changes cover all the things that harness needs to support to 
run tests with different encodings. So I am trying to list what we can/cannot 
do with these changes: 
* Can specify the encoding in _app.properties file and run an individual 
test (not as part of a suite). If the encoding property is specified for a 
test, it gets used only if the test is run individually using RunTest. When the 
test gets run as part of a suite, useprocess is set to false in RunTest and no 
new jvm gets launched for the test. So the encoding property won't get used.

* Can specify the encoding in .properties file and run the whole suite 
of tests using that encoding. In this case, a new jvm is launched for RunTest 
class and all tests are run with the encoding specified. 

* Cannot successfully run sql tests if the encoding property is specified. The 
sql files will get read using the specified encoding and may not be meaningful. 
If the sql files always get read using fixed encoding, this will not be a 
problem. I think this change is planned in DERBY-658 by Myrna. 

* Can run tests/suites using encoding property and look for possible areas for 
cleanup. 

Once the patch is reviewed and if it is okay, I will update the testing readme 
file with this information.  


Changes:

This patch does the following: 

* Adds a new property 'derbyTesting.encoding' to the test harness. This 
property can be specified as a suite in .properties file or as test 
property in _app.properties file. If this property is set at suite level, 
it overrides the property set in the tests inside that suite. For this, I made 
changes to RunSuite.java, RunList.java and RunTest.java to read the property at 
each level only if it is not set at the higher level. 

* The patch uses the value specified in 'derbyTesting.encoding=' for 
two things:

1. To append to the jvmflags property used to start the child jvm process. 
Following is appended: -Dfile.encoding=. Currently, I have 
hard-coded the prefix "-Dfile.encoding=" in the code. In case any new jvm uses 
a different property name, the prefix can be specified for each jvm in the
corresponding jvm class and this can be retrieved and used.
 
2. To read the test output: 
 - when using RunTest, ProcessStreamResult class is used to read the output of 
the jvm process and write to the output file. The patch changes this class to 
use InputStreamReader which is created using  encoding. The 
OutputStreamWriter which writes to .out file is created using system default 
encoding. This needs to use the default encoding because the harness will 
compare the .out file to master using .
- when using RunSuite, HandleResult class is used to read the test output. The 
patch changes this class to use InputStreamReader which is created using 
 encoding. 

* Creates a new suite encodingTests with jdbcapi/lobStreams.java in .runall 
file. I created a new suite because I cannot specify the encoding property in a 
test and run it as part

[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the > max int check in the method

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12365037 ] 

Daniel John Debrunner commented on DERBY-856:
-

Patch looks good,  I don't agree the error message has to change, it's the 
standard Derby error message for the correct situation. We shouls not be adding 
special error messages for one off situations.

> modify setCharacterStreamInternal to take a long for the length, and perform 
> the > max int check in the method
> --
>
>  Key: DERBY-856
>  URL: http://issues.apache.org/jira/browse/DERBY-856
>  Project: Derby
> Type: Improvement
>   Components: JDBC
> Versions: 10.2.0.0
>  Environment: All Environments
> Reporter: V.Narayanan
> Assignee: V.Narayanan
> Priority: Minor
>  Attachments: setCharacterStreamInternal.diff, 
> setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, 
> setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat
>
> A similar change to setBinaryStreamInternal is being handled as part of 
> DERBY-599. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread V.Narayanan


+1

Narayanan

Kathey Marsden wrote On 02/03/06 05:25,:

This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  
Voting will close 5pm PST Thursday, Feb 9.


Since joining the project, Bryan  has submitted many high quality patches to 
correct several long standing, difficult DRDA protocol issues with Network 
Server. He has submitted fixes for:

DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569

His supporting documentation of his patches has received universal high acclaim 
and has educated many of us in the finer points of DRDA protocol.  He is an 
inspiration to others to write better comments and explanations of their 
patches.  He has also reviewed many patches, answered numerous questions and  
provided an independent, highly qualified technical voice to the project.  He 
will be a tremendous asset as a committer with Derby.

Kathey

Re: javadoc errors

2006-02-02 Thread Kathey Marsden

Rick Hillegas wrote:

> I just synced an empty client with the mainline. When I run "ant
> derbydocs" I don't see the errors you're seeing. However, I see the
> following new javadoc warnings:
>
>  [javadoc]
> C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:59:
>
> warning - @return tag has no arguments.

[snip]
I will fix.

[jira] Updated: (DERBY-917) Disable largedata/LobLimits.java test from running in network server mode

2006-02-02 Thread Sunitha Kambhampati (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-917?page=all ]

Sunitha Kambhampati updated DERBY-917:
--

Attachment: Exclude_LobLimits.diff
Derby917.stat.diff

- Add largedata/LobLimits test to DerbyNetClient.exclude and DerbyNet.exclude
-Add comments to testing README file. 

svn stat
M  java\testing\README.htm
M  
java\testing\org\apache\derbyTesting\functionTests\suites\DerbyNetClient.exclude
M  
java\testing\org\apache\derbyTesting\functionTests\suites\DerbyNet.exclude

I tested the largedata suite on linux.

The entire suite took about 4.5 hrs on a 2.8Ghz intel xeon cpu, 4gb ram linux 
machine with ibm142 running with default jvm memory heap size.
Also note, the database etc is cleaned up OK if the test finish successfully.  

I'd appreciate it if someone could review and commit this patch. Thanks. 

> Disable largedata/LobLimits.java test  from running in network server mode
> --
>
>  Key: DERBY-917
>  URL: http://issues.apache.org/jira/browse/DERBY-917
>  Project: Derby
> Type: Test
>   Components: Test
> Reporter: Sunitha Kambhampati
> Assignee: Sunitha Kambhampati
> Priority: Trivial
>  Fix For: 10.2.0.0
>  Attachments: Derby917.stat.diff, Exclude_LobLimits.diff
>
> Currently we have the following suites. 
> 1) largeDataTests which runs only in embedded mode. 
> 2) largeData which will run the largedata tests in embedded mode, in DerbyNet 
> and in DerbyNetClient frameworks. 
> The test largedata/LobLimits.java tests on large lobs (2Gb) and this will 
> work only in embedded as of now.  In case of Network Server, materialization 
> happens and hence this test cannot run there.  Hence add this test in the 
> DerbyNetClient.exclude and DerbyNet.exclude so it wont run against network 
> server.
> Work is being done to stream lobs - as part of DERBY-326 and other related 
> jira issues. ( Thanks to Tomohito and others who are working on streaming 
> related issues for network server). Once these issues are addressed,  this 
> test can also be run in network server mode. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-917) Disable largedata/LobLimits.java test from running in network server mode

2006-02-02 Thread Sunitha Kambhampati (JIRA)

Disable largedata/LobLimits.java test  from running in network server mode
--

 Key: DERBY-917
 URL: http://issues.apache.org/jira/browse/DERBY-917
 Project: Derby
Type: Test
  Components: Test  
Reporter: Sunitha Kambhampati
 Assigned to: Sunitha Kambhampati 
Priority: Trivial
 Fix For: 10.2.0.0


Currently we have the following suites. 
1) largeDataTests which runs only in embedded mode. 
2) largeData which will run the largedata tests in embedded mode, in DerbyNet 
and in DerbyNetClient frameworks. 

The test largedata/LobLimits.java tests on large lobs (2Gb) and this will work 
only in embedded as of now.  In case of Network Server, materialization happens 
and hence this test cannot run there.  Hence add this test in the 
DerbyNetClient.exclude and DerbyNet.exclude so it wont run against network 
server.

Work is being done to stream lobs - as part of DERBY-326 and other related jira 
issues. ( Thanks to Tomohito and others who are working on streaming related 
issues for network server). Once these issues are addressed,  this test can 
also be run in network server mode. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Derby - sysinfo call hangs

2006-02-02 Thread Stanley Bradbury


Mark Kurley wrote:


Hi,

I have noticed that sometimes when I call the "sysinfo" script the 
process hangs.  There are no entries in the log files.  I even when as 
far as writing a shell script that calls the "sysinfo" in a loop.  It 
fails on different iterations each time. 

Has anyone else experienced this problem?  I am not sure how to debug 
this problem.  Please pass along any information.


Thanks
-mark



*Notice:* This transmission is for the sole use of the intended 
recipient(s) and may contain information that is confidential and/or 
privileged.
If you are not the intended recipient, please delete this transmission 
and any attachments and notify the sender by return email immediately.

Any unauthorized review, use, disclosure or distribution is prohibited.


I've see the NetworkServer sysinfo (the one in 
%DERBY_INSTALL%\frameworks\NetworkServer\bin) take a long to return when 
NetworkServer has not been started.  Always thought it had something to 
do with the setting of network timeouts but don't know for sure.  Is 
this the script you are using?  Not sure why the loop would fail on 
different iterations but perhaps connections have been exhausted?

Of course if you are using the script in embedded then .. Never Mind

HTH

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Dag H. Wanvik


+1

Dag

[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the > max int check in the method

2006-02-02 Thread Sunitha Kambhampati (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12365033 ] 

Sunitha Kambhampati commented on DERBY-856:
---

The patch 'setCharacterStreamInternal_2.diff' looks good to me. Thanks for 
taking care of my comments. 

> modify setCharacterStreamInternal to take a long for the length, and perform 
> the > max int check in the method
> --
>
>  Key: DERBY-856
>  URL: http://issues.apache.org/jira/browse/DERBY-856
>  Project: Derby
> Type: Improvement
>   Components: JDBC
> Versions: 10.2.0.0
>  Environment: All Environments
> Reporter: V.Narayanan
> Assignee: V.Narayanan
> Priority: Minor
>  Attachments: setCharacterStreamInternal.diff, 
> setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, 
> setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat
>
> A similar change to setBinaryStreamInternal is being handled as part of 
> DERBY-599. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Features of the JUnit test execution harness

On 2/2/06, Andreas Korneliussen <[EMAIL PROTECTED]
> wrote:
I think the work currently done on DERBY-874 was mainly to improve theDerbyJUnitTest's JavaDoc, and to log exceptions. So I would not throw
that away.However I do propose to change DerbyJUnitTest to move out everythingabout configuration into a separate class.
cool. thx for the reply.
I now noticed that the wiki says all suggestions are to be put on the list, so here I go rather than plopping them directly on the wiki:
I think the following could qualify as 'more details' to the jvm, framework, version specific logic:
1. jvm-specific:
1.1.
not all parameters are consistent for all jvms. Think here of jit settings / configurations, memory settings. For j2ME testing, that jvm doesn't come with a DriverManager implementation, so already from the start you know you have to go with DataSources.

1.2. Different versions of a vendor's jvm also may have slightly different implementations resulting in slightly different behavior - e.g. of the order of rows, for instance, or rounding of certain numeric values.

1.3. Some behavior will be only supported by later versions...
2. version specific.
This really falls back to the discussion on ...(can't find right now, raman's working on it, I think)... re mixed version testing. I think the conclusion was that the harness needs a way to cope with results from newer servers and clients - if they differ from results with same versions as the harness.

3. framework specific
The tests needs to be able to cope with the following
3.1. different client drivers (e.g. DerbyClient, IBM Universal JDBC Driver)
3.2. server may need to be started by harness, or not
3.3. server may be on the localhost, or be running on a remote machine.
certain individual tests may not be able to run in with this mechanism...
3.4 should be able to have the harness start the server in a differrent jvm.
4. one thing the current harness has no way of doing is to cope with different OSs. For instance, sometimes there are slight differences in behaviour of the same jvm version on different OSs. Like slightly different error messages (although this may be irrelevant if we're not gathering & comparing output).

I think the following details would be useful (in addition to the above and item 1 on the wiki):
- there must be a way to skip individual tests without causing an error but with an informational message for certain configurations. eg. absence of optional jars (specifically thinking of db2jcc.jar), unsupported functionality with older jvms..., or when there is a problem that's being worked on, or that's been referred to some other organization (
e.g. in the case of jvm bugs, OS bugs...).
- some way to compare runtimestatistics.
Currently this is done by comparing the output, I have a hard time thinking of another mechanism.
Ok, that'll do for now...:-)
Myrna

Re: [jira] Resolved: (DERBY-905) derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 specific

Hi, Myrna, no, I didn't check with jdk14, I didn't know this hierarchy 
existed.


I'll retest on jdk14...  Just when I thought I had fixed this :)

I can relocate the jdk13-specific canons to the top-level, and stay 
consistent with the existing approach.


Boy, I'm glad someone around here knows how this all works :)

David

Myrna van Lunteren wrote:
On 2/2/06, *David Van Couvering (JIRA)* > wrote:


[ http://issues.apache.org/jira/browse/DERBY-905?page=all
 ]

David Van Couvering resolved DERBY-905:
---

   Resolution: Fixed

Committed revision 374550

 
 
David, I didn't check, but as far as I know the canon system 'builds' on 
earlier versions.
 
Thus, if you check in jdk13 canons, those also get picked up by jdk14 etc.

You'd need another canon for jdk14. I think.
(In fact, normally, we'd put the jdk131 canon at the top level (i.e. 
DerbyNetClient, in this case) and then add a jdk14 canon.
 
Did you re-verify with jdk14?
 
Thx,

Myrna

 
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: Not all Jira comments are making it to e-mail

On 2/2/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Myrna van Lunteren wrote (for DERBY-891):> I had run derbyall (as I reported)I missed that Myrna had said she had run tests, and then I saw that she
did say so in the jira comments of DERBY-891. I think if a comment ismarked in Jira as 'visible to derby developers' rather than visible toall then no e-mail is sent to the derby-dev list (kind of ironic).  So
I've been missing any comments attached to jira entries if anyone madethem through jira and marked them as only visible to derby developers.This is an issue as all Derby communication needs to happen on the
mailing lists, adding comments to Jira is ok, as the assumption is thecomment is also sent to the mailing list.Would this be simply fixed by making the derby-dev alias that jira usesa member of derby developers?
Dan.
 
Aha, that's why people didn't always see my comments.
:-)
 
What is the advised procedure?
Who gets the mail with 'all users'? 
Who gets the mail when you get jira-users?
And with derby-developers?
Did I miss a document that describes this? (I did a quick search but couldn't find anything useful to me).
 
Myrna

Re: Holistic getting started approach

2006-02-02 Thread Jean T. Anderson


David W. Van Couvering wrote:
Hm.  You mention that *anybody* can update the Wiki.  Perhaps that's not 
such a bad thing.  Postgres and PHP both have user-updatable 
documentation, and this has become very valuable.


I need to clarify that I didn't mean to include the Derby docs in my 
discussion below, only the main web site pages.


Is that what you're referring to for Postgres and PHP? do they support 
update of web site content separate from the product docs? I thought PHP 
had support for commenting on the product docs, but that isn't what I'm 
talking about here.


Product doc updates could also be considered, but would entail feedback 
to the DITA source for the Derby docs.




What if we had a controlled "official" version of the docs, and a 
Wikified version of the docs that can be updated/appended to by anybody?


I would actually prefer a simpler approach. If a page should be 
updateable by anyone, then move it to the Wiki.  :-)


An example of something that cannot be moved is the downloads page at 
http://db.apache.org/derby/derby_downloads.html and all it's associated 
release pages.


 -jean



Here's a thought as to how to do that:

- Use Forrest's great MVC approach to generate a Wiki-friendly version 
of the docs and publish this to the Wiki


- Allow users to annotate the docs on the Wiki site

- At next release, merge valuable user comments into the docs, and then 
generate a new Wiki-friendly set for that version


The only downside is comments that we don't consider "valuable" would 
get orphaned in prior version doc sets on the Wiki set.  But maybe 
that's OK...


Thoughts?

David

Jean T. Anderson wrote:


Daniel John Debrunner wrote:


Looking at Stan's WMD, sorry WWD document in DERBY-913 I want to promote
 a holistic approach to making getting started on Derby easier. Thus by
improving various areas such as documentation, web-site, product,
tutorials, FAQ etc. together we can gain a bigger benefit than by
increasing individual items to make up for deficiencies in other areas.




The web site needs a huge overhaul. Here are some of the issues I've 
been mulling over.


(1) Web site content isn't trivial to update

Whether the web site is in Forrest, Maven, or Anakia (those seem to be 
the big three at Apache), it involves learning the file formats those 
products support and the build process, and this learning curve is a 
barrier.


We've had a much higher rate of contribution to the Derby Wiki.

I'd like to move as much of the highly changing information on the web 
site to the Wiki as we can. For example, I think that all of 
http://db.apache.org/derby/integrate/misc.html can be moved to the 
Wiki -- and reorganized. Some is eclipsed by 
http://wiki.apache.org/db-derby/UsesOfDerby anyhow, but there are 
categories not handled by that Wiki page.


We'll have to strike some sort of balance, though. One issue with the 
Wiki is *anyone* can update it. Anything that requires controlled 
updates by committers must stay on the web site.


(2) New users can't easily find what they need

Too many responses to posts on derby-user consist of an URL to that 
information on the web site (or, lately, even on the Wiki).


The good news is we have a lot more content than we did a year and 
half ago. The bad news is I've pretty much just shovelled it in and 
some of it's pretty tangled now.


Perhaps a master "Start Here" page would help that is specifically 
tailored for new users. It could be on the web site or the Wiki, with 
a prominent tab on the web site that goes directly to that page.


(3) It's hard to find the downloads

I'm surprised by the number of requests I get which are "where are the 
downloads?" Even though downloads are on the home tab, they clearly 
aren't visible. So make downloads its own tab?


The real estate of a web browser can accommodate only so many tabs, so 
we have to choose carefully. I'm hoping to free up some time soon to 
look more closely at each of these areas.


 -jean

[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the > max int check in the method

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12365024 ] 

David Van Couvering commented on DERBY-856:
---

Hi, Narayanan.  I took a quick look at this patch.  In general it looks quite 
good, except for one nit: the error message.

Currently it says 

"The resulting value is outside the range for the data type CLOB"

I know you are using an existing message, but since we're at it, it would be 
better if it said something a little more relevant to the end user, like:

"The resulting value is has a size of {0} which exceeds the maximum length of 
{1} for a Clob in Derby"

David

> modify setCharacterStreamInternal to take a long for the length, and perform 
> the > max int check in the method
> --
>
>  Key: DERBY-856
>  URL: http://issues.apache.org/jira/browse/DERBY-856
>  Project: Derby
> Type: Improvement
>   Components: JDBC
> Versions: 10.2.0.0
>  Environment: All Environments
> Reporter: V.Narayanan
> Assignee: V.Narayanan
> Priority: Minor
>  Attachments: setCharacterStreamInternal.diff, 
> setCharacterStreamInternal.stat, setCharacterStreamInternal_1.diff, 
> setCharacterStreamInternal_2.diff, setCharacterStreamInternal_2.stat
>
> A similar change to setBinaryStreamInternal is being handled as part of 
> DERBY-599. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Returning an empty result set


The client network driver has, we do it internally.

David W. Van Couvering wrote:

Lance -- it appears that Derby has not been run through the 
conformance tests.  How does one go about doing that?  I would think 
that's pretty important.


Thanks,

David

Lance J. Andersen wrote:


The JDBC spec requires DatabaseMetaData to be fully implemented.

For non DatabaseMetaData methods not implement and not required,  a 
SQLException must be thrown and in the case of JDBC 4.0 
SQLFeatureNotSupportedException must be thrown.



Any drivers which fail to implement DatabaseMetaData methods  and 
throw an Exception would not pass the conformance tests.



HTH

Lance




David W. Van Couvering wrote:


Great question.  Odd answer.

Things are not coherent, as far as I can tell, between the network 
driver and the embedded driver.


== getUDTs() ==

*** network driver ***

call SYSIBM.SQLUDTS(?,?,?,?,?)

*** embedded driver ***

throw Util.notImplemented()

== getSuperTypes() ==

*** network driver ***

String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
"VARCHAR('', 128) AS TYPE_NAME," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
"VARCHAR('', 128) AS SUPERTYPE_NAME " +
"FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";

*** embedded driver ***

throw Util.notImplemented()



So, I'm at a bit of a loss.  Can anyone explain the history of this 
and what the "right" thing to do is.  Barring any other feedback, it 
would appear that the embedded driver is out-of-date and needs 
updating to do what the client driver does.  Another case where code 
sharing could be quite useful...


And, Lance, is it really true that every metadata call has to return 
a real result rather than throw a "Feature not implemented" exception?


David

Lance J. Andersen wrote:




David W. Van Couvering wrote:


According to our most esteemed spec lead, for the new metadata calls
that return a result set, if we don't support the metadata call, we
should return an empty result set.

Can anyone provide me some guidance as to the best way to do 
this?  The
constructor for org.apache.derby.client.am.ResultSet requires a 
lot of
parameters that I don't want to try and create, and the same is 
true for

the engine.

And a question to Lance: does it really make sense for 
getSchemas() and

getClientInfoProperties() to return an empty result set, isn't that a
bit misleading?


Hi Dave,

There is already a precedent for this type of behavior. getUDTS(), 
getSuperTypes() are an example


regards
lance
(your friendly neighborhood spec lead)


Thanks,

David

Re: [jira] Resolved: (DERBY-905) derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 specific

On 2/2/06, David Van Couvering (JIRA)  wrote:
[ http://issues.apache.org/jira/browse/DERBY-905?page=all
 ]David Van Couvering resolved DERBY-905:---   Resolution: FixedCommitted revision 374550
 
 
David, I didn't check, but as far as I know the canon system 'builds' on earlier versions.
 
Thus, if you check in jdk13 canons, those also get picked up by jdk14 etc.
You'd need another canon for jdk14. I think.
(In fact, normally, we'd put the jdk131 canon at the top level (i.e. DerbyNetClient, in this case) and then add a jdk14 canon.
 
Did you re-verify with jdk14?
 
Thx,
Myrna

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Satheesh Bandaram

+1. Brian has been really great since he joined DerbyDev Community.

Satheesh

Kathey Marsden wrote:

>This vote is for establishing Bryan Pendleton  as a committer for Derby. 
>Please vote +1 if you approve of Bryan  as a committer.  
>Voting will close 5pm PST Thursday, Feb 9.
>
>Since joining the project, Bryan  has submitted many high quality patches to 
>correct several long standing, difficult DRDA protocol issues with Network 
>Server. He has submitted fixes for:
>
>DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569
> 
>His supporting documentation of his patches has received universal high 
>acclaim and has educated many of us in the finer points of DRDA protocol.  He 
>is an inspiration to others to write better comments and explanations of their 
>patches.  He has also reviewed many patches, answered numerous questions and  
>provided an independent, highly qualified technical voice to the project.  He 
>will be a tremendous asset as a committer with Derby.
>
>Kathey
>
>
>
>
>  
>

Re: Returning an empty result set

Lance -- it appears that Derby has not been run through the conformance 
tests.  How does one go about doing that?  I would think that's pretty 
important.


Thanks,

David

Lance J. Andersen wrote:

The JDBC spec requires DatabaseMetaData to be fully implemented.

For non DatabaseMetaData methods not implement and not required,  a 
SQLException must be thrown and in the case of JDBC 4.0 
SQLFeatureNotSupportedException must be thrown.



Any drivers which fail to implement DatabaseMetaData methods  and throw 
an Exception would not pass the conformance tests.



HTH

Lance




David W. Van Couvering wrote:


Great question.  Odd answer.

Things are not coherent, as far as I can tell, between the network 
driver and the embedded driver.


== getUDTs() ==

*** network driver ***

call SYSIBM.SQLUDTS(?,?,?,?,?)

*** embedded driver ***

throw Util.notImplemented()

== getSuperTypes() ==

*** network driver ***

String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
"VARCHAR('', 128) AS TYPE_NAME," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
"VARCHAR('', 128) AS SUPERTYPE_NAME " +
"FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";

*** embedded driver ***

throw Util.notImplemented()



So, I'm at a bit of a loss.  Can anyone explain the history of this 
and what the "right" thing to do is.  Barring any other feedback, it 
would appear that the embedded driver is out-of-date and needs 
updating to do what the client driver does.  Another case where code 
sharing could be quite useful...


And, Lance, is it really true that every metadata call has to return a 
real result rather than throw a "Feature not implemented" exception?


David

Lance J. Andersen wrote:




David W. Van Couvering wrote:


According to our most esteemed spec lead, for the new metadata calls
that return a result set, if we don't support the metadata call, we
should return an empty result set.

Can anyone provide me some guidance as to the best way to do this?  The
constructor for org.apache.derby.client.am.ResultSet requires a lot of
parameters that I don't want to try and create, and the same is true 
for

the engine.

And a question to Lance: does it really make sense for getSchemas() and
getClientInfoProperties() to return an empty result set, isn't that a
bit misleading?


Hi Dave,

There is already a precedent for this type of behavior. getUDTS(), 
getSuperTypes() are an example


regards
lance
(your friendly neighborhood spec lead)


Thanks,

David

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: Holistic getting started approach

Hm.  You mention that *anybody* can update the Wiki.  Perhaps that's not 
such a bad thing.  Postgres and PHP both have user-updatable 
documentation, and this has become very valuable.


What if we had a controlled "official" version of the docs, and a 
Wikified version of the docs that can be updated/appended to by anybody?


Here's a thought as to how to do that:

- Use Forrest's great MVC approach to generate a Wiki-friendly version 
of the docs and publish this to the Wiki


- Allow users to annotate the docs on the Wiki site

- At next release, merge valuable user comments into the docs, and then 
generate a new Wiki-friendly set for that version


The only downside is comments that we don't consider "valuable" would 
get orphaned in prior version doc sets on the Wiki set.  But maybe 
that's OK...


Thoughts?

David

Jean T. Anderson wrote:

Daniel John Debrunner wrote:


Looking at Stan's WMD, sorry WWD document in DERBY-913 I want to promote
 a holistic approach to making getting started on Derby easier. Thus by
improving various areas such as documentation, web-site, product,
tutorials, FAQ etc. together we can gain a bigger benefit than by
increasing individual items to make up for deficiencies in other areas.



The web site needs a huge overhaul. Here are some of the issues I've 
been mulling over.


(1) Web site content isn't trivial to update

Whether the web site is in Forrest, Maven, or Anakia (those seem to be 
the big three at Apache), it involves learning the file formats those 
products support and the build process, and this learning curve is a 
barrier.


We've had a much higher rate of contribution to the Derby Wiki.

I'd like to move as much of the highly changing information on the web 
site to the Wiki as we can. For example, I think that all of 
http://db.apache.org/derby/integrate/misc.html can be moved to the Wiki 
-- and reorganized. Some is eclipsed by 
http://wiki.apache.org/db-derby/UsesOfDerby anyhow, but there are 
categories not handled by that Wiki page.


We'll have to strike some sort of balance, though. One issue with the 
Wiki is *anyone* can update it. Anything that requires controlled 
updates by committers must stay on the web site.


(2) New users can't easily find what they need

Too many responses to posts on derby-user consist of an URL to that 
information on the web site (or, lately, even on the Wiki).


The good news is we have a lot more content than we did a year and half 
ago. The bad news is I've pretty much just shovelled it in and some of 
it's pretty tangled now.


Perhaps a master "Start Here" page would help that is specifically 
tailored for new users. It could be on the web site or the Wiki, with a 
prominent tab on the web site that goes directly to that page.


(3) It's hard to find the downloads

I'm surprised by the number of requests I get which are "where are the 
downloads?" Even though downloads are on the home tab, they clearly 
aren't visible. So make downloads its own tab?


The real estate of a web browser can accommodate only so many tabs, so 
we have to choose carefully. I'm hoping to free up some time soon to 
look more closely at each of these areas.


 -jean
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Jean T. Anderson


Kathey Marsden wrote:
This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  


 +1

 -jean

[jira] Closed: (DERBY-841) Internationalize messages in GetResourceBundleAction to ParameterMetadata in org.apache.derby.client.am

 [ http://issues.apache.org/jira/browse/DERBY-841?page=all ]
 
David Van Couvering closed DERBY-841:
-


> Internationalize messages in GetResourceBundleAction to ParameterMetadata in 
> org.apache.derby.client.am
> ---
>
>  Key: DERBY-841
>  URL: http://issues.apache.org/jira/browse/DERBY-841
>  Project: Derby
> Type: Sub-task
>   Components: Network Client
> Reporter: David Van Couvering
> Assignee: David Van Couvering

>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (DERBY-841) Internationalize messages in GetResourceBundleAction to ParameterMetadata in org.apache.derby.client.am

 [ http://issues.apache.org/jira/browse/DERBY-841?page=all ]
 
David Van Couvering resolved DERBY-841:
---

Resolution: Fixed

Submitted revision 374203

> Internationalize messages in GetResourceBundleAction to ParameterMetadata in 
> org.apache.derby.client.am
> ---
>
>  Key: DERBY-841
>  URL: http://issues.apache.org/jira/browse/DERBY-841
>  Project: Derby
> Type: Sub-task
>   Components: Network Client
> Reporter: David Van Couvering
> Assignee: David Van Couvering

>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Holistic getting started approach

2006-02-02 Thread Jean T. Anderson


Daniel John Debrunner wrote:

Looking at Stan's WMD, sorry WWD document in DERBY-913 I want to promote
 a holistic approach to making getting started on Derby easier. Thus by
improving various areas such as documentation, web-site, product,
tutorials, FAQ etc. together we can gain a bigger benefit than by
increasing individual items to make up for deficiencies in other areas.


The web site needs a huge overhaul. Here are some of the issues I've 
been mulling over.


(1) Web site content isn't trivial to update

Whether the web site is in Forrest, Maven, or Anakia (those seem to be 
the big three at Apache), it involves learning the file formats those 
products support and the build process, and this learning curve is a 
barrier.


We've had a much higher rate of contribution to the Derby Wiki.

I'd like to move as much of the highly changing information on the web 
site to the Wiki as we can. For example, I think that all of 
http://db.apache.org/derby/integrate/misc.html can be moved to the Wiki 
-- and reorganized. Some is eclipsed by 
http://wiki.apache.org/db-derby/UsesOfDerby anyhow, but there are 
categories not handled by that Wiki page.


We'll have to strike some sort of balance, though. One issue with the 
Wiki is *anyone* can update it. Anything that requires controlled 
updates by committers must stay on the web site.


(2) New users can't easily find what they need

Too many responses to posts on derby-user consist of an URL to that 
information on the web site (or, lately, even on the Wiki).


The good news is we have a lot more content than we did a year and half 
ago. The bad news is I've pretty much just shovelled it in and some of 
it's pretty tangled now.


Perhaps a master "Start Here" page would help that is specifically 
tailored for new users. It could be on the web site or the Wiki, with a 
prominent tab on the web site that goes directly to that page.


(3) It's hard to find the downloads

I'm surprised by the number of requests I get which are "where are the 
downloads?" Even though downloads are on the home tab, they clearly 
aren't visible. So make downloads its own tab?


The real estate of a web browser can accommodate only so many tabs, so 
we have to choose carefully. I'm hoping to free up some time soon to 
look more closely at each of these areas.


 -jean

[jira] Resolved: (DERBY-905) derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 specific

 [ http://issues.apache.org/jira/browse/DERBY-905?page=all ]
 
David Van Couvering resolved DERBY-905:
---

Resolution: Fixed

Committed revision 374550

> derbyall nightly failure in LOBTest running under DerbyNetClient - jdk131 
> specific
> --
>
>  Key: DERBY-905
>  URL: http://issues.apache.org/jira/browse/DERBY-905
>  Project: Derby
> Type: Bug
>   Components: Regression Test Failure
> Versions: 10.1.2.2
>  Environment: sun jdk1.3.1_15
> Reporter: Mike Matrigali
> Assignee: David Van Couvering
>  Fix For: 10.2.0.0

>
> The following nightly regression happened in the 1/27 codeline, it also 
> failed on 1/20 but worked on 1/13.
> *** Start: LOBTest jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 2006-01-29 
> 05:59:59 ***
> 48 del
> < 1 getDate  ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 101is invalid for requested conversion 
> to java.sql.Date.)
> 48a48
> > 1 getDate  ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 101is invalid for requested 
> > conversion to java.sql.Date. Caused by exception class 
> > java.lang.IllegalArgumentException: null)
> 56 del
> < 1 getTime  ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 101is invalid for requested conversion 
> to java.sql.Time.)
> 57 del
> < 1 getTimeStamp ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 101is invalid for requested conversion 
> to java.sql.Timestamp.)
> 57a56,57
> > 1 getTime  ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 101is invalid for requested 
> > conversion to java.sql.Time. Caused by exception class 
> > java.lang.IllegalArgumentException: null)
> > 1 getTimeStamp ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 101is invalid for requested 
> > conversion to java.sql.Timestamp. Caused by exception class 
> > java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
> > hh:mm:ss.f)
> 71 del
> < 2 getDate  ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 102 is invalid for requested conversion to 
> java.sql.Date.)
> 71a71
> > 2 getDate  ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 102 is invalid for requested conversion to 
> > java.sql.Date. Caused by exception class 
> > java.lang.IllegalArgumentException: null)
> 79 del
> < 2 getTime  ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 102 is invalid for requested conversion to 
> java.sql.Time.)
> 80 del
> < 2 getTimeStamp ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 102 is invalid for requested conversion to 
> java.sql.Timestamp.)
> 80a79,80
> > 2 getTime  ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 102 is invalid for requested conversion to 
> > java.sql.Time. Caused by exception class 
> > java.lang.IllegalArgumentException: null)
> > 2 getTimeStamp ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 102 is invalid for requested conversion to 
> > java.sql.Timestamp. Caused by exception class 
> > java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
> > hh:mm:ss.f)
> 94 del
> < 3 getDate  ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 103 is invalid for requested conversion to 
> java.sql.Date.)
> 94a94
> > 3 getDate  ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 103 is invalid for requested conversion to 
> > java.sql.Date. Caused by exception class 
> > java.lang.IllegalArgumentException: null)
> 102 del
> < 3 getTime  ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 103 is invalid for requested conversion to 
> java.sql.Time.)
> 103 del
> < 3 getTimeStamp ->   EXCEPTION (Invalid data 
> conversion: Parameter instance 103 is invalid for requested conversion to 
> java.sql.Timestamp.)
> 103a102,103
> > 3 getTime  ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 103 is invalid for requested conversion to 
> > java.sql.Time. Caused by exception class 
> > java.lang.IllegalArgumentException: null)
> > 3 getTimeStamp ->   EXCEPTION (Invalid data 
> > conversion: Parameter instance 103 is invalid for requested conversion to 
> > java.sql.Timestamp. Caused by exception class 
> > java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
> > hh:mm:ss.f)
> 6

[jira] Commented: (DERBY-916) documentation to address Derby-239: online backup

2006-02-02 Thread Eric Radzinski (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-916?page=comments#action_12365020 ] 

Eric Radzinski commented on DERBY-916:
--

Can somebody confirm that this is what is required to document Derby-239:

Reference Guide:
Add the following two new stored procedures:
--SYSC_UTIL.SYSCS_ONLINE_BACKUP_DATABASE_NOWAIT and
--SYSC_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT

Also, it doesn't look like there are any changes to the 
SYSCS_UTIL.SYSCS_BACKUP_DATABASE topic.  Is that correct?

Server and Admin Guide:
--Remove references to update operations not being possible during a backup 
(there are a lot of these)
--Add topic about performing an online backup in which unlogged operations 
immediately return an error.

Anything else?

> documentation to address Derby-239: online backup
> -
>
>  Key: DERBY-916
>  URL: http://issues.apache.org/jira/browse/DERBY-916
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Versions: 10.0.2.0
> Reporter: Eric Radzinski
> Assignee: Eric Radzinski

>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [VOTE] Bryan Pendleton as a committer

On 2/2/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
This vote is for establishing Bryan Pendleton  as a committer for Derby.Please vote +1 if you approve of Bryan  as a committer.
Voting will close 5pm PST Thursday, Feb 9.
 
+1

[jira] Created: (DERBY-916) documentation to address Derby-239: online backup

2006-02-02 Thread Eric Radzinski (JIRA)

documentation to address Derby-239: online backup
-

 Key: DERBY-916
 URL: http://issues.apache.org/jira/browse/DERBY-916
 Project: Derby
Type: Sub-task
  Components: Documentation  
Versions: 10.0.2.0
Reporter: Eric Radzinski
 Assigned to: Eric Radzinski 




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Rajesh Kartha



This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  
Voting will close 5pm PST Thursday, Feb 9.


 


+1

-Rajesh

Re: javadoc errors

2006-02-02 Thread Rick Hillegas


Hi Mike,

I just synced an empty client with the mainline. When I run "ant 
derbydocs" I don't see the errors you're seeing. However, I see the 
following new javadoc warnings:


 [javadoc] 
C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:59:

warning - @return tag has no arguments.
 [javadoc] 
C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:349:

warning - @return tag has no arguments.
 [javadoc] 
C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\catalog\SystemProcedures.jav

a:1208: warning - @return tag has no arguments.
 [javadoc] 
C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:116:

warning - @return tag has no arguments.
 [javadoc] 
C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:408:

warning - @return tag has no arguments.
 [javadoc] 
C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:458:

warning - @return tag has no arguments.
 [javadoc] 
C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:506:

warning - @return tag has no arguments.
 [javadoc] 
C:\cygwin\home\rh161140\derby\mainline\trunk\javadoc\sourcedir\org\apache\derby\client\am\DateTime.java:161:

warning - @return tag has no arguments.

Mike Matrigali wrote:

After the recent checkin I am still getting a few javadoc errors (WAY 
less after rick's work), I am wondering if these are particular to my 
build environment.  Rick's recent message seemed to indicate he was

getting none.  Is anyone else seeing them:
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\ClientPooledConnection.java:28: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Connection.java:24: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlWarning.java:25: 
package org.apache.derby.shared.common.info does not exist

  [javadoc] import org.apache.derby.shared.common.info.JVMInfo;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:27: 
package org.apache.derby.shared.common.info does not exist

  [javadoc] import org.apache.derby.shared.common.info.JVMInfo;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:28: 
package org.apache.derby.shared.common.i18n does not exist

  [javadoc] import org.apache.derby.shared.common.i18n.MessageUtil;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:29: 
package org.apache.derby.shared.common.error does not exist

  [javadoc] import org.apache.derby.shared.common.error.ExceptionUtil;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\LogWriter.java:26: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\CallableStatement.java:24: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Sqlca.java:23: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\ResultSet.java:25: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:95: 
cannot resolve symbol

  [javadoc] symbol  : class MessageUtil
  [javadoc] location: class org.apache.derby.client.am.SqlException
  [javadoc] private static MessageUtil msgutil_ =
  [javadoc]^
  [jav

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Manjula G Kutty


Rick Hillegas wrote:


Kathey Marsden wrote:

This vote is for establishing Bryan Pendleton  as a committer for 
Derby. Please vote +1 if you approve of Bryan  as a committer.  
Voting will close 5pm PST Thursday, Feb 9.
 


+1


+1

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Rick Hillegas


Kathey Marsden wrote:

This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  
Voting will close 5pm PST Thursday, Feb 9.
 


+1

[jira] Resolved: (DERBY-906) parameterMapping test in DerbyAll nightly regression under DerbyNetClient, specific to jdk1.3.1

 [ http://issues.apache.org/jira/browse/DERBY-906?page=all ]
 
David Van Couvering resolved DERBY-906:
---

Resolution: Fixed

Committed revision 374548

> parameterMapping test in DerbyAll nightly regression under DerbyNetClient, 
> specific to jdk1.3.1
> ---
>
>  Key: DERBY-906
>  URL: http://issues.apache.org/jira/browse/DERBY-906
>  Project: Derby
> Type: Bug
>   Components: Regression Test Failure
> Versions: 10.1.2.2
>  Environment: sun jdk1.3.1_15
> Reporter: Mike Matrigali
> Assignee: David Van Couvering
> Priority: Critical
>  Fix For: 10.2.0.0

>
> The following regression test  failed on 1/27 and 1/20, but did not fail on 
> 1/13.
> It looks to be specific to jdk1.3.1_15 - have not seen errors in 1.4 or 1.5 
> runs.
> *** Start: parameterMapping jdk1.3.1_15 DerbyNetClient derbynetmats:jdbcapi 
> 2006-01-29 06:01:00 ***
> 1257 del
> <   getDate= (?):Invalid data conversion: Parameter instance 32   
> is invalid for requested 
> conversion to java.sql.Date. JDBC FAIL CHAR(60)
> 1258 del
> <   getTime= (?):Invalid data conversion: Parameter instance 32   
> is invalid for requested 
> conversion to java.sql.Time. JDBC FAIL CHAR(60)
> 1259 del
> <   getTimestamp= (?):Invalid data conversion: Parameter instance 32  
>  is invalid for requested 
> conversion to java.sql.Timestamp. JDBC FAIL CHAR(60)
> 1259a1257,1259
> >   getDate= (?):Invalid data conversion: Parameter instance 32   
> > is invalid for requested 
> > conversion to java.sql.Date. Caused by exception class 
> > java.lang.IllegalArgumentException: null JDBC FAIL CHAR(60)
> >   getTime= (?):Invalid data conversion: Parameter instance 32   
> > is invalid for requested 
> > conversion to java.sql.Time. Caused by exception class 
> > java.lang.IllegalArgumentException: null JDBC FAIL CHAR(60)
> >   getTimestamp= (?):Invalid data conversion: Parameter instance 32  
> >  is invalid for 
> > requested conversion to java.sql.Timestamp. Caused by exception class 
> > java.lang.IllegalArgumentException: Timestamp format must be -mm-dd 
> > hh:mm:ss.f JDBC FAIL CHAR(60)
> 1429 del
> <   getDate= (?):Invalid data conversion: Parameter instance 32 is 
> invalid for requested conversion to java.sql.Date. JDBC FAIL VARCHAR(60)
> 1430 del
> <   getTime= (?):Invalid data conversion: Parameter instance 32 is 
> invalid for requested conversion to java.sql.Time. JDBC FAIL VARCHAR(60)
> 1431 del
> <   getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
> invalid for requested conversion to java.sql.Timestamp. JDBC FAIL VARCHAR(60)
> 1431a1429,1431
> >   getDate= (?):Invalid data conversion: Parameter instance 32 is 
> > invalid for requested conversion to java.sql.Date. Caused by exception 
> > class java.lang.IllegalArgumentException: null JDBC FAIL VARCHAR(60)
> >   getTime= (?):Invalid data conversion: Parameter instance 32 is 
> > invalid for requested conversion to java.sql.Time. Caused by exception 
> > class java.lang.IllegalArgumentException: null JDBC FAIL VARCHAR(60)
> >   getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
> > invalid for requested conversion to java.sql.Timestamp. Caused by exception 
> > class java.lang.IllegalArgumentException: Timestamp format must be 
> > -mm-dd hh:mm:ss.f JDBC FAIL VARCHAR(60)
> 1601 del
> <   getDate= (?):Invalid data conversion: Parameter instance 32 is 
> invalid for requested conversion to java.sql.Date. JDBC FAIL LONG VARCHAR
> 1602 del
> <   getTime= (?):Invalid data conversion: Parameter instance 32 is 
> invalid for requested conversion to java.sql.Time. JDBC FAIL LONG VARCHAR
> 1603 del
> <   getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
> invalid for requested conversion to java.sql.Timestamp. JDBC FAIL LONG VARCHAR
> 1603a1601,1603
> >   getDate= (?):Invalid data conversion: Parameter instance 32 is 
> > invalid for requested conversion to java.sql.Date. Caused by exception 
> > class java.lang.IllegalArgumentException: null JDBC FAIL LONG VARCHAR
> >   getTime= (?):Invalid data conversion: Parameter instance 32 is 
> > invalid for requested conversion to java.sql.Time. Caused by exception 
> > class java.lang.IllegalArgumentException: null JDBC FAIL LONG VARCHAR
> >   getTimestamp= (?):Invalid data conversion: Parameter instance 32 is 
> > invalid for requested conversion to java.sql.Timestamp. Caused by exception 
> > class java.

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Mamta Satoor

+1
On 2/2/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
+1, way +1!Kathey Marsden wrote:> This vote is for establishing Bryan Pendleton  as a committer for Derby.
> Please vote +1 if you approve of Bryan  as a committer.> Voting will close 5pm PST Thursday, Feb 9.>> Since joining the project, Bryan  has submitted many high quality patches to correct several long standing, difficult DRDA protocol issues with Network Server. He has submitted fixes for:
>> DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569>> His supporting documentation of his patches has received universal high acclaim and has educated many of us in the finer points of DRDA protocol.  He is an inspiration to others to write better comments and explanations of their patches.  He has also reviewed many patches, answered numerous questions and  provided an independent, highly qualified technical voice to the project.  He will be a tremendous asset as a committer with Derby.
>> Kathey>>

Re: [VOTE] Bryan Pendleton as a committer


+1, way +1!

Kathey Marsden wrote:
This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  
Voting will close 5pm PST Thursday, Feb 9.


Since joining the project, Bryan  has submitted many high quality patches to 
correct several long standing, difficult DRDA protocol issues with Network 
Server. He has submitted fixes for:

DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569
 
His supporting documentation of his patches has received universal high acclaim and has educated many of us in the finer points of DRDA protocol.  He is an inspiration to others to write better comments and explanations of their patches.  He has also reviewed many patches, answered numerous questions and  provided an independent, highly qualified technical voice to the project.  He will be a tremendous asset as a committer with Derby.


Kathey


begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Sunitha Kambhampati


Kathey Marsden wrote:

This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  
 


+1

sunitha.

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Jeffrey Lichtman




This vote is for establishing Bryan Pendleton  as a committer for Derby.
Please vote +1 if you approve of Bryan  as a committer.


+1


   -Jeff Lichtman
[EMAIL PROTECTED]
Check out Swazoo Koolak's Web Jukebox at
http://swazoo.com/

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Army


Kathey Marsden wrote:
This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.


+1

Army

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Deepa Remesh

On 2/2/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
> This vote is for establishing Bryan Pendleton  as a committer for Derby.
> Please vote +1 if you approve of Bryan  as a committer.

+1

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Suresh Thalamati


+1

Kathey Marsden wrote:
This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  
Voting will close 5pm PST Thursday, Feb 9.


Since joining the project, Bryan  has submitted many high quality patches to 
correct several long standing, difficult DRDA protocol issues with Network 
Server. He has submitted fixes for:

DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569
 
His supporting documentation of his patches has received universal high acclaim and has educated many of us in the finer points of DRDA protocol.  He is an inspiration to others to write better comments and explanations of their patches.  He has also reviewed many patches, answered numerous questions and  provided an independent, highly qualified technical voice to the project.  He will be a tremendous asset as a committer with Derby.


Kathey

Re: [VOTE] Bryan Pendleton as a committer





+1

Kathey Marsden wrote:

  Kathey Marsden wrote:

  
  
This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  
 


  
  +1

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Andrew McIntyre

On 2/2/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
> This vote is for establishing Bryan Pendleton  as a committer for Derby.
> Please vote +1 if you approve of Bryan  as a committer.
> Voting will close 5pm PST Thursday, Feb 9.

+1

andrew

Re: [VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Kathey Marsden

Kathey Marsden wrote:

>This vote is for establishing Bryan Pendleton  as a committer for Derby. 
>Please vote +1 if you approve of Bryan  as a committer.  
>  
>
+1

[VOTE] Bryan Pendleton as a committer

2006-02-02 Thread Kathey Marsden

This vote is for establishing Bryan Pendleton  as a committer for Derby. 
Please vote +1 if you approve of Bryan  as a committer.  
Voting will close 5pm PST Thursday, Feb 9.

Since joining the project, Bryan  has submitted many high quality patches to 
correct several long standing, difficult DRDA protocol issues with Network 
Server. He has submitted fixes for:

DERBY-614, DERBY-125, DERBY-170, DERBY-491, DERBY-492, DERBY-395, DERBY-569
 
His supporting documentation of his patches has received universal high acclaim 
and has educated many of us in the finer points of DRDA protocol.  He is an 
inspiration to others to write better comments and explanations of their 
patches.  He has also reviewed many patches, answered numerous questions and  
provided an independent, highly qualified technical voice to the project.  He 
will be a tremendous asset as a committer with Derby.

Kathey

[jira] Resolved: (DERBY-904) big decimal error diff in derbyall lang/procedure test run in the DerbyNetClient - jdk1.3 specific

 [ http://issues.apache.org/jira/browse/DERBY-904?page=all ]
 
David Van Couvering resolved DERBY-904:
---

Resolution: Fixed

Committed revision 374543

> big decimal error diff in derbyall lang/procedure test run in the 
> DerbyNetClient - jdk1.3 specific
> --
>
>  Key: DERBY-904
>  URL: http://issues.apache.org/jira/browse/DERBY-904
>  Project: Derby
> Type: Bug
>   Components: Regression Test Failure
> Versions: 10.2.0.0
>  Environment: sun jdk1.3.1
> Reporter: Mike Matrigali
> Assignee: David Van Couvering
> Priority: Critical

>
> derby all regression test failure in the following test.  Most recently it 
> failed in the 1/27 derby build.  It also failed on 1/20.  It ran fine on 
> 1/13.  Have
> not had time to narrow down further.  Did note that there is a separate 
> master for this test , but no jdk131 specific masters that I could see.
> *** Start: procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
> 2006-01-22 05:30:23 ***
> 274 del
> < EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
> Overflow occurred during numeric data type conversion of "10243".. See 
> attached Throwable.
> 274a274
> > EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
> > Overflow occurred during numeric data type conversion of "10243".. See 
> > attached Throwable. Caused by exception class 
> > org.apache.derby.client.am.ConversionException: [converters] Overflow 
> > occurred during numeric data type conversion of "10243".
> 337 del
> < EXPECTED SQL Exception: Invalid argument: parameter index 2 is not an OUT 
> or INOUT parameter.
> 337a337
> > EXPECTED SQL Exception: XN009.S : [0] 2
> 355 del
> < EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
> Overflow occurred during numeric data type conversion of "102.33".. See 
> attached Throwable.
> 355a355
> > EXPECTED SQL Exception: BigDecimal conversion exception [converters] 
> > Overflow occurred during numeric data type conversion of "102.33".. See 
> > attached Throwable. Caused by exception class 
> > org.apache.derby.client.am.ConversionException: [converters] Overflow 
> > occurred during numeric data type conversion of "102.33".
> Test Failed.
> *** End:   procedure jdk1.3.1_15 DerbyNetClient derbynetmats:derbynetmats 
> 2006-01-22 05:31:39 ***

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Returning an empty result set

David W. Van Couvering wrote:

> Well, then, I think we have a bug in EmbedDatabaseMetadata,
> EmbedDatabaseMetadata40, and NetDatabaesMetadata40.  I'll log JIRA items.
> 
> I also noticed that getSuperTypes() in the network client does what I
> need to do: it calls a "fake" query on the server, and then returns what
> must be an empty result set.  I'll use that approach where necessary.

This is done for emebdded as well, see getCatalogs(), maybe just not all
the DMD methods where an empty result set could be return.

Dan.

[jira] Assigned: (DERBY-915) EmbedDatabaseMetadata, EmbedDatabaseMetadata40, and client.net.NetDatabaseMetadata40 should not throw a "not implemented" exception

 [ http://issues.apache.org/jira/browse/DERBY-915?page=all ]

David Van Couvering reassigned DERBY-915:
-

Assign To: David Van Couvering

> EmbedDatabaseMetadata, EmbedDatabaseMetadata40, and 
> client.net.NetDatabaseMetadata40 should not throw a "not implemented" 
> exception
> ---
>
>  Key: DERBY-915
>  URL: http://issues.apache.org/jira/browse/DERBY-915
>  Project: Derby
> Type: Bug
> Reporter: David Van Couvering
> Assignee: David Van Couvering

>
> Per this email from Lance Andersen, JDBC4 spec lead:
> "The JDBC spec requires DatabaseMetaData to be fully implemented.
> For non DatabaseMetaData methods not implement and not required,  a 
> SQLException must be thrown and in the case of JDBC 4.0 
> SQLFeatureNotSupportedException must be thrown.
> Any drivers which fail to implement DatabaseMetaData methods  and throw an 
> Exception would not pass the conformance tests.
> HTH
> Lance"
> These metadata calls need to be modified to return either true/false for 
> boolean methods, or an empty result set for methods that return result sets.
> The client.am.DatabaseMetadata.getSuperTypes() has a good example of how to 
> generate an empty result set:
> String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
> "CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
> "VARCHAR('', 128) AS TYPE_NAME," +
> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
> "CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
> "VARCHAR('', 128) AS SUPERTYPE_NAME " +
> "FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-915) EmbedDatabaseMetadata, EmbedDatabaseMetadata40, and client.net.NetDatabaseMetadata40 should not throw a "not implemented" exception

EmbedDatabaseMetadata, EmbedDatabaseMetadata40, and 
client.net.NetDatabaseMetadata40 should not throw a "not implemented" exception
---

 Key: DERBY-915
 URL: http://issues.apache.org/jira/browse/DERBY-915
 Project: Derby
Type: Bug
Reporter: David Van Couvering


Per this email from Lance Andersen, JDBC4 spec lead:

"The JDBC spec requires DatabaseMetaData to be fully implemented.

For non DatabaseMetaData methods not implement and not required,  a 
SQLException must be thrown and in the case of JDBC 4.0 
SQLFeatureNotSupportedException must be thrown.


Any drivers which fail to implement DatabaseMetaData methods  and throw an 
Exception would not pass the conformance tests.


HTH

Lance"

These metadata calls need to be modified to return either true/false for 
boolean methods, or an empty result set for methods that return result sets.

The client.am.DatabaseMetadata.getSuperTypes() has a good example of how to 
generate an empty result set:

String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
"VARCHAR('', 128) AS TYPE_NAME," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
"VARCHAR('', 128) AS SUPERTYPE_NAME " +
"FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Returning an empty result set

Well, then, I think we have a bug in EmbedDatabaseMetadata, 
EmbedDatabaseMetadata40, and NetDatabaesMetadata40.  I'll log JIRA items.


I also noticed that getSuperTypes() in the network client does what I 
need to do: it calls a "fake" query on the server, and then returns what 
must be an empty result set.  I'll use that approach where necessary.


David

Lance J. Andersen wrote:

The JDBC spec requires DatabaseMetaData to be fully implemented.

For non DatabaseMetaData methods not implement and not required,  a 
SQLException must be thrown and in the case of JDBC 4.0 
SQLFeatureNotSupportedException must be thrown.



Any drivers which fail to implement DatabaseMetaData methods  and throw 
an Exception would not pass the conformance tests.



HTH

Lance




David W. Van Couvering wrote:


Great question.  Odd answer.

Things are not coherent, as far as I can tell, between the network 
driver and the embedded driver.


== getUDTs() ==

*** network driver ***

call SYSIBM.SQLUDTS(?,?,?,?,?)

*** embedded driver ***

throw Util.notImplemented()

== getSuperTypes() ==

*** network driver ***

String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
"VARCHAR('', 128) AS TYPE_NAME," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
"VARCHAR('', 128) AS SUPERTYPE_NAME " +
"FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";

*** embedded driver ***

throw Util.notImplemented()



So, I'm at a bit of a loss.  Can anyone explain the history of this 
and what the "right" thing to do is.  Barring any other feedback, it 
would appear that the embedded driver is out-of-date and needs 
updating to do what the client driver does.  Another case where code 
sharing could be quite useful...


And, Lance, is it really true that every metadata call has to return a 
real result rather than throw a "Feature not implemented" exception?


David

Lance J. Andersen wrote:




David W. Van Couvering wrote:


According to our most esteemed spec lead, for the new metadata calls
that return a result set, if we don't support the metadata call, we
should return an empty result set.

Can anyone provide me some guidance as to the best way to do this?  The
constructor for org.apache.derby.client.am.ResultSet requires a lot of
parameters that I don't want to try and create, and the same is true 
for

the engine.

And a question to Lance: does it really make sense for getSchemas() and
getClientInfoProperties() to return an empty result set, isn't that a
bit misleading?


Hi Dave,

There is already a precedent for this type of behavior. getUDTS(), 
getSuperTypes() are an example


regards
lance
(your friendly neighborhood spec lead)


Thanks,

David

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: Returning an empty result set


The JDBC spec requires DatabaseMetaData to be fully implemented.

For non DatabaseMetaData methods not implement and not required,  a 
SQLException must be thrown and in the case of JDBC 4.0 
SQLFeatureNotSupportedException must be thrown.



Any drivers which fail to implement DatabaseMetaData methods  and throw 
an Exception would not pass the conformance tests.



HTH

Lance




David W. Van Couvering wrote:


Great question.  Odd answer.

Things are not coherent, as far as I can tell, between the network 
driver and the embedded driver.


== getUDTs() ==

*** network driver ***

call SYSIBM.SQLUDTS(?,?,?,?,?)

*** embedded driver ***

throw Util.notImplemented()

== getSuperTypes() ==

*** network driver ***

String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
"VARCHAR('', 128) AS TYPE_NAME," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
"VARCHAR('', 128) AS SUPERTYPE_NAME " +
"FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";

*** embedded driver ***

throw Util.notImplemented()



So, I'm at a bit of a loss.  Can anyone explain the history of this 
and what the "right" thing to do is.  Barring any other feedback, it 
would appear that the embedded driver is out-of-date and needs 
updating to do what the client driver does.  Another case where code 
sharing could be quite useful...


And, Lance, is it really true that every metadata call has to return a 
real result rather than throw a "Feature not implemented" exception?


David

Lance J. Andersen wrote:




David W. Van Couvering wrote:


According to our most esteemed spec lead, for the new metadata calls
that return a result set, if we don't support the metadata call, we
should return an empty result set.

Can anyone provide me some guidance as to the best way to do this?  The
constructor for org.apache.derby.client.am.ResultSet requires a lot of
parameters that I don't want to try and create, and the same is true 
for

the engine.

And a question to Lance: does it really make sense for getSchemas() and
getClientInfoProperties() to return an empty result set, isn't that a
bit misleading?


Hi Dave,

There is already a precedent for this type of behavior. getUDTS(), 
getSuperTypes() are an example


regards
lance
(your friendly neighborhood spec lead)


Thanks,

David

Re: Holistic getting started approach

Sunitha Kambhampati wrote:

> Daniel John Debrunner wrote:
> < snip - lots of great stuff>
> 
>> Can these jars be executed directly, I thought on windows one could
>> double-click a jar file and have it run right away, doesn't seem to
>> happen on my machine though?
>>
>>  
>>
> I found this on http://java.sun.com/j2se/1.4.2/docs/guide/jar/jarGuide.html
> 
> "On Microsoft Windows systems, the Java 2 Runtime Environment's
> installation program will register a default association for Jar files
> so that double-clicking a Jar file on the desktop will automatically run
> it with javaw -jar. Dependent extensions bundled with the application
> will also be loaded automatically. This feature makes the end-user
> runtime environment easier to use on Microsoft Windows systems"

Hmmm, javaw is going to be a problem for ij because I think it starts
with no system in/out or a console. I did try that with my ij.jar and it
just hung and could not be killed with ^C

Dan.

Re: Holistic getting started approach

David W. Van Couvering wrote:

> Solving the classpath issue would be a great win.  Not only could we fix
> ij this way, we could provide guidance to users so they can set up an
> executable application jar that includes derby.jar so that Derby
> application users also don't have to deal with classpath.

Right we've made progress in this area already, derbynet.jar
automatically includes derby.jar (from 10.1) and now derby.jar
automatically includes the locale files.

So this does work

> java -jar jars/sane/derbynet.jar start
Server is ready to accept connections on port 1527.

Dan.

Re: Holistic getting started approach

Solving the classpath issue would be a great win.  Not only could we fix 
ij this way, we could provide guidance to users so they can set up an 
executable application jar that includes derby.jar so that Derby 
application users also don't have to deal with classpath.


David

Daniel John Debrunner wrote:

Looking at Stan's WMD, sorry WWD document in DERBY-913 I want to promote
 a holistic approach to making getting started on Derby easier. Thus by
improving various areas such as documentation, web-site, product,
tutorials, FAQ etc. together we can gain a bigger benefit than by
increasing individual items to make up for deficiencies in other areas.
This echoes something Bryan (I think) said a couple of days ago, that
just don't assume fixing the getting started guide is the only or best
approach.

Stan's WWD tutorial looks like a great project and I'm sure will benefit
people getting up to speed on Derby.

What really jumped out at me was the very first things a user has to do
is understand and set classpaths. Something that causes the most
problems and is tricky to get right in a manual way, is the first thing
we hit users with. To my mind seems like a very good way to lose users
at the first step, either because they want to issue some SQL right away
but we make them setup environment variables first, or they get
frustrated by ClassNotFoundExceptions due to minor typos.

Now I understand where Stan is coming from, he's once supported this
product and saw the endless class path issues, so why not explain it up
front.

I would take a different approach, start out with something that works
and get users into executing SQL through ij as soon as possible. As the
tutorial moves on, explain class paths later, once they have seen all
the powers of Derby.

Note that what I'm talking about is maybe 2% of Stan's proposed
tutorial, but it's the first 2% where one stands the greatest risk to
lose the most people.

I see the requirement to set classpath as a weakness in the product,
which the tutorial is trying to work around. So what could be done
better in the product that would help this tutorial?

Having installed Derby there needs to be something simple that gets you
into ij. Some very easy step that gets you to a successful session like:

ij version 10.2
ij> connect 'MYDB;create=true';
ij> create table t (i int );
insert into t values 1;
0 rows inserted/updated/deleted
ij> 1 row inserted/updated/deleted
ij> select * from t;
I
---
1

1 row selected


Note that I intentionally have a connect statement without
'jdbc:derby:', I'm trying to make it simple, then as one progresses
through the tutorial one unwraps the layers to expose the full story.
E.g. some section that said, what was really going on with the 'connect
MYDB', then explain it's being mapped in jdbc:derby:MYDB and so on.

Maybe the simple command to get things going is based upon the current
ij shell or batch scripts in the frameworks directory. They could be
improved so that they were more visible and were a single step.  If I
can't run this scripts right away after an installation they will turn
people off.

Maybe we could provide additional jar files the execute the tools, I
created a simple ij.jar containing only this manifest (no classes etc.):

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.2
Created-By: 1.4.2 (IBM Corporation)
Main-Class: org.apache.derby.tools.ij
Class-Path: derbytools.jar derby.jar


Then I can execute

java -jar jars/sane/ij.jar
ij version 10.2
ij>

To set the default JDBC protocol a simple java class would be needed in
ij.jar as its main class to set the ij.protocol property and then call ij.

Can these jars be executed directly, I thought on windows one could
double-click a jar file and have it run right away, doesn't seem to
happen on my machine though?

So that's just one example where hopefully addressing something in the
product would make the tutorial better and lead to more happy Derby
users. I would encourage others to think along similar lines when
looking at the tutorial, manual or anything else that's aimed at making
Derby easier, namely to see if some other piece would make it even easier.

Dan.






begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: Holistic getting started approach

2006-02-02 Thread Sunitha Kambhampati


Daniel John Debrunner wrote:
< snip - lots of great stuff>


Can these jars be executed directly, I thought on windows one could
double-click a jar file and have it run right away, doesn't seem to
happen on my machine though?

 


I found this on http://java.sun.com/j2se/1.4.2/docs/guide/jar/jarGuide.html

"On Microsoft Windows systems, the Java 2 Runtime Environment's 
installation program will register a default association for Jar files 
so that double-clicking a Jar file on the desktop will automatically run 
it with javaw -jar. Dependent extensions bundled with the application 
will also be loaded automatically. This feature makes the end-user 
runtime environment easier to use on Microsoft Windows systems"


On Win2k, I can/tried to register the default association for the jar 
(derbynet.jar) file with javaw.exe, but not sure how to give the 
argument -jar..  anyone know ? 


Thanks,
Sunitha.

Re: Derby - sysinfo call hangs

2006-02-02 Thread Bryan Pendleton

I have noticed that sometimes when I call the "sysinfo" script the 
process hangs. 


You didn't mention what platform you are running, but you should be
able to get a Java Stack Trace showing all the threads in the sysinfo
process, and what they are waiting on:

- On Windows, use Control-Break: Hold down the Control key and press
  the Break key.

- On Unix systems, send "kill -QUIT" to the process which is running
  sysinfo, from some other window on that machine.

Then, capture the output from the Java Stack Trace, and send it along.
That will provide more information about where in the sysinfo script
it is hanging.

thanks,

bryan

Re: Returning an empty result set


Great question.  Odd answer.

Things are not coherent, as far as I can tell, between the network 
driver and the embedded driver.


== getUDTs() ==

*** network driver ***

call SYSIBM.SQLUDTS(?,?,?,?,?)

*** embedded driver ***

throw Util.notImplemented()

== getSuperTypes() ==

*** network driver ***

String sql = "SELECT CAST(NULL AS VARCHAR(128)) AS TYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS TYPE_SCHEM," +
"VARCHAR('', 128) AS TYPE_NAME," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_CAT," +
"CAST(NULL AS VARCHAR(128)) AS SUPERTYPE_SCHEM," +
"VARCHAR('', 128) AS SUPERTYPE_NAME " +
"FROM SYSIBM.SYSDUMMY1 WHERE 1=0 WITH UR ";

*** embedded driver ***

throw Util.notImplemented()



So, I'm at a bit of a loss.  Can anyone explain the history of this and 
what the "right" thing to do is.  Barring any other feedback, it would 
appear that the embedded driver is out-of-date and needs updating to do 
what the client driver does.  Another case where code sharing could be 
quite useful...


And, Lance, is it really true that every metadata call has to return a 
real result rather than throw a "Feature not implemented" exception?


David

Lance J. Andersen wrote:



David W. Van Couvering wrote:


According to our most esteemed spec lead, for the new metadata calls
that return a result set, if we don't support the metadata call, we
should return an empty result set.

Can anyone provide me some guidance as to the best way to do this?  The
constructor for org.apache.derby.client.am.ResultSet requires a lot of
parameters that I don't want to try and create, and the same is true for
the engine.

And a question to Lance: does it really make sense for getSchemas() and
getClientInfoProperties() to return an empty result set, isn't that a
bit misleading?


Hi Dave,

There is already a precedent for this type of behavior. getUDTS(), 
getSuperTypes() are an example


regards
lance
(your friendly neighborhood spec lead)


Thanks,

David

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Holistic getting started approach


Looking at Stan's WMD, sorry WWD document in DERBY-913 I want to promote
 a holistic approach to making getting started on Derby easier. Thus by
improving various areas such as documentation, web-site, product,
tutorials, FAQ etc. together we can gain a bigger benefit than by
increasing individual items to make up for deficiencies in other areas.
This echoes something Bryan (I think) said a couple of days ago, that
just don't assume fixing the getting started guide is the only or best
approach.

Stan's WWD tutorial looks like a great project and I'm sure will benefit
people getting up to speed on Derby.

What really jumped out at me was the very first things a user has to do
is understand and set classpaths. Something that causes the most
problems and is tricky to get right in a manual way, is the first thing
we hit users with. To my mind seems like a very good way to lose users
at the first step, either because they want to issue some SQL right away
but we make them setup environment variables first, or they get
frustrated by ClassNotFoundExceptions due to minor typos.

Now I understand where Stan is coming from, he's once supported this
product and saw the endless class path issues, so why not explain it up
front.

I would take a different approach, start out with something that works
and get users into executing SQL through ij as soon as possible. As the
tutorial moves on, explain class paths later, once they have seen all
the powers of Derby.

Note that what I'm talking about is maybe 2% of Stan's proposed
tutorial, but it's the first 2% where one stands the greatest risk to
lose the most people.

I see the requirement to set classpath as a weakness in the product,
which the tutorial is trying to work around. So what could be done
better in the product that would help this tutorial?

Having installed Derby there needs to be something simple that gets you
into ij. Some very easy step that gets you to a successful session like:

ij version 10.2
ij> connect 'MYDB;create=true';
ij> create table t (i int );
insert into t values 1;
0 rows inserted/updated/deleted
ij> 1 row inserted/updated/deleted
ij> select * from t;
I
---
1

1 row selected


Note that I intentionally have a connect statement without
'jdbc:derby:', I'm trying to make it simple, then as one progresses
through the tutorial one unwraps the layers to expose the full story.
E.g. some section that said, what was really going on with the 'connect
MYDB', then explain it's being mapped in jdbc:derby:MYDB and so on.

Maybe the simple command to get things going is based upon the current
ij shell or batch scripts in the frameworks directory. They could be
improved so that they were more visible and were a single step.  If I
can't run this scripts right away after an installation they will turn
people off.

Maybe we could provide additional jar files the execute the tools, I
created a simple ij.jar containing only this manifest (no classes etc.):

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.2
Created-By: 1.4.2 (IBM Corporation)
Main-Class: org.apache.derby.tools.ij
Class-Path: derbytools.jar derby.jar


Then I can execute

java -jar jars/sane/ij.jar
ij version 10.2
ij>

To set the default JDBC protocol a simple java class would be needed in
ij.jar as its main class to set the ij.protocol property and then call ij.

Can these jars be executed directly, I thought on windows one could
double-click a jar file and have it run right away, doesn't seem to
happen on my machine though?

So that's just one example where hopefully addressing something in the
product would make the tutorial better and lead to more happy Derby
users. I would encourage others to think along similar lines when
looking at the tutorial, manual or anything else that's aimed at making
Derby easier, namely to see if some other piece would make it even easier.

Dan.

[jira] Updated: (DERBY-747) Derby Logo Work

2006-02-02 Thread Jean T. Anderson (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-747?page=all ]

Jean T. Anderson updated DERBY-747:
---

Description: 
The Derby logo was voted on and a logo selected; see DERBY-297. This Jira issue 
provides a spot for uploading images for final fine tuning.

Finals are at DERBY-914.

  was:
The Derby logo was voted on and a logo selected; see DERBY-297. This Jira issue 
provides a spot for uploading images for final fine tuning.

***NOTE!*** A final based on 
http://issues.apache.org/jira/secure/attachment/12321023/derby_with_text.jpg 
but without the "Pure Java Database" tagline is being finalized.


> Derby Logo Work
> ---
>
>  Key: DERBY-747
>  URL: http://issues.apache.org/jira/browse/DERBY-747
>  Project: Derby
> Type: New Feature
>   Components: Documentation
> Reporter: Jean T. Anderson
> Priority: Minor
>  Attachments: derbylogo.ai, logo_320x200.png, logo_320x200.psd, 
> masthead_derby.png, masthead_derby2.png, masthead_derby3.png, 
> masthead_derby4.png, masthead_derby5.png, small_button_80x15_blackwhite.psd, 
> small_button_80x15_blue.psd, small_button_80x15_gold.psd, 
> small_button_80x15_orange.psd, use_of_logo.psd, web-preview-20dec05-2.png, 
> web-preview-21dec05-6.png
>
> The Derby logo was voted on and a logo selected; see DERBY-297. This Jira 
> issue provides a spot for uploading images for final fine tuning.
> Finals are at DERBY-914.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Derby - sysinfo call hangs

2006-02-02 Thread Mark Kurley

Title: Derby - sysinfo call hangs






Hi,


I have noticed that sometimes when I call the "sysinfo" script the process hangs.  There are no entries in the log files.  I even when as far as writing a shell script that calls the "sysinfo" in a loop.  It fails on different iterations each time.  

Has anyone else experienced this problem?  I am not sure how to debug this problem.  Please pass along any information. 

Thanks

-mark


 
Notice: This transmission is for the sole use of the intended recipient(s) and may contain information that is confidential and/or privileged.
If you are not the intended recipient, please delete this transmission and any attachments and notify the sender by return email immediately.
Any unauthorized review, use, disclosure or distribution is prohibited.

[jira] Closed: (DERBY-353) It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user specified value or system generated value for BY DEFAULT identity columns.

2006-02-02 Thread Satheesh Bandaram (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-353?page=all ]
 
Satheesh Bandaram closed DERBY-353:
---


Closing after resolving the bug.

> It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user 
> specified value or system generated value for BY DEFAULT identity columns.
> 
>
>  Key: DERBY-353
>  URL: http://issues.apache.org/jira/browse/DERBY-353
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.1.1.0
>  Environment: Generic
> Reporter: Satheesh Bandaram
> Assignee: V.Narayanan
>  Fix For: 10.2.0.0
>  Attachments: patch353.diff
>
> Derby was recently enhanced to support BY DEFAULT identity column. While the 
> behavior of this feature is not documented yet, I think, it is desirable for 
> IDENTITY_VAL_LOCAL() function, that is used to retrieve last single statement 
> insert value for identity column, to return user specified value for the 
> default column.
> For GENERATED ALWAYS identity columns, this issue doesn't apply, since users 
> can't provide a value. But for GENERATED BY DEFAULT identity columns, users 
> can optionally specify a value. IDENTITY_VAL_LOCAL() function should return 
> this value. Derby currently doesn't support this behavior.
> ij> create table tauto ( i int generated by default as identity, j int, k 
> int);
> 0 rows inserted/updated/deleted
> ij> insert into tauto (j,k) values (1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 1
> 1 row selected
> ij> insert into tauto (j,k) values (1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 2
> 1 row selected
> ij> insert into tauto values (5,1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 2 
> <<= This needs be '5'
> 1 row selected
> ij> select * from tauto;
> I  |J  |K
> ---
> 1  |1  |1
> 2  |1  |1
> 5  |1  |1
> 3 rows selected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (DERBY-353) It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user specified value or system generated value for BY DEFAULT identity columns.

2006-02-02 Thread Satheesh Bandaram (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-353?page=all ]
 
Satheesh Bandaram resolved DERBY-353:
-

Fix Version: 10.2.0.0
 Resolution: Fixed

Fix part of 10.2.

> It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user 
> specified value or system generated value for BY DEFAULT identity columns.
> 
>
>  Key: DERBY-353
>  URL: http://issues.apache.org/jira/browse/DERBY-353
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.1.1.0
>  Environment: Generic
> Reporter: Satheesh Bandaram
> Assignee: V.Narayanan
>  Fix For: 10.2.0.0
>  Attachments: patch353.diff
>
> Derby was recently enhanced to support BY DEFAULT identity column. While the 
> behavior of this feature is not documented yet, I think, it is desirable for 
> IDENTITY_VAL_LOCAL() function, that is used to retrieve last single statement 
> insert value for identity column, to return user specified value for the 
> default column.
> For GENERATED ALWAYS identity columns, this issue doesn't apply, since users 
> can't provide a value. But for GENERATED BY DEFAULT identity columns, users 
> can optionally specify a value. IDENTITY_VAL_LOCAL() function should return 
> this value. Derby currently doesn't support this behavior.
> ij> create table tauto ( i int generated by default as identity, j int, k 
> int);
> 0 rows inserted/updated/deleted
> ij> insert into tauto (j,k) values (1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 1
> 1 row selected
> ij> insert into tauto (j,k) values (1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 2
> 1 row selected
> ij> insert into tauto values (5,1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 2 
> <<= This needs be '5'
> 1 row selected
> ij> select * from tauto;
> I  |J  |K
> ---
> 1  |1  |1
> 2  |1  |1
> 5  |1  |1
> 3 rows selected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Reopened: (DERBY-353) It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user specified value or system generated value for BY DEFAULT identity columns.

2006-02-02 Thread Satheesh Bandaram (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-353?page=all ]
 
Satheesh Bandaram reopened DERBY-353:
-


Reopening to mark fix version.

> It is desirable to have IDENTITY_VAL_LOCAL() function return last recent user 
> specified value or system generated value for BY DEFAULT identity columns.
> 
>
>  Key: DERBY-353
>  URL: http://issues.apache.org/jira/browse/DERBY-353
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.1.1.0
>  Environment: Generic
> Reporter: Satheesh Bandaram
> Assignee: V.Narayanan
>  Attachments: patch353.diff
>
> Derby was recently enhanced to support BY DEFAULT identity column. While the 
> behavior of this feature is not documented yet, I think, it is desirable for 
> IDENTITY_VAL_LOCAL() function, that is used to retrieve last single statement 
> insert value for identity column, to return user specified value for the 
> default column.
> For GENERATED ALWAYS identity columns, this issue doesn't apply, since users 
> can't provide a value. But for GENERATED BY DEFAULT identity columns, users 
> can optionally specify a value. IDENTITY_VAL_LOCAL() function should return 
> this value. Derby currently doesn't support this behavior.
> ij> create table tauto ( i int generated by default as identity, j int, k 
> int);
> 0 rows inserted/updated/deleted
> ij> insert into tauto (j,k) values (1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 1
> 1 row selected
> ij> insert into tauto (j,k) values (1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 2
> 1 row selected
> ij> insert into tauto values (5,1,1);
> 1 row inserted/updated/deleted
> ij> values identity_val_local();
> 1
> ---
> 2 
> <<= This needs be '5'
> 1 row selected
> ij> select * from tauto;
> I  |J  |K
> ---
> 1  |1  |1
> 2  |1  |1
> 5  |1  |1
> 3 rows selected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Discussion of how to map the recovery time into Xmb of log --Checkpoint issue

2006-02-02 Thread Kristian Waagan





Mike Matrigali wrote:

  Long answer above, some comments inline below.

I think runtime performance would be optimal in this case, runtime
performance is in no way "helped" by having checkpoints - only either
not affected or hindered.  As has been noted checkpoints can cause
drastic downward spikes in some disk bound applications, hopefully we
will some changes into 10.2 to smooth those spikes down.  But the
reality is the more checkpoints on a system that is disk i/o bound the
more the app is going to slow down, if you are not disk i/o bound then
the checkpoints may have little affect.
  


Thank you for the explanations Mike. I run a TPC-B like load against
Derby and plotted some performance metrics for two different
configurations; one where the default checkpointing interval was used,
and one where it was set to maximum. I ran for 1 hour, and for the
second case, I don't think a checkpoint was started (the test took a
long time to exit when the database was shut down, as almost 100 MB of
log had to be handled). Please have a look at the attached figures, and
see if they are as you expected. 

What bothers me in particular, are the spikes for the run with default
checkpointing interval. As you can see, the throughput drops to
(nearly) zero for 10 second periods, which is pretty bad. The
checkpoint should not interfere with user activity in such a way. I
have talked to some people about this, and we suspect there might be
some kind of OS/filesystem issue that we're running into. This might be
caused by the way the checkpoint writes pages to disk - write all dirty
pages to disk, then sync at the very end. Depending on the underlying
OS/filesystem/caches, the effects may vary. My runs were done on
Solaris with the UFS filesystem. I also attatched a second graph where
I used directio (option 'forcedirectio' when mounting).
 
Unfortunately I do not have logs for disk io activity for these runs.
The data and logs were stored on different physical disks (used
'logDevice'). The database was approx 17 GB, the page cache 0.5 GB.
Embedded Derby, 16 clients/connections.

Any comments on the graphs attached?



--
Kristian

  
There are only 2 reasons for checkpoints:
1) decrease recovery time after a system crash.
2) make it possible to delete log file information (if you don't have
   rollforward recovery backups).  Without a checkpoint derby must
   keep all log files, thus space needed in the log directory will
   always grow.

The background writer thread should handle this, it should not consider
this an extreme case.  If there were no background writer and no
checkpoints then the following would happen:

1) the page cache grows to whatever maximum size it has gotten to
2) requests for a new page then use clock to determine what page to
   throw out.
3) if the page picked to throw out is dirty, then it is first written
  to the OS with no sync requested.  It is up to the OS whether this
  is handled async or not.  Most modern OS's will make this be an
  async operation unless the OS cache is full and then it will turn
  into a wait for some i/o (maybe some other i/o to free OS resource).
  The downside is that a user select at this point may end up waiting
  on a synchronous write of some page.
4) if the page to throw out is not dirty, then it can just be thrown
   out without any possible I/O wait.
5) In both cases 3 and 4 the user thread of course has to wait on the
   I/O to read the page into the cache.  Depending on the OS cache this
   may or may not be a "real" I/O.

The job of the background writer is to make case 3 less likely, that's
it.  Note if you try to keep the whole cache clean then you may flood
the I/O system unnecessarily if the app tends to write the same page
over and over again, then it is better to leave it dirty in cache until
needed.  The clock tends to do this by throwing out less used pages
vs. more used pages.

Kristian Waagan wrote:

  
  
Hi Mike,

A question totally on the side of this discussion: Do you, or anyone
else, have any opinion about how the "runtime performance" of Derby
would be affected by not having checkpoints at all, say for a large
database (around 20 GB) and 0.5 GB of page cache in a disk-bound
application load?

Is the Derby background-writer (and Clock.java) written/designed to
handle such "extreme cases" without major performance degradation?
Any information on the goal/function of the background-writer?
What mechanisms would kick in when the page-cache is full and Derby
needs slots for new pages?

  
  mechansism described above, it it particular to whether page to throw
out is dirty vs. clean.  There isn't really dependency on full.  In
a busy "normal" system the cache is always full and I don't think we
do anything special about weights of dirty vs. clean.  more work could
be done in this area as has been discussed.
  
  
I do know this is not a smart way to handle things, I'm just curious
what people think about this! And I am not seeking

Re: Returning an empty result set




David W. Van Couvering wrote:


According to our most esteemed spec lead, for the new metadata calls
that return a result set, if we don't support the metadata call, we
should return an empty result set.

Can anyone provide me some guidance as to the best way to do this?  The
constructor for org.apache.derby.client.am.ResultSet requires a lot of
parameters that I don't want to try and create, and the same is true for
the engine.

And a question to Lance: does it really make sense for getSchemas() and
getClientInfoProperties() to return an empty result set, isn't that a
bit misleading?


Hi Dave,

There is already a precedent for this type of behavior. getUDTS(), 
getSuperTypes() are an example


regards
lance
(your friendly neighborhood spec lead)


Thanks,

David

Re: [jira] Commented: (DERBY-304) If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!

2006-02-02 Thread Rajesh Kartha


Suresh Thalamati wrote:




I tried getCanonicalFile() on Windows xp , it does not resolve 
symbolic/hard links.



I feared that must be the case for Windows


Does the comparision u mentioned works on Linux if there are hard links ?



The comparision does not work on hard links but sure works for soft 
links. Eitherway hard links are not for directories.

[
$ ln adir temp
ln: `adir': hard link not allowed for directory
]

Regards
-Rajesh

[jira] Commented: (DERBY-914) Final logos

[ 
http://issues.apache.org/jira/browse/DERBY-914?page=comments#action_12364995 ] 

Roger Dudler commented on DERBY-914:


You will find a better overview of the graphics in the derby wiki:

http://wiki.apache.org/db-derby/DerbyGraphicsAndLogo

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo.psd, final_logo128.png, final_logo32.png, 
> final_logo64.png, final_logowithtext.ai, final_logowithtext.eps, 
> final_logowithtext.png, final_logowithtext.psd, final_logowithtext.svg, 
> final_logowithtext120.png, final_logowithtext220.png, 
> final_logowithtextdark.png, final_logowithtextdark.psd
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-914) Final logos

 [ http://issues.apache.org/jira/browse/DERBY-914?page=all ]

Roger Dudler updated DERBY-914:
---

Attachment: final_logowithtextdark.psd

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo.psd, final_logo128.png, final_logo32.png, 
> final_logo64.png, final_logowithtext.ai, final_logowithtext.eps, 
> final_logowithtext.png, final_logowithtext.psd, final_logowithtext.svg, 
> final_logowithtext120.png, final_logowithtext220.png, 
> final_logowithtextdark.png, final_logowithtextdark.psd
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-914) Final logos

 [ http://issues.apache.org/jira/browse/DERBY-914?page=all ]

Roger Dudler updated DERBY-914:
---

Attachment: final_logowithtext.ai
final_logowithtext.eps
final_logowithtext.png

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo.psd, final_logo128.png, final_logo32.png, 
> final_logo64.png, final_logowithtext.ai, final_logowithtext.eps, 
> final_logowithtext.png, final_logowithtext.psd, final_logowithtext.svg, 
> final_logowithtext120.png, final_logowithtext220.png, 
> final_logowithtextdark.png, final_logowithtextdark.psd
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-914) Final logos

 [ http://issues.apache.org/jira/browse/DERBY-914?page=all ]

Roger Dudler updated DERBY-914:
---

Attachment: final_logowithtext.psd
final_logowithtext.svg
final_logowithtextdark.png

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo.psd, final_logo128.png, final_logo32.png, 
> final_logo64.png, final_logowithtext.ai, final_logowithtext.eps, 
> final_logowithtext.png, final_logowithtext.psd, final_logowithtext.svg, 
> final_logowithtext120.png, final_logowithtext220.png, 
> final_logowithtextdark.png, final_logowithtextdark.psd
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-914) Final logos

 [ http://issues.apache.org/jira/browse/DERBY-914?page=all ]

Roger Dudler updated DERBY-914:
---

Attachment: final_logo.psd
final_logowithtext120.png
final_logowithtext220.png

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo.psd, final_logo128.png, final_logo32.png, 
> final_logo64.png, final_logowithtext.ai, final_logowithtext.eps, 
> final_logowithtext.png, final_logowithtext.psd, final_logowithtext.svg, 
> final_logowithtext120.png, final_logowithtext220.png, 
> final_logowithtextdark.png, final_logowithtextdark.psd
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-914) Final logos

 [ http://issues.apache.org/jira/browse/DERBY-914?page=all ]

Roger Dudler updated DERBY-914:
---

Attachment: final_logo64.png
final_logo128.png
final_logo.png

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo128.png, final_logo32.png, final_logo64.png
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-914) Final logos

 [ http://issues.apache.org/jira/browse/DERBY-914?page=all ]

Roger Dudler updated DERBY-914:
---

Attachment: final_derbylogo.pdf
final_derbylogo.svg
final_logo32.png

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo128.png, final_logo32.png, final_logo64.png
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-914) Final logos

 [ http://issues.apache.org/jira/browse/DERBY-914?page=all ]

Roger Dudler updated DERBY-914:
---

Attachment: final_80x15button_orange.png
final_derbylogo.ai
final_derbylogo.eps

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo128.png, final_logo32.png, final_logo64.png
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-914) Final logos

 [ http://issues.apache.org/jira/browse/DERBY-914?page=all ]

Roger Dudler updated DERBY-914:
---

Attachment: final_80x15button_blue.png
final_80x15button_gold.png
final_80x15button_gray.png

> Final logos
> ---
>
>  Key: DERBY-914
>  URL: http://issues.apache.org/jira/browse/DERBY-914
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Reporter: Jean T. Anderson
>  Attachments: final_80x15button_blue.png, final_80x15button_gold.png, 
> final_80x15button_gray.png, final_80x15button_orange.png, final_derbylogo.ai, 
> final_derbylogo.eps, final_derbylogo.pdf, final_derbylogo.svg, 
> final_logo.png, final_logo128.png, final_logo32.png, final_logo64.png
>
> We're leaving the initial mockups/discussions in place in DERBY-747 in case 
> that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-914) Final logos

2006-02-02 Thread Jean T. Anderson (JIRA)

Final logos
---

 Key: DERBY-914
 URL: http://issues.apache.org/jira/browse/DERBY-914
 Project: Derby
Type: Sub-task
  Components: Documentation  
Reporter: Jean T. Anderson


We're leaving the initial mockups/discussions in place in DERBY-747 in case 
that history needs to be retained.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (DERBY-492) Server hangs when trying to return high number (hundreds) of columns from a Java procedure to the client.

2006-02-02 Thread Bryan Pendleton (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-492?page=all ]
 
Bryan Pendleton resolved DERBY-492:
---

Resolution: Duplicate

The symptoms are different, but the underlying bug is the same as DERBY-491.

> Server hangs when trying to return high number (hundreds) of columns from a 
> Java procedure to the client.
> -
>
>  Key: DERBY-492
>  URL: http://issues.apache.org/jira/browse/DERBY-492
>  Project: Derby
> Type: Sub-task
>   Components: Network Server
> Versions: 10.1.1.0, 10.2.0.0, 10.0.2.2
>  Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
>  Attachments: storedProcs.java, stored_proc_repro.java
>
> Server hangs in communication with client when it (the server) tries to send 
> a DSS continuation header to accommodate a high number (hundreds) of return 
> columns from a Java procedure. Problem appears to be in the way the server 
> creates the DSS continuation header. Repro can be found in the 
> "stored_proc_repro.java" file, which uses the stored procedure "LOTS_O_COLS" 
> declared in "storedProcs.java". Both files are attached to this bug.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-913) [WWD] Proposal to create and add Working With Derby, an activity-based tutorial document, to the Derby documentation set

2006-02-02 Thread Stan Bradbury (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-913?page=all ]

Stan Bradbury updated DERBY-913:


Attachment: WorkingWithDerbyV10.html

The initial proposal describing Working With Derby

> [WWD] Proposal to create and add Working With Derby, an activity-based 
> tutorial document, to the Derby documentation set
> 
>
>  Key: DERBY-913
>  URL: http://issues.apache.org/jira/browse/DERBY-913
>  Project: Derby
> Type: Improvement
>   Components: Documentation
> Versions: 10.2.0.0
> Reporter: Stan Bradbury
> Assignee: Stan Bradbury
>  Attachments: WorkingWithDerbyV10.html
>
> I propose starting a new activity-based tutorial document for Derby.  The 
> proposed name is "Working With Derby" and I'd like to include it with the 
> next release.  The document would target new Derby users.  Information would 
> be presented that supports a series of activities designed to be performed 
> after installation.  These activities will guide beginners through the basics 
> of using Derby.  Attached is a proposal that further describes the initial 
> topics as I see them.  I would very much like feedback on all aspects of this 
> proposal from the Derby communities.  Please post all feedback to the 
> derby-user maillist, include Working With Derby (WWD for short) in the 
> subject line of all messages on this topic.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-913) [WWD] Proposal to create and add Working With Derby, an activity-based tutorial document, to the Derby documentation set

2006-02-02 Thread Stan Bradbury (JIRA)

[WWD] Proposal to create and add Working With Derby, an activity-based tutorial 
document, to the Derby documentation set


 Key: DERBY-913
 URL: http://issues.apache.org/jira/browse/DERBY-913
 Project: Derby
Type: Improvement
  Components: Documentation  
Versions: 10.2.0.0
Reporter: Stan Bradbury
 Assigned to: Stan Bradbury 


I propose starting a new activity-based tutorial document for Derby.  The 
proposed name is "Working With Derby" and I'd like to include it with the next 
release.  The document would target new Derby users.  Information would be 
presented that supports a series of activities designed to be performed after 
installation.  These activities will guide beginners through the basics of 
using Derby.  Attached is a proposal that further describes the initial topics 
as I see them.  I would very much like feedback on all aspects of this proposal 
from the Derby communities.  Please post all feedback to the derby-user 
maillist, include Working With Derby (WWD for short) in the subject line of all 
messages on this topic.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (DERBY-475) Add a system function mechanism and table of functions, including a set of initial functions.

 [ http://issues.apache.org/jira/browse/DERBY-475?page=all ]
 
Daniel John Debrunner resolved DERBY-475:
-

Resolution: Fixed

Complete set of functions added is:

ACOS, ASIN, ATAN, COS, SIN, TAN, PI
DEGREES, RADIANS, EXP, LN, LOG, LOG10, CEIL, CEILING, FLOOR

> Add a system function mechanism and table of  functions, including a set of 
> initial functions.
> --
>
>  Key: DERBY-475
>  URL: http://issues.apache.org/jira/browse/DERBY-475
>  Project: Derby
> Type: Improvement
>   Components: SQL
> Reporter: Daniel John Debrunner
> Assignee: Daniel John Debrunner
>  Fix For: 10.2.0.0

>
> Add a mechanism for system functions to be easily added. Resolution of 
> functions will check SYSFUN. for a function call in SQL when the 
> function is not qualified by a schema. If the current schema does not have a 
> function matching the name, then an additional resolution is made using 
> SYSFUN..
> Add a table driven mechanism for simple single argument functions (could be 
> expanded in the future).
> Add these functions
> /*
> ** SYSFUN functions
> *[0] = FUNCTION name
> *[1] = RETURNS type
> *[2] = Java class
> *[3] = method name
> *[4] = parameter type (single parameter)
> *
> */
> private static final String[][] SYSFUN_FUNCTIONS = {
> {"ACOS", "DOUBLE", "java.lang.Math", "acos", "DOUBLE"},
> {"ASIN", "DOUBLE", "java.lang.Math", "asin", "DOUBLE"},
> {"ATAN", "DOUBLE", "java.lang.Math", "atan", "DOUBLE"},
> {"COS", "DOUBLE", "java.lang.Math", "cos", "DOUBLE"},
> {"SIN", "DOUBLE", "java.lang.Math", "sin", "DOUBLE"},
> {"TAN", "DOUBLE", "java.lang.Math", "tan", "DOUBLE"},
> {"DEGREES", "DOUBLE", "java.lang.Math", "toDegrees", "DOUBLE"},
> {"RADIANS", "DOUBLE", "java.lang.Math", "toRadians", "DOUBLE"},
> {"LN", "DOUBLE", "java.lang.Math", "log", "DOUBLE"},
> {"EXP", "DOUBLE", "java.lang.Math", "exp", "DOUBLE"},
> {"CEIL", "DOUBLE", "java.lang.Math", "ceil", "DOUBLE"},
> {"CEILING", "DOUBLE", "java.lang.Math", "ceil", "DOUBLE"},
> {"FLOOR", "DOUBLE", "java.lang.Math", "floor", "DOUBLE"},
> };

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (DERBY-592) Expand table driven system function defintion added in DERBY-475 to allow definition of JDBC escaped functions.

 [ http://issues.apache.org/jira/browse/DERBY-592?page=all ]
 
Daniel John Debrunner resolved DERBY-592:
-

Resolution: Fixed

SImplified the solution to have a list in the parser of escaped functions that 
map directly to builting SYSFUN functions. Decided this was the simplest 
approach with the smallest amount of code. Since the list of escape functions 
is static, coming from ODBC a very flexible scheme would have been overkill.

JDBC escape functions added are:

ACOS, ASIN, ATAN, COS, SIN, TAN, PI
DEGREES, RADIANS, EXP, LOG, LOG10, CEILING, FLOOR

> Expand table driven system function defintion added in DERBY-475 to allow 
> definition of JDBC escaped functions.
> ---
>
>  Key: DERBY-592
>  URL: http://issues.apache.org/jira/browse/DERBY-592
>  Project: Derby
> Type: Improvement
>   Components: JDBC, SQL
> Reporter: Daniel John Debrunner
> Assignee: Daniel John Debrunner
> Priority: Minor
>  Fix For: 10.2.0.0

>
> Since the functions added in DERBY-475 overlap with the numeric scaler 
> functions defined in section C.1 of JDBC 3.0 it would be benfiical to expand 
> the table to indicate if the function can be used as a JDBC escaped scaler as 
> well.
> Plus adding all the code to find them and call them etc. :-)
> I'll add a comment later to show which JDBC escape functions this would add.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: javadoc errors

That's very odd.  I didn't get these when I ran derbydocs target.  Are 
you sure you have the latest stuff, org.apache.derby.shared is a 
somewhat new package (although not that new).


David

Mike Matrigali wrote:
After the recent checkin I am still getting a few javadoc errors (WAY 
less after rick's work), I am wondering if these are particular to my 
build environment.  Rick's recent message seemed to indicate he was

getting none.  Is anyone else seeing them:
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\ClientPooledConnection.java:28: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Connection.java:24: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlWarning.java:25: 
package org.apache.derby.shared.common.info does not exist

  [javadoc] import org.apache.derby.shared.common.info.JVMInfo;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:27: 
package org.apache.derby.shared.common.info does not exist

  [javadoc] import org.apache.derby.shared.common.info.JVMInfo;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:28: 
package org.apache.derby.shared.common.i18n does not exist

  [javadoc] import org.apache.derby.shared.common.i18n.MessageUtil;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:29: 
package org.apache.derby.shared.common.error does not exist

  [javadoc] import org.apache.derby.shared.common.error.ExceptionUtil;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\LogWriter.java:26: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\CallableStatement.java:24: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Sqlca.java:23: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\ResultSet.java:25: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:95: 
cannot resolve symbol

  [javadoc] symbol  : class MessageUtil
  [javadoc] location: class org.apache.derby.client.am.SqlException
  [javadoc] private static MessageUtil msgutil_ =
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Blob.java:24: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Lob.java:23: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\LogicalConnection.java:22: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\iapi\error\ExceptionSeverity.java:30: 
package org.apache.derby.shared.common.error does not exist
  [javadoc] extends 
org.apache.derby.shared.common.error.ExceptionSeverity

  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\iapi\reference\JDBC30Translation.java:28:

[jira] Updated: (DERBY-830) lang/dcl.sql is failing

 [ http://issues.apache.org/jira/browse/DERBY-830?page=all ]

David Van Couvering updated DERBY-830:
--

Priority: Major  (was: Critical)

Downgrading to Major since this appears to only be occurring on Solaris x86 
now, instead of all platforms.

> lang/dcl.sql is failing
> ---
>
>  Key: DERBY-830
>  URL: http://issues.apache.org/jira/browse/DERBY-830
>  Project: Derby
> Type: Test
>   Components: Test
>  Environment: Microsoft(R) Windows(R) Server 2003, - 5.2.3790 Service Pack 1 
> Build 3790
> CYGWIN_NT-5.2 1.5.12(0.116/4/2) 2004-11-10 08:34 Cygwin
> Sun Microsystems Inc. 1.5 Java VM
> Reporter: David Van Couvering

>
> The first observed failure of this was revision 344536 (see 
> http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/345536.txt), 
> which has a number of changes queued up because the tests were not run for a 
> while.
> derbylang diff -
> * Diff file derbylang/derbylang/dcl.diff
> *** Start: dcl jdk1.5.0_04 derbylang:derbylang 2006-01-18 20:23:36 ***
> 274a275,276
> > ERROR XJ040: Failed to start database 'jar:(ina.jar)db7', see the next 
> > exception for details.
> > ERROR XBM0W: An exception was thrown while creating an instance of class 
> > class org.apache.derby.impl.io.JarStorageFactory registered for identifier 
> > jar.
> 278 del
> < ID |E_MAIL|OK
> 279 del
> < -
> 280 del
> < 1  |[EMAIL PROTECTED] |NULL  
> 281 del
> < 2  |[EMAIL PROTECTED]  |NULL  
> 282 del
> < 3  |[EMAIL PROTECTED]  |NULL  
> 283 del
> < 4  |[EMAIL PROTECTED]|0 
> 284 del
> < 5  |[EMAIL PROTECTED]   |1 
> 284a280
> > IJ ERROR: Unable to establish connection
> 286 del
> < E_MAIL|2 
> 287 del
> < -
> 288 del
> < [EMAIL PROTECTED] |0 
> 289 del
> < [EMAIL PROTECTED]  |0 
> 290 del
> < [EMAIL PROTECTED]  |0 
> 291 del
> < [EMAIL PROTECTED]|0 
> 292 del
> < [EMAIL PROTECTED]   |1 
> 292a282
> > IJ ERROR: Unable to establish connection
> 294 del
> < ERROR 25502: An SQL data change is not permitted for a read-only 
> connection, user or database.
> 294a284
> > IJ ERROR: Unable to establish connection
> 296 del
> < ERROR 25502: An SQL data change is not permitted for a read-only 
> connection, user or database.
> 296a286
> > IJ ERROR: Unable to establish connection
> 306 del
> < 1   
>   
>   
> 
> 307 del
> < 
> 
> 308 del
> < NULL
>   
>   
> 
> 308a296
> > IJ ERROR: Unable to establish connection
> 311 del
> < 1   
>   
>   
> 
> 312 del
> < 
> 
> 313 del
> < NULL
>   
>   
> 
> 313a299
> > IJ ERROR: Unable to establish connection
> 315a302
> > IJ ERROR: Unable to establish connection
> 317 del
> < ID |E_MAIL|OK
> 318 del
> < -
> 319 del
> < 1  |[EMAIL PROTECTED] |NULL  
> 320 del
> < 2

Re: 'Unassigned' critical issues


It appears to still be failing on JDK 1.5 on Solaris x86, see

http://www.multinet.no/~solberg/public/Apache/Derby/testlog/CYGWIN_NT-5.2_i686-unknown/374142-derbylang_diff.txt

Since it's not occurring on all platforms I will downgrade this to Major.

David


Rajesh Kartha wrote:

Thanks Mike.

I agree, if we did not get the needed info (scenario, repro etc.) for 
DERBY-749 all this time, I see no reason why it has

to be kept critical.

For DERBY-830, can David please confirm if it is still a valid issue and 
need to remain open. From the comments

the test seem to pass for Dan on XP.

-Rajesh

On 2/2/06, *Mike Matrigali* <[EMAIL PROTECTED] 
> wrote:


As to DERBY-749 I have requested multiple times more information, and
not gotten anything.  Given that it is likely to get closed with no
fix intended.

Rajesh Kartha wrote:
 > Hello,
 >
 > I was reviewing the list of open JIRA issues for Derby and
noticed there
 > are some 'Critical'
 > issues that remain 'Unassigned'.
 >
 >

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10594&priority=2&resolution=-1


 >

>
 >
 > Does anybody have any comments or plan to work on the following?
 >
 > Type  JIRA ID Summary
 >   Assigned
 > Updated
 >
 >
 > Test  DERBY-830   lang/dcl.sql is failing
 >Unassigned  20/Jan/06
 > Bug   DERBY-749   Corrupt Database after high cpu usage
 > Unassigned  14/Dec/05
 > Bug   DERBY-616   create index can fail under the SecurityManager
 > Unassigned  11/Oct/05
 >  when trying to access files in the tmp
 > folder of
 >  a database
 >
 > In addition, for the following issue there has been no updates
for some
 > time.
 > Scott, can you please share your progress, if you are actively
working
 > on this.
 >
 >
 > New   DERBY-396   Support for ALTER STATEMENT to DROP , Scott
 >   28/Dec/05
 > Feature   MODIFY, RENAME a COLUMN
 >   MacDonald
 >
 >
 > The following issues of regression failure were discussed on
derby-dev -
 > the v10.2
 > behavior seems appropriate  and the v10.1 tests needs to be fixed.
 > Having said that,
 > I don't think they need to remain 'Critical' anymore.
 >
 >
 > Bug   DERBY-881   jdbcapi/LOBTest.java fails for server (
10.1.2.2 
 > )Unassigned   31/Jan/06
 >  and client (10.2.0.0
 )
 > compatibility testing
 >
 > Bug   DERBY-880   jdbcapi/connectionJdbc20.java fails for server
 >   (10.1.2.2 
) and client
 > (10.2.0.0  )
compatibility   Unassigned31/Jan/06
 >   testing with > SQLSTATE(null):
 >   java.sql.SQLException: Stream of
column value
 >   in result cannot be retrieved twice
 >
 > Going forward, I suggest any issues (specially Bugs, Test failures)
 > marked 'Blocker' or 'Critical' needs
 > to get the immediate attention to be evaluated for assigning
(have an
 > owner) or marking (the priority)
 > accordingly. Any regression test failures would fall into this
category.
 >
 > I can volunteer to monitor and send follow-up mails, for
addressing the
 > high priority
 > Derby issues, on a regular basis.
 >
 > Regards,
 > Rajesh


begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: [Db-derby Wiki] Update of "FrontPage" by Roger Dudler


Thanks, Roger.

I'm confused, it still has the Pure Java Database tagline (not that I 
don't mind, but we recently had a vote to remove the tagline).


Are you planning to do that?

Thanks,

David

Apache Wiki wrote:

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for 
change notification.

The following page has been changed by Roger Dudler:
http://wiki.apache.org/db-derby/FrontPage

--
   * LanguageSystem: Information on the SQL compilation system
   * ForNewDevelopers: Information to get started with Derby development
  
+ == General Information on the Derby Project ==

+  * DerbyGraphicsAndLogo: Derby logo and related graphics with usage guidelines
+ 
  == Interesting starting points ==

   * RecentChanges: see where people are currently working
   * WikiSandBox: feel free to change this page and experiment with editing
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

javadoc errors

2006-02-02 Thread Mike Matrigali

After the recent checkin I am still getting a few javadoc errors (WAY 
less after rick's work), I am wondering if these are particular to my 
build environment.  Rick's recent message seemed to indicate he was

getting none.  Is anyone else seeing them:
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\ClientPooledConnection.java:28: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Connection.java:24: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlWarning.java:25: 
package org.apache.derby.shared.common.info does not exist

  [javadoc] import org.apache.derby.shared.common.info.JVMInfo;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:27: 
package org.apache.derby.shared.common.info does not exist

  [javadoc] import org.apache.derby.shared.common.info.JVMInfo;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:28: 
package org.apache.derby.shared.common.i18n does not exist

  [javadoc] import org.apache.derby.shared.common.i18n.MessageUtil;
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:29: 
package org.apache.derby.shared.common.error does not exist

  [javadoc] import org.apache.derby.shared.common.error.ExceptionUtil;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\LogWriter.java:26: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\CallableStatement.java:24: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Sqlca.java:23: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\ResultSet.java:25: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\SqlException.java:95: 
cannot resolve symbol

  [javadoc] symbol  : class MessageUtil
  [javadoc] location: class org.apache.derby.client.am.SqlException
  [javadoc] private static MessageUtil msgutil_ =
  [javadoc]^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Blob.java:24: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\Lob.java:23: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\client\am\LogicalConnection.java:22: 
package org.apache.derby.shared.common.reference does not exist

  [javadoc] import org.apache.derby.shared.common.reference.SQLState;
  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\iapi\error\ExceptionSeverity.java:30: 
package org.apache.derby.shared.common.error does not exist
  [javadoc] extends 
org.apache.derby.shared.common.error.ExceptionSeverity

  [javadoc] ^
  [javadoc] 
C:\nightlies\main\src\html\sourcedir\org\apache\derby\iapi\reference\JDBC30Translation.java:28: 
package org.apache.derby.shared.common.reference does not exist
  [javadoc] 
org.apache.derby.shared.common.reference.JDBC30Translation {

  [javadoc] ^
  [javadoc] 
C:\ni

Re: And another metadata question