Bryan Pendleton wrote:
Kristian Waagan wrote:
Hello,
While investigating a little around logging of connections, I found
that the Javadoc of NetworkServerControl.logConnections(boolean)
states that a message is printed to derby.log when a connection is
made or closed. I do not observe this
Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
--
Key: DERBY-809
URL: http://issues.apache.org/jira/browse/DERBY-809
Project: Derby
Type: Bug
Components:
[
http://issues.apache.org/jira/browse/DERBY-807?page=comments#action_12362526 ]
Ole Solberg commented on DERBY-807:
---
Fix verified:
http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-368163.html
Failure in
[ http://issues.apache.org/jira/browse/DERBY-807?page=all ]
Ole Solberg closed DERBY-807:
-
Resolution: Fixed
Failure in derbyall/derbylang since r366564 | 2006-01-06 21:44:57 +0100
(Fri, 06 Jan 2006) | Add grantRevoke test to derbyLang suite.
[ http://issues.apache.org/jira/browse/DERBY-99?page=all ]
Bernt M. Johnsen reassigned DERBY-99:
-
Assign To: Dag H. Wanvik
Add support for update functionality using JDBC 2.0 updatable resultset apis
[ http://issues.apache.org/jira/browse/DERBY-98?page=all ]
Bernt M. Johnsen reassigned DERBY-98:
-
Assign To: Dag H. Wanvik
Add support for delete functionality using JDBC 2.0 updatable resultset apis
[ http://issues.apache.org/jira/browse/DERBY-212?page=all ]
Bernt M. Johnsen resolved DERBY-212:
Resolution: Fixed
Optimize some specific methods in Network Server to improve performance
[ http://issues.apache.org/jira/browse/DERBY-212?page=all ]
Knut Anders Hatlen reopened DERBY-212:
--
Assign To: Dyre Tjeldvoll (was: Knut Anders Hatlen)
Reopening the issue since my patch didn't address everything mentioned
in the
Kathey Marsden [EMAIL PROTECTED] writes:
This sounds like a correct analysis and a good solution. A couple of
areas of vague concern:
You might want to consider if there is any impact on the fix for
DERBY-213. I think it should be fine, but popped into my mind as a red
flag.
Thanks,
Satheesh Bandaram wrote (2006-01-11 13:28:30):
I already did that... You are seeing my intermediate results... I kept saving
in the middle, old habit.
Here is my first version of active developments as I have noticed. I know
there
are some more that I have missed. Before I continue
David W. Van Couvering wrote:
This vote is for establishing Rick Hillegas as a committer for Derby.
Please vote +1 if you approve of Rick as a committer.
+1
I have to say, I thought long and hard about this one. My life as
advocate for the installed user base has been much more challenging
Hi Kathey,
I don't want to pull on a big ball of yarn, either. Do you think the
following changes will be adequate?
1) Remove the hard-coded release-specific variables from the metadata test.
2) Go back to printing release variables in the canons.
3) Update the bumplastdigit target to include
[ http://issues.apache.org/jira/browse/DERBY-690?page=all ]
Dag H. Wanvik reassigned DERBY-690:
---
Assign To: Dag H. Wanvik
Add scrollable, updatable, insensitive result sets
--
Key: DERBY-690
[ http://issues.apache.org/jira/browse/DERBY-775?page=all ]
Dag H. Wanvik reassigned DERBY-775:
---
Assign To: Dag H. Wanvik
Network client: Add support for scrollable, updatable, insensitive result sets
Rick Hillegas wrote:
Hi Kathey,
I don't want to pull on a big ball of yarn, either. Do you think the
following changes will be adequate?
1) Remove the hard-coded release-specific variables from the metadata
test.
2) Go back to printing release variables in the canons.
3) Update the
Bernt == Bernt M Johnsen [EMAIL PROTECTED] wrote:
Bernt Here is my first version of active developments as I have noticed. I
know there
Bernt are some more that I have missed. Before I continue further, any
comments on
Bernt the format?
Bernt
Bernt
Hi Bernt,
Bernt M. Johnsen wrote:
A very nice overview. Especially as an addition to Jira and as a
gateway into Jira.
BUT: I think its equally (or more) important that we take full
advantage of Jira too. The most important one is to set Jira issues
being worked on to In progress.
Right...
[
http://issues.apache.org/jira/browse/DERBY-125?page=comments#action_12362549 ]
Bryan Pendleton commented on DERBY-125:
---
I am withdrawing this patch. It is unnecessarily large and complex, as it
bundles multiple bug-fixes into one patch. I will
[ http://issues.apache.org/jira/browse/DERBY-125?page=all ]
Bryan Pendleton updated DERBY-125:
--
Attachment: (was: changes2.html)
Network Server can send DSS greater than 32K to client, which breaks DRDA
protocol.
[ http://issues.apache.org/jira/browse/DERBY-125?page=all ]
Bryan Pendleton updated DERBY-125:
--
Attachment: (was: svn-dec_28_2005.diff)
Network Server can send DSS greater than 32K to client, which breaks DRDA
protocol.
Hi Kathey,
I'd welcome your suggestions about how to recode the test to behave as
you describe. It seems difficult to me because the code in question
doesn't know that the columns are supposed to be BOOLEAN. The code in
question is inspecting ResultSetMetaData, which returns different type
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton updated DERBY-170:
--
Attachment: changes.html
svn_jan12_2006.diff
svn_jan12_2006.status
Attached is a proposed patch for DERBY-170, which teaches
Bernt M. Johnsen wrote:
Satheesh Bandaram wrote (2006-01-11 13:28:30):
I already did that... You are seeing my intermediate results... I kept saving
in the middle, old habit.
Here is my first version of active developments as I have noticed. I know
there
are some more that I have missed.
Kathey Marsden wrote:
Rick Hillegas wrote:
What if the metadata test internally verified that the version numbers
from the client driver agreed with the values in dnc.properties? Then
we wouldn't have to hard code version numbers anywhere: not in the
test code and not in the canons. We
Satheesh Bandaram wrote:
I already did that... You are seeing my intermediate results... I kept
saving in the middle, old habit.
Here is my first version of active developments as I have noticed. I
know there are some more that I have missed. Before I continue further,
any comments on the
Satheesh Bandaram wrote:
I already did that... You are seeing my intermediate results... I kept
saving in the middle, old habit.
Here is my first version of active developments as I have noticed. I
know there are some more that I have missed. Before I continue further,
any comments on the
Wishi I could join but it's a little far for me.
Mamta
On 1/11/06, Brian McCallister [EMAIL PROTECTED] wrote:
I'd love to, but cannot make it up to the city for lunch very easily.Will be there in spirit =)
-Brian
Daniel John Debrunner wrote:
Do we need the contributor column? I think we found from the similar
column in the old to-do list that it encouraged direct e-mails to the
contact listed.
Dan.
I can remove it, but I thought since this list is for short-term use, to
help plan for immediate
[ http://issues.apache.org/jira/browse/DERBY-573?page=all ]
Mamta A. Satoor updated DERBY-573:
--
Attachment: Derby573OptimizerOverridesAndRunTimeStatistics011206.txt
I have attached a patch named
Derby573OptimizerOverridesAndRunTimeStatistics011206.txt
Hi,
There are about 10 failures while running derbyall with the new ibmjdk1.5.
Jvminfo:
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20051104)
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32
j9vmxi3223-20051103 (JI
T enabled)
J9VM -
[ http://issues.apache.org/jira/browse/DERBY-679?page=all ]
Eric Radzinski updated DERBY-679:
-
Attachment: derby679.diff
rdevconcepts2462.html
Attached patch applies the requested change to the Lock Compatibility Matrix
table (Shared
+1
On 1/11/06, Suresh Thalamati [EMAIL PROTECTED] wrote:
+1David W. Van Couvering wrote: This vote is for establishing Rick Hillegas as a committer for Derby.
Please vote +1 if you approve of Rick as a committer.
Same problem for me... I work in San Jose area. I might still decide to
join the lunch, but not sure yet.
Satheesh
Mamta Satoor wrote:
Wishi I could join but it's a little far for me.
Mamta
On 1/11/06, Brian McCallister [EMAIL PROTECTED] wrote:
I'd
love to, but cannot make it
+1
Mamta Satoor wrote:
+1
On 1/11/06, *Suresh Thalamati* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
+1
David W. Van Couvering wrote:
This vote is for establishing Rick Hillegas as a committer for
Derby.
Please vote +1 if you approve of Rick as a committer.
count me in for lunch.
Thanks,
Ramandeep
On 1/12/06, Satheesh Bandaram [EMAIL PROTECTED] wrote:
Same problem for me... I work in San Jose area. I might still decide to join the lunch, but not sure yet.
Satheesh
Mamta Satoor wrote:
Wishi I could join but it's a little far for me.
Mamta
On
Satheesh Bandaram wrote:
Daniel John Debrunner wrote:
Do we need the contributor column? I think we found from the similar
column in the old to-do list that it encouraged direct e-mails to the
contact listed.
Dan.
I can remove it, but I thought since this list is for short-term use,
Daniel John Debrunner wrote:
I'm
curious how do you think it would be useful?
For status updates... If I look at the list after long time, I know
which items I need to update more easily. Guess feature name might be
enough to remind me. :-)
I have changed the page to have three tables now.
Rick Hillegas wrote:
The code in question is inspecting ResultSetMetaData, which returns
different type information depending on your vm. On jdk1.3 (JDBC 3),
you can't tell SMALLINT from BOOLEAN just by inspecting
ResultSetMetaData. To achieve what you want, I think this test needs
to be
intermittent diff for store/RecoveryAfterBackup.java test
-
Key: DERBY-810
URL: http://issues.apache.org/jira/browse/DERBY-810
Project: Derby
Type: Test
Components: Store
Versions: 10.2.0.0
Rick Hillegas wrote:
I'd like to setup a lunch for those of us in the Bay Area who are
working on Derby. I'm thinking of Wednesday February 1 in San Francisco.
Any interest?
Thanks,
-Rick
I'm 600 miles too far south, so can't attend, but have a great lunch! If
there are any cool tech
Jean T. Anderson wrote:
Olav Sandstå wrote:
Jean has offered to put the presentation on the Derby web page. I will
send it to her when I get back from Christmas vacation.
I don't think this is the way to handle such items. The licensing of
items sent directly to individuals is not clear.
I applied all suggestions. Let me know if any more changes are required.
http://wiki.apache.org/db-derby/DerbyDevActivities
It would be great if everyone can take a minute to update the page.
Satheesh
Daniel John Debrunner wrote:
Derby should be able to run on 1.6 without any JDBC 4.0
Daniel John Debrunner wrote:
Jean T. Anderson wrote:
Olav Sandstå wrote:
Jean has offered to put the presentation on the Derby web page. I will
send it to her when I get back from Christmas vacation.
I don't think this is the way to handle such items. The licensing of
items sent
I am (as we talked about it in-person) ;)On 1/10/06, Rick Hillegas [EMAIL PROTECTED] wrote:
So far, Jeff, David, and Kathey have rsvd. Anyone else interested?Would people prefer a different day?
Thanks,-RickRick Hillegas wrote: I'd like to setup a lunch for those of us in the Bay Area who are
Jean T. Anderson wrote:
Daniel John Debrunner wrote:
Jean T. Anderson wrote:
Olav Sandstå wrote:
Jean has offered to put the presentation on the Derby web page. I will
send it to her when I get back from Christmas vacation.
I don't think this is the way to handle such items. The
Thanks, Kathey. I appreciate your thoroughness in reviewing this patch
and I will work on a new patch which I hope will meet your 3 conditions.
Cheers,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
The code in question is inspecting ResultSetMetaData, which returns
different type
[ http://issues.apache.org/jira/browse/DERBY-125?page=all ]
Bryan Pendleton updated DERBY-125:
--
Attachment: changes.html
svn_jan_12_2006.diff
svn_jan_12_2006.status
Attached is a focused patch which addresses *only* the
One of my paranoid fears about
the junit assert testing is that it's impossible to tell if a test ran
and did everything, or didn't do anything. The output is the same in
both cases.
Dan.
It's a downside of assertion-based tests. My workaround is to seed the
test with print statements,
[
http://issues.apache.org/jira/browse/DERBY-499?page=comments#action_12362582 ]
Rick Hillegas commented on DERBY-499:
-
It's, admittedly, an odd set of casts and I wonder if anyone really needs them.
The casts between BOOLEAN and CLOB are inherited
What can be done about this? It looks like FromVTI.java implements
Optimizable, which I'm assuming is the interface to supply indexed
lookup. But, like I said, my head is swimming trying to figure out
if I either 1) don't understand how to enable an indexed lookup for
my VTI or 2) if it's
Is this what you were referring to, Jeff?
derby.language.logQueryPlan
Function
When this property is set to true, Derby writes the query plan information into the derby.log file for all executed queries.
This property is useful for debugging to know what query plan was chosen by the optimizer.
Is this what you were referring
to, Jeff?
derby.language.logQueryPlan
Thanks, but that's not it. logQueryPlan causes the final query plan to be
written to derby.log. I was thinking of a trace function that creates a
trail of all the decisions and calculations the optimizer makes in
derby.log.
[ http://issues.apache.org/jira/browse/DERBY-756?page=all ]
Manish Khettry reassigned DERBY-756:
Assign To: Manish Khettry
OutOfMemory Error on continous execution of select statement using COUNT()
and DISTINCT on same connection
[
http://issues.apache.org/jira/browse/DERBY-756?page=comments#action_12362606 ]
Manish Khettry commented on DERBY-756:
--
It looks like the scan controller created in DistinctScalarAggregateResultSet
is never closed. This causes the scanController
54 matches
Mail list logo
