"David W. Van Couvering" <[EMAIL PROTECTED]> writes:
> This vote is for establishing Rick Hillegas as a committer for
> Derby. Please vote +1 if you approve of Rick as a committer.
+1
--
Knut Anders
"David W. Van Couvering" <[EMAIL PROTECTED]> 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
..olav
Bryan Pendleton <[EMAIL PROTECTED]> writes:
> Knut Anders Hatlen (JIRA) wrote:
>> I have uploaded a new patch (DERBY-212-parsePKGNAMCSN-2.diff) where I
>> have tried to address Bryan's review comments.
>
> Hi Knut Anders,
>
> I read through your changes and they look good to me. Thanks for
> takin
+1
Rick will be good for Derby!
David W. Van Couvering wrote (2006-01-09 10:20:31):
> This vote is for establishing Rick Hillegas as a committer for Derby.
> Please vote +1 if you approve of Rick as a committer.
>
> I am nominating Rick because he has been consistently contributing
I wonder if we should look at grant/revoke augmenting the existing
authorization model instead of replacing it.
The existing authorization functionality has:
- disallow a user
- allow a user read-only
- allow a user full-access
Grant/revoke does not replace this functionality, it could be
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
As David indicates Rick has been a useful and active contributor on
numerous fronts for Derby.
Dan.
[ http://issues.apache.org/jira/browse/DERBY-612?page=all ]
Daniel John Debrunner closed DERBY-612:
---
Verified by running and passing i18nTest suite with a class path that did not
include the locale jars files.
> Add locale jars as ClassPath entr
+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.
>
>
>
Ah, great, thanks.
David
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
I can use reflection to see if the initCause() method is available, and
call it if it's there. For JDK 1.3 vms, I can ensure that the stack
trace is logged prior to converting the exception.
Just on the i
Knut Anders Hatlen (JIRA) wrote:
I have uploaded a new patch (DERBY-212-parsePKGNAMCSN-2.diff) where I
have tried to address Bryan's review comments.
Hi Knut Anders,
I read through your changes and they look good to me. Thanks for
taking the time to investigate my comments. I have no further
c
David W. Van Couvering wrote:
> I can use reflection to see if the initCause() method is available, and
> call it if it's there. For JDK 1.3 vms, I can ensure that the stack
> trace is logged prior to converting the exception.
Just on the initCause method, the engine does:
if (J
Looking for your thoughts on a bit of a conundrum.
It is working pretty well to migrate the client code to throw
SQLException directly rather than org.apache.derby.client.am.SqlException.
There are some diagnostic features, however, that can't migrate, because
they rely on extra information s
Øystein Grøvlen wrote:
Suresh,
Thanks for considering my suggestions. A few responses below.
--
Øystein
>> * SYSCS_DISABLE_LOG_ARCHIVE_MODE()
>> - Is checkBackupTransactionIsIdle() strictly necessary here? This
>> seems like an operation where failures could be handle at
Rick Hillegas wrote:
>
>
> I have clipped to JIRA-499 a fix for these regressions.
Thanks Rick for fixing the tests. I will take a look. However, I don't
think these are fixes for a regression, they are test updates. A fix
for a regression would have to be in the code and could never be fixe
On 1/10/06, Andrew McIntyre <[EMAIL PROTECTED]> wrote:
>
> On Dec 27, 2005, at 4:27 PM, Deepa Remesh wrote:
>
> > It would be great if a committer can add a new component 'newcomer'.
> > We can add this information to the Wiki page. Also, I can update the
> > bugs listed in DERBY-257 with this new
[ http://issues.apache.org/jira/browse/DERBY-39?page=all ]
Deepa Remesh updated DERBY-39:
--
Component: Newcomer
Description:
The exception:
---
Error: An ON clause associated with a JOIN operator is not valid.
--
[ http://issues.apache.org/jira/browse/DERBY-163?page=all ]
Deepa Remesh updated DERBY-163:
---
Component: Newcomer
Description:
The timestamp format within Derby contains the following information:
-mm-dd-hh.mm.ss.mm
When issuing a CURREN
[ http://issues.apache.org/jira/browse/DERBY-223?page=all ]
Deepa Remesh updated DERBY-223:
---
Component: Newcomer
> Change programs under demo directory use consistent package names so IDEs do
> not report errors
> -
[ http://issues.apache.org/jira/browse/DERBY-17?page=all ]
Deepa Remesh updated DERBY-17:
--
Component: Newcomer
Description:
Opening this bug on behalf of Katherine Marsden
--
JCC cannot guar
[ http://issues.apache.org/jira/browse/DERBY-211?page=all ]
Deepa Remesh updated DERBY-211:
---
Component: Newcomer
Description:
For a call of a procedure with no dynamic results embedded
Cloudscape returns a one result, an update count of zero. Howev
[ http://issues.apache.org/jira/browse/DERBY-209?page=all ]
Deepa Remesh updated DERBY-209:
---
Component: Newcomer
Description:
Network server tests currently run only for the following suites
derbynetmats jdbcapi jdbc20 multi
with the tests listed in
[ http://issues.apache.org/jira/browse/DERBY-204?page=all ]
Deepa Remesh updated DERBY-204:
---
Component: Newcomer
Description:
The Derby javadoc has many warnings that could be cleaned up.
A full list of javadoc warnings can be produced by invoking
On Dec 27, 2005, at 4:27 PM, Deepa Remesh wrote:
It would be great if a committer can add a new component 'newcomer'.
We can add this information to the Wiki page. Also, I can update the
bugs listed in DERBY-257 with this new component.
I've added a "Newcomer" component to JIRA. It won't show
I'd be interested in coming if it's open to non-developers :-)
Rick Hillegas wrote:
So far, Jeff, David, and Kathey have rsvd. Anyone else interested?
Would people prefer a different day?
Thanks,
-Rick
Rick Hillegas wrote:
I'd like to setup a lunch for those of us in the Bay Area who are
I originally picked the name 'secureMode' to cover not just grant &
revoke work I am doing, but also expecting more enhancements in the
security area. I know Francois is working on something related for
sure.. But may be the name should reflect what is actually being done,
to avoid misleading.
On Jan 9, 2006, at 10:20 AM, 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. +1andrew
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
--
Jeremy
+1
--
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
[ http://issues.apache.org/jira/browse/DERBY-612?page=all ]
Andrew McIntyre resolved DERBY-612:
---
Fix Version: 10.2.0.0
Resolution: Fixed
Committed revision 367801.
> Add locale jars as ClassPath entries in derby.jar
> ---
I did not pick 'ansiAuthMode' because one could easily confuse 'Auth'
for Authentication instead of Authorization (these are 2 different
beasts) - hence why I leaned towards 'ansiAuthoMode' ;)On 1/10/06, David W. Van Couvering <[EMAIL PROTECTED]
> wrote:ansiAuthMode (not AuthoMode) sounds good to m
[
http://issues.apache.org/jira/browse/DERBY-612?page=comments#action_12362371 ]
Andrew McIntyre commented on DERBY-612:
---
Ant's general lack of list processing or loops would, in my opinion, make
generating the list of locales to add to the manifest's
[ http://issues.apache.org/jira/browse/DERBY-612?page=all ]
Andrew McIntyre reassigned DERBY-612:
-
Assign To: Andrew McIntyre
> Add locale jars as ClassPath entries in derby.jar
> -
>
> Key: DE
So far, Jeff, David, and Kathey have rsvd. Anyone else interested?
Would people prefer a different day?
Thanks,
-Rick
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?
Andreas Korneliussen wrote:
I propose to introduce a new test type called "junit" (current test
types are: sql,sql2,unit,java,multi,demo - unit is not junit)
Then you can use:
java org.apache.derbyTesting.functionTests.harness.RunTest
.junit
to run a Junit test - instead of:
java org.apac
Daniel John Debrunner wrote:
I'm still thinking about this 'secureMode' approach and the interaction
with the existing authentication model. One issue I do have is the name
of the attribute, 'secureMode'. I don't believe that the current
grant/revoke syntax makes Derby completely secure, thus t
ansiAuthMode (not AuthoMode) sounds good to me, I agree that there is a
false sense of security around the term secureMode. How secure is
secure? And this is just about authentication and authorization,
necessary but not necessarily sufficient in terms of security.
David
Francois Orsini wro
Agreed - I have had the same reserve but could not really come up with a better name ;)
Although I was thinking of 'ansiAuthorizationMode' (for ANSI authorization mode) or 'ansiAuthoMode'On 1/10/06, Daniel John Debrunner <
[EMAIL PROTECTED]> wrote:I'm still thinking about this 'secureMode' approac
I have been playing with Dan's suggestion of setting up shared
infrastructure for i18n and error handling, but only having the client
use it, and it's working pretty well. The only cut-and-paste at this
time are the messages that are shared between client and server.
But before I commit to th
Bryan,
Thanks as usual for the incredibly detailed explanations--I don't know how long
it took you to write that email, but it was extremely helpful!
Regarding the test cases for DERBY-125 and DERBY-170, I'll need to spend some
time looking at those before I can come up with any suggestions.
Francois Orsini wrote:
> I think we just *cannot* let anyone override the 'defaultConnectionMode'
> database configuration property - The user would have had to be granted
> a 'system privilege' of some sort. Now as far as migrating a secure
> database to a legacy mode one, there would need to be
+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.
I am nominating Rick because he has been consistently contributing to
the Derby project in the following ways:
- He has contributed so
[ http://issues.apache.org/jira/browse/DERBY-785?page=all ]
Daniel John Debrunner resolved DERBY-785:
-
Resolution: Invalid
1.0 is out of range for the given decimal definition
> Cannot specify default value for DECIMAL(15,15) column
> -
I will take a look at this... It ran cleanly for me..
Satheesh
Ole Solberg (JIRA) wrote:
Failure in derbyall/derbylang since r366564 | 2006-01-06 21:44:57 +0100 (Fri, 06 Jan 2006) | Add grantRevoke test to derbyLang suite.
--
I think we just *cannot* let anyone override the
'defaultConnectionMode' database configuration property - The user
would have had to be granted a 'system privilege' of some sort. Now as
far as migrating a secure database to a legacy mode one, there would
need to be good reasons for that, such as r
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
-jean
Is there any write up of the correct way to write new Junit tests?
I am trying to follow the junit cookbook when writing new junit tests.
http://junit.sourceforge.net/doc/cookbook/cookbook.htm
I do have some thoughts on how to write new JUnit Tests.
When writing tests for Derby (using JDBC)
Hi Kathey,
I have clipped to JIRA-499 a fix for these regressions. Thanks for the
heads-up about the version numbers in the canons. I finessed that issue
by removing the volatile numbers from the canons. Instead, the metadata
test now compares version numbers internally and only emits
diff-tr
[ http://issues.apache.org/jira/browse/DERBY-499?page=all ]
Rick Hillegas updated DERBY-499:
Attachment: bug499_jdk13tests.diff
Hi Kathey: The attached patch bug499_jdk13tests.diff fixes the regressions you
found in the metadata.java and syscat.sql test
Andreas Korneliussen wrote:
> It seems to me that for including a new JUnit test into i.e derby-all we
> need to make a new java class with a main() method, which parses a
> command line and set up the testsuite and run it, just like any java
> program. Basically we are running the junit tests as
Dag H. Wanvik wrote:
> Hi,
>
>
>>"Knut" == Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
>
>
> Knut>
> Knut> | Derby | DB2 univ | Postgres | MySQL
> Knut> -
> Knut> DriverManager.getConnect
It seems to me that for including a new JUnit test into i.e derby-all we
need to make a new java class with a main() method, which parses a
command line and set up the testsuite and run it, just like any java
program. Basically we are running the junit tests as test type "java".
Instead of hav
Andreas Korneliussen wrote:
> Daniel John Debrunner wrote:
>
>> DerbyJUnitTest has many cases where the SQLException thrown by Derby
>> (through JDBC) is ignored. To me, this seems very bad practice for test
>> code.
>>
> Isn't that bad practice for any code ?
True, but it's *very* bad practice
Bryan Pendleton wrote:
> Army wrote:
>
>> Well I'm a day late, but I've finished my review of the patch...
>
>
> Hi Army,
>
> Thank you very much for the careful review and the helpful suggestions.
> There were a number of points in your message, many of which I will
> address when I re-submit
Hi,
> "Knut" == Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
Knut>
Knut> | Derby | DB2 univ | Postgres | MySQL
Knut> -
Knut> DriverManager.getConnection | X |X |X |
Kristian Waagan wrote:
Sunitha Kambhampati wrote:
Kristian Waagan wrote:
Hello,
I just uploaded a patch for DERBY-746
(http://issues.apache.org/jira/browse/DERBY-746). It would be nice if
someone could spare the time to review it so it can be committed soon.
The patch fixes the problem o
If ResultSet.close is throwing an exception when being closed then to my
mind that's a bug, but we would never see it through a Junit test.
Unless the resultset is already closed, or you have closed the
connection for the resultset.
Correction: I guess ResultSet.close() should not throw an e
Failure in derbyall/derbylang since r366564 | 2006-01-06 21:44:57 +0100 (Fri,
06 Jan 2006) | Add grantRevoke test to derbyLang suite.
--
Key: DERBY-807
Daniel John Debrunner wrote:
DerbyJUnitTest has many cases where the SQLException thrown by Derby
(through JDBC) is ignored. To me, this seems very bad practice for test
code.
Isn't that bad practice for any code ?
Anyway, I think there are cases when you are interested in not throwing
the SQ
Hello.
I suspect that this phenomena is regression caused by patch for
DERBY-326, which is not committed yet.
I tried derbyall with/without patch for DERBY-326 and found this
phenomena does not happen without the patch.
I looked over the patch for DERBY-326 and
found there was no finalizer t
[ http://issues.apache.org/jira/browse/DERBY-298?page=all ]
Øystein Grøvlen resolved DERBY-298:
---
Fix Version: 10.2.0.0
10.1.3.0
Resolution: Fixed
Verified that the added test run without failure.
> rollforward will not work
Bryan Pendleton <[EMAIL PROTECTED]> writes:
> Army wrote:
>> Well I'm a day late, but I've finished my review of the patch...
>
> Hi Army,
>
> Thank you very much for the careful review and the helpful suggestions.
> There were a number of points in your message, many of which I will
> address whe
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 when connecting/disconnecting to/from a network
Olav Sandstå <[EMAIL PROTECTED]> writes:
> On 1/9/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
>> Are the additional round trips just on the first execution of a prepared
>> statement?
>
> No, it is on every execute of the query/transaction. The numbers are
> average of several thousand transacti
63 matches
Mail list logo
