I took a quick look at Dibyendu's tests and I think they are OK. I
would like to know if these tests pass with the embedded xa support.
Tests 8 and 9 are IMO completely spec compliant but I believe they will
not pass with the majority of databases claiming xa support. As such
it might not be
APACHE DERBY STATUS:
Last modified at [$Date: 2005-02-10 15:37:41 -0500 (Thu, 10 Feb 2005) $] by
$Author: fuzzylogic $.
Web site: http://incubator.apache.org/derby/
Incubator Status
Description
"Derby" is a snapshot of the IBM's Cloudscape Java relational database. IBM is
opening the cod
Yes, this was my experience also. You can't have multiple
configurations in a VM instance, because everything is dependent on
system properties (both Derby itself as well as the test harness
infrastructure). I don't *think* using classloaders will help because
system properties, as I understa
Dag H. Wanvik wrote:
>if I
>want to test several possibilities, it would seem I need to start
>another VM or use explicit class loaders. I could use brute force and
>make a test per combination of properties settings I want to test, but
>that seems ugly.. Any ideas?
>
>
>
If you shutdown derby
[ http://issues.apache.org/jira/browse/DERBY-313?page=all ]
Dag H. Wanvik reassigned DERBY-313:
---
Assign To: Dag H. Wanvik
> testing/README.htm describes non-existing property
> --
>
> Key: DERBY-
[
http://issues.apache.org/jira/browse/DERBY-313?page=comments#action_66316 ]
Dag H. Wanvik commented on DERBY-313:
-
Unless sombody yells, I will make a patch reflecting this finding. Yell now ;-)
> testing/README.htm describes non-existing proper
David's the Geronimo guru on XA.
My understanding is that it is legal for a coordinator to delist a
resource before the end of a transaction and return it to the pool; it
could then be used by another thread (potentially in another
transaction) or just closed.
However, there are many resourc
[ http://issues.apache.org/jira/browse/DERBY-316?page=all ]
Susan Cline updated DERBY-316:
--
Attachment: derby_plugins.diff
derby_plugins.tar
Here are the attachments mentioned earlier, derby_plugins.diff,
and derby_plugins.tar.
> Derby UI a
Derby UI and Help Plug-in documentation for the Derby Web Site
--
Key: DERBY-316
URL: http://issues.apache.org/jira/browse/DERBY-316
Project: Derby
Type: Task
Components: Web Site
Versions: 10.1.0.0
Attaching a file to an issue doesn't require derby-developers.
Open the Jira issue, if it hasn't been opened yet, then under
"Operations" down on the left you should see "Attach file to this issue".
-jean
Hi,
Could someone (I think Satheesh has these priviledges?) add me to the
derby-dev
Hi,
> "KM" == Kathey Marsden <[EMAIL PROTECTED]> wrote:
KM> Thanks for working on the test.
I am encountering an issue making a test for the setting of
derby.stream.error.* properties. It seems the testing harness gives me
no easy way to test combinations of system properites; once the dr
Hi,
Could someone (I think Satheesh has these priviledges?) add me to the derby-developers list in JIRA so I can add attachments to a JIRA issue?
Thanks!
Susan
Satheesh Bandaram wrote:
I have briefly looked at the proposed changes. Some initial comments:
Wow, that was fast ;)
Thanks for the feedback. I think all 4 points you made are good ones, and I
will look into them more.
>1. I suspect the logic to reject XML columns at the toplevel is m
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
David Van Couvering updated DERBY-243:
--
Attachment: DERBY-243.diff
Good catch by Kathey. I added some SQL to lang/miscerrors.sql to print out all
the rows
from the error log using the Err
[ http://issues.apache.org/jira/browse/DERBY-197?page=all ]
Samuel Andrew McIntyre closed DERBY-197:
Resolution: Fixed
Fix Version: 10.0.2.2
10.1.0.0
Revision 178554 (10.1) and 178555 (10.0)
> Add tip for Windows users
On 5/25/05, David Van Couvering (JIRA) wrote:
>
> Can a committer please submit the second patch to this bug so that I can
> close it? It is a very simple change to BUILDING.txt...
You know, I was looking for the second attachment and somehow missed
it in all the mail that went by.
Committed,
Great! I hope this initial XML support in Derby will lead to other XML
enhancements as well. SQL-XML is a large specification with many other
features like publish functions, XMLConcat, mapping of SQL data into
XML, schema validation, XMLCast, XMLQuery and XMLTable etc.
I have briefly looked a
Øystein Grøvlen wrote:
"ST" == Suresh Thalamati <[EMAIL PROTECTED]> writes:
ST> derby has two types of log files , one that works in RWS mode with a
ST> preallocated log file ,
What is RWS mode?
RWS mode is writing transction log using the write sync mechanism
supp
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
David Van Couvering updated DERBY-243:
--
Attachment: DERBY-243.diff
A rescan of svn status revealed that the patch included my modification of
derby.properties to use the "test: durability
jdbcapi/rsgetXXXcolumNames fails with DerbyNet framework
Key: DERBY-315
URL: http://issues.apache.org/jira/browse/DERBY-315
Project: Derby
Type: Bug
Components: Test
Versions: 10.1.0.0
Reporter:
Hi, Kathey. It's not a huge pressure to get this done (at least on my
end), but I agree it would be great if somebody else did the initial
verification that it works OK.
Yes, the Error Log VTI output should have changed. I will run a test to
make sure it looks OK.
David
Kathey Marsden wro
David Van Couvering (JIRA) wrote:
>Here is an updated patch for this item. This addresses my previous comment by
>pushing
>the unique id down to the LanguageConnectionContext.
>
>
Thanks David,
It is probably going to be this weekend before I have a chance to look
at this patch. Do you think
[ http://issues.apache.org/jira/browse/DERBY-305?page=all ]
David Van Couvering updated DERBY-305:
--
Attachment: spelling_grammar_changes_with_comments.txt
> Fix error messages in properties files to match text in documentation
>
[ http://issues.apache.org/jira/browse/DERBY-305?page=all ]
David Van Couvering updated DERBY-305:
--
Attachment: DERBY-305.diff
The attached patch fixes the messages_en.properties file to be in line with the
changes submitted to the documentation.
Dibyendu Majumdar wrote:
>From: "Kathey Marsden" <[EMAIL PROTECTED]>
>
>
>>I think the workaround for DERBY-246, to leave the logical connection
>>open until the end of the global transaction, should be documented in
>>the release notes.
>>
>>
>
>Hi Kathey,
>
>Unfortunately, this is not a w
I was looking at this failure today. Seems like an issue with JCC
driver. For now, I am thinking of disabling this test for JCC driver only.
Satheesh
David Van Couvering wrote:
> I just ran derbyall off a clean build of the trunk, and
> jdbcapi/rsgetXXXcolumnNames failed when running with DerbyN
[
http://issues.apache.org/jira/browse/DERBY-197?page=comments#action_66298 ]
David Van Couvering commented on DERBY-197:
---
Can a committer please submit the second patch to this bug so that I can close
it? It is a very simple change to BUILD
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
David Van Couvering updated DERBY-243:
--
Attachment: DERBY-243.diff
Here is an updated patch for this item. This addresses my previous comment by
pushing
the unique id down to the Language
[ http://issues.apache.org/jira/browse/DERBY-19?page=all ]
Daniel John Debrunner reassigned DERBY-19:
--
Assign To: Daniel John Debrunner
> NPE when trying to create a database at a directory that is not allowed
> -
I just ran derbyall off a clean build of the trunk, and
jdbcapi/rsgetXXXcolumnNames failed when running with DerbyNet. It
passes fine with embedded and with DerbyNetClient.
I get an error:
FAIL -- unexpected exception
SQLSTATE(42X01): Syntax error: Encountered "(" at line 1, column 26.
com.ib
I think one of the advantages of an open source product is the ability
to expose new functionality, with the understanding that it may change
in the future due to user feedback and changing standards. My hope
would be that we could use this kind of change to push a new standard if
appropriate,
Currently, even though network server materializes the LOB to the
client, it uses getBlob or getClob to retrieve the large object. This
holds locks until the end of the transaction.
I would like to change Network Server to:
- Use getCharacterStream and getBinaryStream instead of getClob
I concur with this approach: a lot of trains leaving the station, and if
you miss a train you just get on the next train.
David
Daniel John Debrunner wrote:
Some of my discussion on this has also been looking at the bigger
picture, how long should a release manager wait for a patch for a
rel
On May 24, 2005, at 6:29 PM, Army wrote:
I should clarify. The reason I was thinking that this should not be documented as "official" yet is because the work I've done is based on _working__drafts_ of the SQL/XML syntax--which means we run the risk of the syntax changing in the near future.
I se
eclipse plugin needs improved network server process handling
-
Key: DERBY-314
URL: http://issues.apache.org/jira/browse/DERBY-314
Project: Derby
Type: Bug
Components: Tools
Versions: 10.0.2.0
E
I committed this patch:
m2_142:159>svn commit
Sending
java\engine\org\apache\derby\impl\store\raw\log\LogAccessFile.jav
a
Transmitting file data .
Committed revision 178494.
Suresh Thalamati wrote:
Attached is small fix to make sure that log buffers are switched are
correctly when the are f
[
http://issues.apache.org/jira/browse/DERBY-217?page=comments#action_66286 ]
Daniel John Debrunner commented on DERBY-217:
-
Possibly fixed by changes to Derby-203 but I think if a streaming value is
passed into a BLOB or other binary value
[
http://issues.apache.org/jira/browse/DERBY-309?page=comments#action_66284 ]
Daniel John Debrunner commented on DERBY-309:
-
Hmmm, storemore passes for me, and derbyall passes on Sun & IBM's JDKs.
> Regression: store/backupRestore1.java fai
I have committed this patch with svn 178486.
Suresh Thalamati wrote:
Attached is small fix to make sure that log buffers are switched are
correctly when the are full,
when the log checksum feature is disabled due to a soft upgrade.
Tests: Ran derbyall , There were only two known
failire
Jeremy Boynes wrote:
> Daniel John Debrunner wrote:
>> This approach is a great
>> chance for the open source Darwin approach, see what the users like,
>> see how much confusion (e.g. questions in derby-user) there is with a
>> single data source with all properties vs. multiple data sources with
I can help out with this, but probably will not get to it until next
week, is that ok? Also let's move the discussion to some other
subject.
/mikem
Dibyendu Majumdar wrote:
From: "Mike Matrigali" <[EMAIL PROTECTED]>
3) some extra functionality on btree side (not necessarily show stopper).
comments below
Øystein Grøvlen wrote:
"MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> I spent some time thinking about this and I think the dummy record
MM> approach works in the current system assuming the code is as follows:
MM> o request for roll forward backup starts
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
If we rush a release out now and unify later, users see:
10.1 new ClientDataSource and EmbeddedSimpleDataSource
10.x new DerbyDataSource, deprecation of Client, EmbeddedSimple
and Embedded
If x = 1.1 or 2 then what we did in 10.1 looks
[
http://issues.apache.org/jira/browse/DERBY-309?page=comments#action_66266 ]
Ole Solberg commented on DERBY-309:
---
I updated to rev 178413 and ran storemore, but still saw the same problem.
When I did the following change
---
java/testing/org/apache
Philip Wilder wrote:
> Hello,
>
> I have recently been looking through the drda package in response to
> one of the threads from this mailing list and I have been noticing a
> number of suspicious pieces of code that very much look like trivial
> mistakes. I thought I would bring them up here in c
> "ØG(" == Øystein Grøvlen (JIRA) writes:
ØG(> [ http://issues.apache.org/jira/browse/DERBY-230?page=all ]
ØG(> Øystein Grøvlen updated DERBY-230:
ØG(> --
ØG(> Attachment: derby-230.diff
Is anybody planning to review/commit this?
--
> "MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> I spent some time thinking about this and I think the dummy record
MM> approach works in the current system assuming the code is as follows:
MM> o request for roll forward backup starts
MM> o all subsequent write request
Jeremy Boynes wrote:
>>
> If we rush a release out now and unify later, users see:
>
> 10.1 new ClientDataSource and EmbeddedSimpleDataSource
> 10.x new DerbyDataSource, deprecation of Client, EmbeddedSimple
> and Embedded
>
> If x = 1.1 or 2 then what we did in 10.1 looks silly and, bec
Jeremy Boynes wrote:
>>
> If we rush a release out now and unify later, users see:
>
> 10.1 new ClientDataSource and EmbeddedSimpleDataSource
> 10.x new DerbyDataSource, deprecation of Client, EmbeddedSimple
> and Embedded
>
I am concerned about the packaging of the DerbyDataSource I thi
[ http://issues.apache.org/jira/browse/DERBY-138?page=all ]
Dyre Tjeldvoll reassigned DERBY-138:
Assign To: Dyre Tjeldvoll
> Public javadoc should include the org.apache.derby.diag package to show usage
> of LockTable and other public VTI's
> --
Hello,
I have recently been looking through the drda package in response to one
of the threads from this mailing list and I have been noticing a number
of suspicious pieces of code that very much look like trivial mistakes.
I thought I would bring them up here in case my suspicions proved
cor
[ http://issues.apache.org/jira/browse/DERBY-220?page=all ]
Dyre Tjeldvoll updated DERBY-220:
-
Attachment: derbyall_report.txt
I have tried to run derbyall for about a week, but some tests always fail.
I hope that a committer can look at derbyall_report.
From: "Kathey Marsden" <[EMAIL PROTECTED]>
> I think the workaround for DERBY-246, to leave the logical connection
> open until the end of the global transaction, should be documented in
> the release notes.
Hi Kathey,
Unfortunately, this is not a workaround. For example, see section 4.2 of JTA
[ http://issues.apache.org/jira/browse/DERBY-220?page=all ]
Dyre Tjeldvoll updated DERBY-220:
-
Attachment: derby-220.2.diff
New diff based on the latest revision
> Javadoc build should include a timestamp and/or the svn revision number in a
> visible l
Dibyendu Majumdar wrote:
>The opensource client does not support XA correctly as yet. If this is
>released then it should be made clear in the documentation that the XA
>support is not functional. The other alternative is to wait for it to be
>fixed.
>
>
>
I think the workaround for DERBY-246,
> "ST" == Suresh Thalamati <[EMAIL PROTECTED]> writes:
ST> derby has two types of log files , one that works in RWS mode with a
ST> preallocated log file ,
What is RWS mode?
ST> and one which uses file sync with out preallocation. In case of
ST> preallocation , zero
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
Andrew McIntyre wrote:
I'm thinking that in the interests of getting an official release out
with the Derby client, I'd like to aim for a release in about two
weeks or so.
When we're ready - not before :-)
I think we are ready, it would
[ http://issues.apache.org/jira/browse/DERBY-13?page=all ]
Shreyas Kaushik closed DERBY-13:
Patch submitted
> Quoted names with embedded period mishandled in from list
> -
>
> Key: DERBY-
[
http://issues.apache.org/jira/browse/DERBY-276?page=comments#action_66254 ]
Shreyas Kaushik commented on DERBY-276:
---
Javadoc for J2SE 5.0 says...
relative
boolean relative(int rows)
throws SQLException
Moves the cursor a
From: "Mike Matrigali" <[EMAIL PROTECTED]>
> 3) some extra functionality on btree side (not necessarily show stopper).
Mike, I'd like to restart the work on documenting the Btree module.
Would you have time to add to any of your previous comments?
If you could provide a brief note on the various C
The problem is: relative(1)/relative(-1) can't both be identical to
next()/previous() and throw and exception if there is no current
row. I think there's an inconsistency here (In the Javadoc and in the
tutorial, while the spec has no "current row"-requirement in
ch. 14.2.2).
Shreyas
From: "Daniel John Debrunner" <[EMAIL PROTECTED]>
> I think we are ready, it would be good for Derby to get the open source
> client out as part of a release, release early release often!
The opensource client does not support XA correctly as yet. If this is
released then it should be made clear i
[ http://issues.apache.org/jira/browse/DERBY-18?page=all ]
Shreyas Kaushik closed DERBY-18:
Patch submitted
> Exposed name matching has bugs when the column name is qualified with a
> schema name.
>
[ http://issues.apache.org/jira/browse/DERBY-203?page=all ]
Shreyas Kaushik resolved DERBY-203:
---
Resolution: Fixed
Fixed, as the earlier comment says
> setNull(x,JDBCType.DATE) does not work when batching is turned on
> --
[
http://issues.apache.org/jira/browse/DERBY-276?page=comments#action_66251 ]
Bernt M. Johnsen commented on DERBY-276:
The same goes for absolute(0). It should throw an exception in JDBC 2.0, while
it should be equivalent to beforeFirst() in JD
[ http://issues.apache.org/jira/browse/DERBY-12?page=all ]
Shreyas Kaushik closed DERBY-12:
Patch submitted
> Quoted table names mishandled in select list expansion
> --
>
> Key: DERBY-12
>
[ http://issues.apache.org/jira/browse/DERBY-203?page=all ]
Shreyas Kaushik closed DERBY-203:
-
Patch submitted
> setNull(x,JDBCType.DATE) does not work when batching is turned on
> -
>
>
[ http://issues.apache.org/jira/browse/DERBY-276?page=all ]
Bernt M. Johnsen updated DERBY-276:
---
type: Improvement (was: Bug)
Since the implemented functionality is JDBC 2.0 compliant, this is not a bug,
but an "improvement" to become more JDBC 3.0 c
[
http://issues.apache.org/jira/browse/DERBY-276?page=comments#action_66249 ]
Bernt M. Johnsen commented on DERBY-276:
There has been a change from JDBC 2.0 to JDBC 3.0. In JDBC 2.0
relative(1)/relative(-1) is not necessarily equivalent to next
[ http://issues.apache.org/jira/browse/DERBY-13?page=all ]
Shreyas Kaushik resolved DERBY-13:
--
Resolution: Fixed
Fixed, as per the earlier comment from Dan
> Quoted names with embedded period mishandled in from list
> -
[ http://issues.apache.org/jira/browse/DERBY-18?page=all ]
Shreyas Kaushik resolved DERBY-18:
--
Resolution: Fixed
Fixed , as the earlier comment says
> Exposed name matching has bugs when the column name is qualified with a
> schema name.
> --
71 matches
Mail list logo
