Hello.
I have tried next modification to java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/dataSourcePermissions_net.java
.
==
public void shutdown() {
try {
+ waitSessionOfDBClosed(wombat);
+
TomohitoNakayama wrote:
Talking with people,
I came to think processing in dataSourcePermissions_net.java is
special as processing of program which use ConnectionPooling,
because such programs generally do not close database by themself.
So would just closing the pooled connection work?
For
Hello,
I am looking into issue DERBY-463, and I would like to be added to the
developer-group in Jira in order to be able to assign it to myself.
Thanks,
Fernanda
Philip Wilder wrote:
As part of the EG meeting I was requested to send him an email which
could in turn be forwarded on to other EG members. A few points before
I begin:
- I wish to apologize in advance as I did a poor job keeping track of
organizations everyone was associated with and an
Hello.
So would just closing the pooled connection work?
For instance, in dataSourcePermissions.java we have code line this
checkConnection(ds.getPooledConnection(FRANCES, isabella));
shutdown();
Could we just close the PooledConnection before calling shutdown in
Hello!
I'm trying to load the embedded derby driver, like
this:
Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
It throws an exception, saying it cannot load the
driver.
I've put the derbyjars in classpath (I work
in Eclipse)
What is wrong? Please help me
Bogdan
Hi,
no BOOLEAN type in derby?
Slavic
In particular there are two things I wish to address:
1) ResultSet.next() after last row of FORWARD_ONLY cursor throws an
SQL Exception with Network Server
I started working on this issue approximately 2 months ago and while
it has brought about a great deal of discussion there have been
On Aug 8, 2005, at 5:51 AM, Fernanda Pizzorno wrote:I am looking into issue DERBY-463, and I would like to be added to the "developer-group" in Jira in order to be able to assign it to myself.Hi Fernanda,I've added you to the derby-developers group in JIRA.andrew
Hello.
I follows myself.
I thought connection pool worked behind DataSource interface.
Is it impossible ... ?
Well ... Expression (of English ) which can cause misunderstanding
I meant that I want to confirm that the DataSource object in the code is a
connection pool.
Best regards.
Thanks, Jean. Glad I didn't try this myself :)
David
Jean T. Anderson wrote:
David,
Attaching your ppt to a Jira issue was a perfectly fine way to handle
this web site update, especially since adding your ppt needed some
updates that aren't intuitively obvious. Here's what I did:
1)'svn
http://www.codefutures.com/weblog/corporate/archives/2005/04/apache_derby_a.html
begin:vcard
fn:David Van Couvering
n:Van Couvering;David
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
That's my humble opinion. I would prefer this to, say, adding a new
method to the Connection class to force a connection closed even if it's
in a connection pool.
David
Kathey Marsden wrote:
TomohitoNakayama wrote:
Hello.
I follows myself.
I thought connection pool worked
Hi Slavic,
Thanks for bringing up this issue. Derby internally supports boolean
types but does not let users declare boolean typed columns. I have
logged an enhancment request (499) to track this issue. For the moment,
you can kludge around this problem by creating columns of type CHAR(1).
Lance recently sent me a set of proposed changes to the JDBC 4.0 spec
and in order to keep the dev community informed of all developments I'm
passing on the most pertinent bits. All of these proposed changes refer
to section 9.1 of the JDBC 4.0 specification.
Philip
Lance J. Andersen wrote:
I'd like to take stock of where this issue stands. I believe some
engineers may already be working on JUnit harnesses for Derby tests. If
so, could they let the derby-dev list know what they're planning and
what they've accomplished so far? In case there are multiple parallel
efforts going on
Hi Satheesh,
Do you think you could find some spare cycles to review this enhancement
and either commit the fix or suggest some improvments? I would really
appreciate it.
Thanks,
-Rick
Rick Hillegas wrote:
I have attached a fix to bug 171 to its JIRA page. Bug 171 is an
enhancement
No-one on the user list has objected to the proposed sunsetting policy
for jdk 1.3. Therefore I'm cautiously hopeful that we can move forward
with a vote. Let's wrap up the voting by Friday evening (12 August, 2005).
Thanks,
-Rick
Please vote on the following proposed policy for Derby's
According to BUILDING.txt, you can get a J2ME reference implementation
from Sun or IBM. The Sun implementation runs on Linux/x86. The IBM
implementation is encumbered by a trial license. How are people
building/testing the Derby J2ME support on XP?
Thanks,
-Rick
I did hear the same thing at OSCON -- that the startup of Derby,
especially when it has to create the schema and load initial data -- is
significantly slower than HSQL -- 20 seconds startup time instead of 1-2
for HSQL. It would be very good if we could reproduce and track down
the source of
The grammar's datatype-declaration-production contains a line which
disables the BOOLEAN datatype. If you remove this line, you can
successfully create tables with BOOLEAN columns. You can even create
indexes on those columns. You can even fudge around the lack of TRUE and
FALSE literals by
On 8/8/05, Rick Hillegas [EMAIL PROTECTED] wrote:
According to BUILDING.txt, you can get a J2ME reference implementation
from Sun or IBM. The Sun implementation runs on Linux/x86. The IBM
implementation is encumbered by a trial license. How are people
building/testing the Derby J2ME support on
Thanks, Satheesh and Shreyas.
-Rick
Satheesh Bandaram wrote:
Hi Rick,
I will take a look at the fix. *Shreyas*, since you worked on
DERBY-156 and have a patch for that problem, can you review this patch
too? We want to make sure this addresses DERBY-156 too.
Satheesh
Rick Hillegas
Rick Hillegas wrote:
Hi Slavic,
Thanks for bringing up this issue. Derby internally supports boolean
types but does not let users declare boolean typed columns. I have
logged an enhancment request (499) to track this issue. For the
moment, you can kludge around this problem by creating
Boolean column type is ANSI SQL-99 - if support is already there and
assuming there is no known issues (none in JIRA at least), then it
would be good to see it back from the grave. Just IMHO.
On 8/8/05, Kathey Marsden [EMAIL PROTECTED] wrote:
Rick Hillegas wrote:
Hi Slavic,
Thanks for
I don't think all the support is there... Like using them in expressions
or JDBC metadata to name some.
Dan has a good point in the second link provided by Kathey. Here is the
current status of BOOLEAN support in other DBs, from that message:
IBM DB2 UDB 7/8 - not supported
Informix -
Several RDBMS rely on BIT datatype support when they don't have
intrinsic BOOLEAN support (of course 'bit' allows more than 'boolean',
operator and semantics-wise)- this includes Sybase - as I understand
DB2 UDB does not have support for either BIT or BOOLEAN at this
point...to emulate it in DB2,
Good idea.
Hopefully this will mean Derby will
be deployed to the Maven repos as part of the Derby release process.
Thanks,
John
Jeremy Boynes [EMAIL PROTECTED] wrote on
08/08/2005 04:00:22 AM:
I added a maven directory to HEAD containing project definitions for
all
the artifacts that the
How about adding a JAR into java/jars with just the necessary interfaces
in it? This is common at Apache for API classes that projects need to
compile against (like the geronimo-spec-jta jar we have).
--
Jeremy
Andrew McIntyre wrote:
On 8/8/05, Rick Hillegas [EMAIL PROTECTED] wrote:
Rick Hillegas wrote:
Hi Satheesh,
Do you think you could find some spare cycles to review this
enhancement and either commit the fix or suggest some improvments? I
would really appreciate it.
Well I'm neither Satheesh nor Shreyas ;), but I did take a quick look at the
patch and here are
On Aug 8, 2005, at 7:25 PM, Jeremy Boynes wrote:
How about adding a JAR into java/jars with just the necessary
interfaces in it? This is common at Apache for API classes that
projects need to compile against (like the geronimo-spec-jta jar we
have).
Certainly a good idea, but is there
31 matches
Mail list logo
