But my point was to state that - irrespective of what a good value
for the client server is, the server's max query blocksize should be
10M ( which is per the spec). Does that sound reasonable to you ?
Yes, absolutely.
thanks,
bryan
The maximum value is 2097151, which comes
from java.lang.Integer.MAX_VALUE / 1024.
Army, this is a *wonderful* writeup -- thank you very much?
Is it really realistic, though, to allow a setting of 2 million,
which gives the optimizer permission to try to create a
in-memory hash table of 2
I was trying to verify that the changes in DERBY-920 hadn't
introduced any new compatibility problems (they shouldn't, because
we were changing an internal class, but I wanted to make sure).
So I was trying to follow some old tips about how to run tests with
an old client against a new server,
John H. Embretsen (JIRA) wrote:
I don't know if this is very helpful with regards to this Jira issue.
Thanks, John; this is definitely helpful.
I'm a little worried that DERBY-1326 and DERBY-51 are getting inter-twined,
though;
it seems like your comments are very applicable to DERBY-51.
I
Anyway, setting those two fields to false in DDMReader.initialize()
made the hang go away, and derbynetclientmats runs cleanly with that
change.
Wonderful! Thanks for the quick analysis, Knut Anders.
It sounds like I should open a JIRA issue for this and we should
package up your fix and get
Andrew McIntyre commented on DERBY-1431:
The -bin distribution in 10.2 currently does build with a demo/programs
directory.
With the addition of toursdb to demo/databases, I've moved the demo programs
into demo/programs. I only did so because that
Dag H. Wanvik commented on DERBY-1338:
--
I did consider including a longer comment - I agree it is better. The
comment is fine, except it should be DRDAProtocolExceptionInfo in all
cases, not plain DRDAProtocolException.
Thanks for reviewing the comment.
Stan Bradbury (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-1431?page=comments#action_12417004 ]
Stan Bradbury commented on DERBY-1431:
--
... cast my vote for organizing/grouping files in a hierarchy under the demo
folder.
Hi Stan,
Sunitha Kambhampati wrote:
they are hitting an edge case, where the writer.getDSSLength() is
equal to blksize and this DSS is the only dss in the send buffer.
Hi Sunitha,
Yes, I completely agree with your analysis. There is an off-by-one
bug in the fix for DERBY-170. Thank you very much for
I am fine either ways. If opening a new jira is easy, then we should
just do that. Since DERBY-170 is already backported to 10.1, we will
need to backport this fix to 10.1 also. If we go with opening a new
issue, it might be good to link this new issue with derby-170 using jira
links, so
Andrew McIntyre wrote:
On 6/24/06, Kathey Marsden [EMAIL PROTECTED] wrote:
The patch looks good to me and I say +1 to port to 10.1. Unlucky
users, that hit this boundary will be happy for the fix.
Yes, I'm definitely +1 for this.
Great! The svn merge was clean, and I've successfully run
http://people.apache.org/~fuzzylogic/10.1.3.1/
I successfully verified the fix for DERBY-1454 in this build.
Thanks for getting this fix in, Andrew!
I also spot-checked several of the other fixes I was interested in.
+1 for this release from me.
thanks,
bryan
in place of displaying the class origin information.
(DERBY-668) [ Bryan Pendleton ]
Kristian Waagan (JIRA) wrote:
I will add tests, but have to wait until the signatures have made it into
Mustang (I do have some tests already, but here I use the specific
implementation classes, not the interfaces).
It seems to me that it's completely appropriate for tests to use
specific
You are correct that using specific implementation classes is completely
appropriate in general. However, in this case, I would not be able to
*easily* share the test code between the embedded and the client driver
when running the JUnit test in our harness (I'm not very fond of the
master
Kristian Waagan wrote:
I think a single connection is not expected to be shared between
multiple threads simultaneously. Maybe the necessary synchronization is
done at a lower level in the system.
This is not intended to be a complete answer, and perhaps I'm
misunderstanding the thrust of
Long story short someone who works with the client pointed out that the
client is sending a QRYROWSET of size 0 when it sends the OPNQRY
Hi Army,
Page 698 of V.3 says:
A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs
the server to return no rows with the OPNQRYRM
Knut Anders Hatlen commented on DERBY-1237:
---
Does anyone object to closing this issue as a duplicate of 989?
Thanks for having a close read of the logs. Closing as a duplicate
seems reasonable to me.
bryan
Kristian Waagan commented on DERBY-1471:
The approach is to exhaust the application stream and copy it into
memory to determine the length. If the data is too big to fit in memory,
the client will fail with an out-of-memory exception.
That seems
Instead of making a copy of the interface, I let it the new interface extend
the original one.
Yes, I see; that is a good technique.
Thanks for the explanations.
bryan
I've been writing additional tests for ALTER TABLE DROP COLUMN and
have come across a few questions:
1) When I specify RESTRICT, the code searches for dependent objects
and rejects the DROP COLUMN if a dependent item is found. However,
an index is apparently not considered a dependent item. That
I'm thinking that it would make sense to break DERBY-396 down into
multiple sub-tasks. I think this would make it easier to track and
monitor incremental progress in this area over time.
I am thinking that the following list would be a reasonable set of
sub-tasks to file.
1) drop column
2)
Yes, except that the jira sub-task mechanism is not very flexible. Are
these really sub-tasks or related but independent features? I would say
the latter, which would mean 5 independent issues in Jira. They can
always be linked to DERBY-396 in Jira.
I agree; they are related but independent
The DdlUtils tool seems not be capable of migrating views, CHECK
constraints, and stored procedures. I would like to know what do you
think if DdlUtils tool can be reused for migrating the tables and
Indexes, and use the DatabaseMetadata for migrating views and stored
procedures? .
Perhaps
Is there some easy Java regular expression matching function like
String.matches(Collator collator, String pattern, String value)?
Here's an article from 1999 in which some person apparently decided
that they needed to write such a thing themselves.
Warning: the code described in this
I posted two patches for some optimizer changes a little over a week
ago: one for DERBY-781 and one for DERBY-1357.
Hi Army,
I have been reading your wonderful DERBY-781 document. I will give you
whatever feedback I have by the end of this weekend, although I don't
expect to have many
Kathey Marsden commented on DERBY-1466:
---
If nothing goes wrong this is just the startup and the shutdown message.
I agree with your overall point, and agree that the console should flush.
I just wanted to point out that I think the above is true only
David Van Couvering wrote:
... We should not
allow any other requests to be sent to the server over this connection
until the BLOB data is processed or cancelled
I'm not quite sure how we would do this. What is preventing the client from,
say, calling ResultSet.next(), or going off to some
David Van Couvering wrote:
I guess what I was assuming was, if the application goes off and does
something else, we can notice that and either raise an exception
(you're not done with that BLOB column yet) or flush the rest of the
BLOB data, since it's obvious they won't be getting back to it
Hi Mamta, thank you for investigating this.
DROP COLUMN will also need to see if there are any privileges granted on
it and if yes, then those privileges should be revoked.
That makes sense to me, too.
I am proposing to have the ALTER TABLE DROP COLUMN statement call the
already-existing
SYNTAX: grant codeBase file:d:/derby/lib/-
SYNTAX:grant codeBase file://f:/derby/lib/derby.jar
Ah, the bizarre and sad world of file scheme URLs. Dress in warm
clothes and take lots of water if you want to pursue the path of
knowledge in this area :)
All kidding aside, file scheme
So adding a test case with
timeout disabled won't show the symptom, and adding it with timeout
enabled will likely lead to intermittent failures on different machines.
I agree. Unreliable tests can be worse than no tests at all. I'm comfortable
with this decision.
release note would have to
Hi Kathey,
I am working on an issue where the following exception occured after a
long 16hr stress run.
Another possibility is that this could be DERBY-428, which has a very
similar signature.
I suppose it
could be offset for bytes, but the ensurelength(4) seems like it should
take
I'm interested in getting some feedback about whether some of my patch
proposals for enhanced ALTER TABLE support are close enough to ready to
be worth considering for 10.2.
Specifically, I'm interested in gauging whether there are any reviewers
who have enough spare cycles to be able to have a
Kathey Marsden resolved DERBY-428.
--
I think the hang may have been related to some interaction with my
firewall software. I will post separately to derby-dev about that
as I think there may be a Network Server issue there.
Hi Kathey,
Did you get a
I posted possible release notes to DERBY-1357 and DERBY-781.
Hi Army,
I just wanted to note that I read both the release notes, and the
wiki page too, and I think they are quite clear and will be useful
to customers when they upgrade. Thanks for putting them together!
bryan
Yip Ng wrote:
Got my attention. I am almost done with my other jira issues so I can
help review Army's XML patches. =)
Thanks, Yip!
I, too, am hoping to spend some time over the next few days reviewing
Army's patches. Learning about this work has been on my list for a while,
so I'm glad to
Hi Army,
I believe I've successfully applied the XML patches in
DERBY-688 and built them using the normal build techniques
that I use for Derby.
When I try to run, I see the exception below.
Does this indicate that I missed out a step in building somewhere?
Can you identify what failed to
I want to thank all the reviewers who examined the proposed
patches to DERBY-119, DERBY-1489, and DERBY-1490. They made
a number of excellent comments which I need to research and
address.
I'm not going to have time to get these changes done in the
next day or two, however, so I suggest that we
with a newer version (I'm using 2.6), the problem goes away.
Does this solve the problem for you?
Hi Army,
Yes, switching to Xalan 2.7 and installing it as an endorsed standard
in my JRE does indeed make the problem go away, and xml_general.sql
now passes for me.
Thanks for the quick
Hi Army, thanks for posting the patches and for continuing the work
on the XML support. I think this is going to be a great feature!
Here's my feedback; hope it's useful.
thanks,
bryan
1) The patches read well. The comments are fantastic! The effort is greatly
appreciated.
2) The patches
Otherwise, if any of my answers above would make you uncomfortable with
committing the patches (or with approving their commit), please let me
know and I will try to address your concerns.
Hi Army,
I am comfortable with your responses, and in my opinion the 5 patches
are ready for commit.
Is
Yip Ng wrote:
I think these patches are ready for commit. +1
Thanks Yip!
I will proceed with committing the patches starting today.
thanks,
bryan
after a year of development
Although it's no help for the current situation, I think that one of
the issues here is that our release cycle for this release is too long,
and we've strayed from the Release Early, Release Often advice
In my environment, it seems that the now-committted patch for
DERBY-1649 indeed removes the Wisconsin test diff.
I think that the issue can be resolved and closed and removed
from the patch-available list now, yes?
thanks,
bryan
This is a vote to define the coding conventions for the Derby project
My vote is:
[+1] Adopt the coding convention described.
thanks,
bryan
I think that the patches attached to this issue have been
committed, and there aren't any patches awaiting review.
In my opinion, there's no rush to remove the existing
frameworks scripts, but it would be nice to see the new
scripts appear in the distributions relatively soon so
that people
Hi,
I think we're getting close to the point where DERBY-119 is ready for
commit. It's been tested and reviewed by several people (thanks!) and
seems to be behaving well. Here's the link for convenience:
http://issues.apache.org/jira/browse/DERBY-119
However, since this is a new feature,
that you could hold off committing this work until at least Monday?
Not a problem; glad I checked.
I will check again early next week to see where we are.
thanks,
bryan
jdbcapi/blobclob4BLOB.java fails under DerbyNet framework with JCC 2.6
Is there a download site where one can get access to the 2.6 JCC driver?
I think I asked this last spring and at the time there wasn't
one available. It would be nice to be able to run JCC 2.6 tests
myself occasionally.
Mike Matrigali wrote:
any idea how we do that?
Daniel John Debrunner wrote:
Could all the Derby committers please ensure their name is on the DB
project page.
http://db.apache.org/whoweare.html
I asked about this over on general@db.apache.org, and
Henning Schmiedehausen pointed me at
Hi Jean, thanks for the pointers. This looks pretty straightforward.
I'll try to get myself added to the site.
I'm having a bit of trouble following your notes where you say:
(2) I set up the ssh key and started the agent per
http://www.cs.utk.edu/~england/ssh.html .
In the context of
1. Dropping the column seems very slow for large tables.
This is good to know. I don't think anybody has really experimented with
this yet. Can you quantify very slow with some real measurements
you've taken? Do you think it would be reasonable to treat this as
a follow-on improvement to the
A B (JIRA) wrote:
So this patch, d688_phase6_v1.patch, is ready for commit.
Thanks Army!
I intend to review and commit this change. If anyone else is
reviewing it, please let me know.
thanks,
bryan
Does the phase6 patch need to be applied to the 10.2 branch?
Yes, that'd be great. Thanks for bringing this up--I'd forgotten about the
need for this...
I intend to merge the phase6 patch for DERBY-688 to the 10.2
branch in the next day or so. Rick (or anyone else), please let
me know if
I think that the section titled branches on the web page
http://db.apache.org/derby/derby_downloads.html
needs to be updated, to reflect that there is now a 10.2 branch.
I think it's as simple as adding:
* 10.2
to the bullet list.
thanks,
bryan
I'm concerned about the effect that I saw from setting
derby.database.sqlAuthorization=true in my environment.
I tried making a one line change to the properties used by the
altertable.sql test (see inline diff below), and then running
java
I propose to commit DERBY-119 to the trunk within the next week.
http://issues.apache.org/jira/browse/DERBY-119
This is a new feature, and should not be merged to 10.2, but my
understanding is that all the mass-merging from the trunk to 10.2
is complete and it is ok to start putting new work
Oystein Grovlen - Sun Norway wrote:
Oh, I did not notice this. I tried to run batchUpdate with
DerbyNetClient, but this still fails. I guess that means that beetle
5561 is still an issue
Perhaps this is worthy of a JIRA issue of its own, something along the
lines of:
- if you run
In my 10.2 branch run of derbyall yesterday, the only test
failure I had was blobclob4BLOB:
Summary results:
Test Run Started: 2006-08-24 16:08:21.0
Test Run Duration: 02:36:11
667 Tests Run
99% Pass (666 tests passed)
1% Fail (1 tests failed)
4 Suites skipped
thanks,
bryan
I would like to close the bug, but I'm afraid I don;t have the
privileges, so maybe you could do it yourself?
Hi Wiktor, thanks for testing the fix!
If you send a message to the derby-dev@db.apache.org mailing list,
asking for developer access to JIRA, somebody will grant you the
appropriate
Mike Matrigali wrote:
Bryan do you think it is a problem checking in your patch for 1583 prior
to doing the 1724 research? Are you planning to commit, or are you
looking for someone else to commit the patch?
Hi Mike, thanks for the feedback.
I don't think it would be a problem to commit the
Mike Matrigali wrote:
I committed your latest patch to the trunk.
Thanks Mike!
bryan
r437215 | bpendleton | 2006-08-26 12:42:02 -0700 (Sat, 26 Aug 2006) | 18 lines
DERBY-119: Add ALTER TABLE option to change column from NULL to NOT NULL
Why was this omitted?
Probably because I suggested it should not be merged. I think this reflects my
inexperience with the open source
I also believe there is a JSR that is looking at I/O improvement to
future java releases. We should get someone from Derby involved in
that.
This looks like it could be the JSR you're thinking of:
http://jcp.org/en/jsr/detail?id=203
JSR 203 was planned to be part of JDK 1.6 but has moved to
Hi All,
On the Resources page of the web site,
http://db.apache.org/derby/integrate/index.html,
in the Papers section, in the Derby Engine subsection, there is a link
entitled
Type System.
The Type System link is a link to:
In the open source world however, by releasing the code and allowing
others to use it, the more eyes syndrome means that the testing by
chance becomes the significant factor, thus the quality increases by
releasing it.
I completely agree. Release early, release often, get real feedback from
Hi, I'm trying to learn how to build Derby myself, as a
precursor to being able to work on bugs that concern me.
As a first step, I downloaded db-derby-10.1.1.0-bin.zip
and db-derby-10.1.1.0.src.zip from the Derby download site,
and then I opened up the source distribution on my Red Hat
Linux
DERBY-569 is my current itch, so I am exploring scratching it.
Following the suggestion made by Oystein Grovlen in the comments
at http://issues.apache.org/jira/browse/DERBY-569, I have been
experimenting with letting derby.drda.logConnections also turn
off logging of connections to the console.
For the 2904165 build - did you compile the classes with both
debug=false, and sane=false in your ant.properties ?
I suspect the 2904165 size is probably because the classes were built with
debug=true
Sunitha.
Yes, you are exactly right. Re-building with debug=false in
my ant.properties
Thanks for raising and addressing this issue. In specifying the JUnit
version, I was mimicking the way that BUILDING.txt treats Ant. I like
Dan's suggestion and I'll amend the scripts accordingly. I'll also amend
BUILDING.txt to say that the build succeeds with JUnit 3.8.1 but that
you can
In the Administrivia section of the digest forms
of each of the mailing lists (derby-user-digest and
derby-dev-digest), there are some bad mailto: links.
For example, here's a snip from the most recent issue
of the derby-dev-digest:
--
Administrivia:
To subscribe to the digest,
Hi all,
I've been trying to set up my build environment to learn how
to build Derby and run tests. I'm working with yesterday's
trunk, on a RedHat Linux machine.
My build appears to complete successfully, and I get a l-o-o-n-g
way through derbyall, but then I get the error below.
Am I missing
java.io.IOException: CreateProcess: \marsden\bin\md5.ksh
D:\svn\opensource\10.1/tools/release/db-derby-10.1.2.0-bin.zip error=193
I think this is Ant's (and Windows's) way of trying to tell you
that md5.ksh is not an executable file.
The exec task in Ant can only directly run things that are
Hi,
On Friday, I uploaded some sample data, a DDL script, and
a JDBC program to reproduce bug Derby-614.
Can somebody please give my script a try, and confirm whether
you can or cannot reproduce the bug using this data?
thanks,
bryan
All the ksh scripts are have CRLF line terminators and therefore don't
work under unix.
Is this a regression from 10.1.1.0 (previous 10.1 official release)?
I don't think so. I noticed this same problem in 10.1.1.0 when I fetched
it last month.
bryan
I thought it was generally accepted that the .tar.gz files were
intended for Unix-related platforms, and zips were intended for use
with Windows. No?
No, that subtlety escaped me. When I went to
http://db.apache.org/derby/releases/release-10.1.1.0.cgi I didn't see
anything obvious telling me
the current Derby semantics (releasing
the update lock once a next() is executed), isn't very helpful.
Even in read-committed isolation level, it still seems like it
might be useful to be able to control the lock-mode on the current
row. If I have an read-committed transaction which reads
windows allows one to partition in software, I think included in the
base OS. Can someone say if linux does or not (or at least a particular
version of linux).
Well, Linux has an extremely powerful component called the Logical
Volume Manager, which sounds like what you mean:
Hi all,
I'm still struggling, trying to get a configuration of
my system such that I can run 'derbyall' successfully.
Three questions:
1) java/testing/README.htm does not say anything about
creating a database; it just says to cd into a directory
that does not have any colons or spaces in it.
Thanks for the quick help, everybody!
I am working with trunk as of a few weeks ago. I am building
all the code from scratch, including building derbyTesting.jar.
The builds were completely uneventful. I am running with the
insane jars built by ant buildjars.
Running store/access.sql was fine.
Myrna van Lunteren wrote:
I think your problem is indeed with db2jcc. Your sysinfo reports it's
version 1.0:
[/home/bpendleton/downloads/derby/db2jcc/lib/db2jcc.jar] 1.0 - (581)
I think we only support 2.4 and up with derby 10 and up. Try to download
a later version if you need jcc.
Ah,
Well, I'm confused too - it's too weird.
OMG! I am very embarrassed.
It turns out that one of the other tools I have on my
machine had copied an old version of db2jcc.jar into
my $JAVA_HOME/jre/lib/ext.
Removing that file solved the problem.
My apologies, and thanks to Myrna for
I've now got my development environment set up properly,
I think, and I've run 'derbyall' multiple times.
I'm trying to interpret my results, to see if I have a
successful run. I appear to have skipped some number
of tests, and I appear to have two failing tests.
Can somebody who's more
The file trunk/README currently contains the following text:
Derby is an effort undergoing incubation at the Apache Software Foundation
(ASF), sponsored by the Apache DB project. Incubation is required of all
newly accepted projects until a further review indicates that the
Kathey Marsden wrote:
The patch for DERBY-569 changes the derby.drda.logConnections
property to also turn off logging of connections to console.
Hi Kathey,
Thanks for reviewing my changes.
I mailed the ICLA this morning. Hopefully Apache will receive it soon.
thanks,
bryan
Although not included in this initial contribution, we will need to
provide mechanisms to help track down and resolve mixed version issues.
Possible mechanisms include:
- upgrade sysinfo to use the current classloader rather than the
classpath to determine version information
...
I just
As part of preparing to work on DERBY-666 I've been setting myself
up to be able to build and test Derby using JDK 1.5.
I may be going about this all wrong, but here's what I did:
- I've installed the Sun 1.5.0_05 JDK on my RedHat Linux system.
- I set JAVA_HOME to point to my 1.5 JDK
- I set
As part of preparing to work on DERBY-666 I've been setting myself
up to be able to build and test Derby using JDK 1.5.
You need to use JDK 1.4 to build Derby.
I think I didn't make my question very clear.
I already have a JDK 1.4 build environment set up for Derby,
and I am able to build it
Narayanan's icla now shows up as being recorded
Yay! So does mine!
http://people.apache.org/~jim/committers.html#unlistedclas
bryan
I have attached a thin functional specification describing expected SQL and
JDBC behavior for the re-enabled BOOLEAN datatype.
Are there any changes to the way that ResultSet.getBoolean()
and PreparedStatement.setBoolean() work for data types *other*
than the boolean data type?
thanks,
bryan
Hi all,
I was wondering if anybody had had a chance to take a look
at the changes I proposed to fix DERBY-668.
http://issues.apache.org/jira/browse/DERBY-668
Is my patch valuable? Worth committing? Promising but insufficient?
If somebody could have a look and give me some feedback,
I'd
Hi, Brya. I'm trying to access this but JIRA looks to be down. Is this
your fix around the fact that db2jcc was in the extensions directory?
I was wondering if anybody had had a chance to take a look
at the changes I proposed to fix DERBY-668.
http://issues.apache.org/jira/browse/DERBY-668
I'm having trouble getting my editor set up properly
to work with the Derby source code.
Can somebody send me the commonly-accepted Derby source
code tab-and-spacing conventions?
I'm using VIM, so ideally if somebody could point me at
a .vimrc that set things up the right way...
thanks,
bryan
While trying to test my fixes for DERBY-614, I think I may have
stumbled into an entirely unrelated DRDA protocol bug of some
sort. I've backed out my changes for DERBY-614 and I still see
this problem, so I don't think I've caused it; however, I might
have blown it. :)
Below are the steps to
Kathey Marsden (JIRA) wrote:
The change looks good to me. A couple small points and a request
Thanks Kathey, this is very helpful.
I'll pursue these points, but I don't think it will be until next
weekend; I'll let you know how it turns out.
thanks,
bryan
Oh, I see I misunderstood the question.
I think in the past I have always made a copy of
the jar file, added the new entry to the copy, and
then renamed the files around.
Sorry for the misunderstanding.
bryan
If anyone knows a way to get Ant to generate a list of files
(like the find command) that we could then filter, let me know.
I'm always up for puttering around with Ant scripts. Between
fileset, patternset, and selector, there's a lot of power
there. Maybe you could send me some more details
It would be
interesting if you can get the derbydocs javadoc build going using
multiple nested filesets, excluding the classes listed in tools/
javadoc/derbydocs_excludes.ant, and avoid the need to copy the entire
source tree to a new directory before generating the javadoc.
I'm possibly
: Bryan Pendleton [EMAIL PROTECTED]
While trying to test my fixes for DERBY-614, I think I may have
stumbled into an entirely unrelated DRDA protocol bug of some
sort. I've backed out my changes for DERBY-614 and I still see
this problem, so I don't think I've caused it; however, I might
have blown
1 - 100 of 4627 matches
Mail list logo
