[ http://issues.apache.org/jira/browse/DERBY-2037?page=all ]
Myrna van Lunteren updated DERBY-2037:
--
Derby Info: [Patch Available]
> provide checking tool to flag possible errors in message translations
>
[ http://issues.apache.org/jira/browse/DERBY-2037?page=all ]
Myrna van Lunteren updated DERBY-2037:
--
Attachment: DERBY-2037_20061121.stat
DERBY-2037_20061121.diff
Attaching a patch holding a reworked program, incl. README and build.x
Anders Morken <[EMAIL PROTECTED]> writes:
> We've taken some long hard looks at the lock manager, and we're
> convinced that there's a lot of potential for improvement in Derby lock
> management. Not that there's anything wrong with the approach taken in
> the current implementation - correctness
Convert derby/prepStmt.java to Junit
Key: DERBY-2100
URL: http://issues.apache.org/jira/browse/DERBY-2100
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.3.0.0
Hi Suresh,
I was able to extract the issue from my application. Only thing you need to
do is run the sql file(createDB.sql) with the attachement and try to run the
following select statement
Select * from vwDerbyBasePackage_derbygen_DerbyRepositoryObject67ceb178
I have also attached some batch fi
[ http://issues.apache.org/jira/browse/DERBY-859?page=all ]
Myrna van Lunteren closed DERBY-859.
> Resolve the IBM15 test failures by updating the corresponding master files
> --
>
>
[ http://issues.apache.org/jira/browse/DERBY-1108?page=all ]
Myrna van Lunteren closed DERBY-1108.
-
> The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5
> ---
>
>
[Auto-generated mail]
*Daily* 476847/2006-11-19 18:00:08 MET
Failed TestsOK Skip Duration Suite
---
*Jvm: 1.6*
lin
0519519 098.86% derbyall
063046304 099.33%
org.apache.derbyTesting.
Daniel John Debrunner wrote:
I was thinking more generally in that an XML value may be generated and
thus never have been stored to disk. How it is stored on disk and how
the XML value is serialized using XMLSERIALIZE() are different
operations, it's just an implementation detail of derby that
Rick Hillegas wrote:
Hi Kristian,
I agree that we should stabilize the 10.2 tests soon since we're
planning a 10.2.2 release in early December. If we don't merge the JUnit
infrastructure into 10.2, then porting a bug fix to the 10.2 branch may
involve re-writing the test case which verifies t
After a Lexical Error due to syntax error ,even a simple create table does
not work on the same connection.
-
Key: DERBY-2103
URL: http://issues.
[ http://issues.apache.org/jira/browse/DERBY-2059?page=all ]
Myrna van Lunteren closed DERBY-2059.
-
> derbynetmats/derbynetmats.fail:jdbcapi/resultset.java,derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java,derbynetmats/derbynetmats.fail:jdbcapi/paramet
[ http://issues.apache.org/jira/browse/DERBY-2059?page=all ]
Myrna van Lunteren resolved DERBY-2059.
---
Fix Version/s: 10.1.3.2
Resolution: Fixed
fixed by committing revision:
http://svn.apache.org/viewvc?view=rev&revision=477526
- added addi
[ http://issues.apache.org/jira/browse/DERBY-2102?page=all ]
Knut Anders Hatlen resolved DERBY-2102.
---
Resolution: Fixed
Derby Info: (was: [Patch Available])
Thank you, Øystein! Committed revision 477645.
> JDBC.assertFullResultSet should han
[ http://issues.apache.org/jira/browse/DERBY-2059?page=all ]
Myrna van Lunteren reassigned DERBY-2059:
-
Assignee: Myrna van Lunteren
> derbynetmats/derbynetmats.fail:jdbcapi/resultset.java,derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java,derby
I also didn't think we were going to backport all the junit stuff
to 10.2. As Myrna points out some of those changes involve decisions
not valid for 10.2, a released product.
It is unfortunate that some bug tests won't backport cleanly, but
that could be the case with any backport, and even if w
[Auto-generated mail]
*Daily* 477254/2006-11-20 18:00:08 MET
Failed TestsOK Skip Duration Suite
---
*Jvm: 1.6*
lin
0519519 099.70% derbyall
063046304 0 104.21%
org.apache.derbyTesting.
[
http://issues.apache.org/jira/browse/DERBY-1595?page=comments#action_12451347 ]
Julius Stroffek commented on DERBY-1595:
I was able to reproduce this but when I decreased the size of LOB to 2GB-2, I
got a different exception only on cl
[ http://issues.apache.org/jira/browse/DERBY-1108?page=all ]
Myrna van Lunteren reopened DERBY-1108:
---
backporting this fix to 10.1
> The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5
> --
[EMAIL PROTECTED] writes:
> Anders Morken <[EMAIL PROTECTED]> writes:
>
>> We've taken some long hard looks at the lock manager, and we're
>> convinced that there's a lot of potential for improvement in Derby lock
>> management. Not that there's anything wrong with the approach taken in
>> the cur
Thanks, Jean. That was the pointer I needed. I posted to that address,
was redirected to [EMAIL PROTECTED], and received a message
saying that ApacheCon hopes to give us that feedback in a couple weeks.
Regards,
-Rick
Jean T. Anderson wrote:
Rick Hillegas wrote:
Does anyone know where we
Knut Anders Hatlen wrote:
Mike Matrigali <[EMAIL PROTECTED]> writes:
Having said that it would be interesting if someone had time to
implement a higher performance latch implementation and plug it in
and see how much it helps. It would decrease the total time spent
in lock manager.
Ok, a new
Mike Matrigali <[EMAIL PROTECTED]> writes:
> Having said that it would be interesting if someone had time to
> implement a higher performance latch implementation and plug it in
> and see how much it helps. It would decrease the total time spent
> in lock manager.
Ok, a new experiment: I removed
Knut Anders Hatlen wrote:
Thanks Bryan, that could be the case. I have done some more
investigation and it seems like the method is only called when a
B-tree container is opened with a lock policy. It also seems like the
B-tree containers always are opened with a null/NoLocking lock policy
(r
[
http://issues.apache.org/jira/browse/DERBY-47?page=comments#action_12451812 ]
Bryan Pendleton commented on DERBY-47:
--
Note that there is a Wiki page related to this issue:
http://wiki.apache.org/db-derby/DerbyBug47
> Some possible improv
Embedded - Column of type CHAR, VARCHAR or LONG VARCHAR contains wrong value
after being updated using the ResultSet.updateBytes() method.
--
Ke
[
http://issues.apache.org/jira/browse/DERBY-1595?page=comments#action_12451686 ]
Julius Stroffek commented on DERBY-1595:
The exception in my comment was caused by the lack of disk space. I had started
the derby with traceAll and run ou
Network Client - Column of type CHAR, VARCHAR or LONG VARCHAR contains wrong
value after being updated using the updateObject() method with a clob as
parameter.
Bryan Pendleton <[EMAIL PROTECTED]> writes:
>> When this method is used, the specified latch will be
>> released if the lock cannot be obtained immediately, and that page
>> will be re-latched when the lock has been obtained.
>
> I'm just guessing here ...
>
> I think that there are some fairly ad
[ http://issues.apache.org/jira/browse/DERBY-2102?page=all ]
Øystein Grøvlen updated DERBY-2102:
---
Attachment: derby2102.diff
derby2102.diff adds handling of byte arrays to the general object-based
comparison in assertRowInResultSet(). I also added a
[
http://issues.apache.org/jira/browse/DERBY-1089?page=comments#action_12451805 ]
Bryan Pendleton commented on DERBY-1089:
Hi Christian,
I spent some time studying the code that you identified, and I set up various
experiments to learn
Mike Matrigali:
> by single row update do you mean (obviously not exact syntax):
> update x = y where key = z
This one, yeah. ~100-byte rows, INTEGER primary keys, we update the
filler only. UPDATE thetable SET filler = WHERE key = ;
> In the cursor case derby maintains an "internal" lock on the
Army wrote:
I made the following addition to the end of the "serializeToString()"
method in SqlXmlUtil.java and was able to get consistent results (i.e.
exactly the same characters) across platforms:
+String eol = PropertyUtil.getSystemProperty("line.separator");
+if (eol != null
[ http://issues.apache.org/jira/browse/DERBY-1693?page=all ]
Kristian Waagan updated DERBY-1693:
---
Fix Version/s: 10.2.1.8
Merged to 10.2 branch with revision 477699 and the following merge command:
svn merge -r 475816:475817 https://svn.apache.org/repo
Issue Subscription
Filter: Derby: JIRA issues with patch available (9 issues)
Subscriber: derby-dev
Key Summary
DERBY-812 Scripts to publish Derby test results
http://issues.apache.org/jira/browse/DERBY-812
DERBY-1089 Derby fails inserting a join into a table with a generat
Daniel John Debrunner wrote:
Myrna van Lunteren wrote:
I feel apprehesive about backporting all changes to junit framework in
trunk back to 10.2.
1. 10.2 is stable...which should mean changes get applied more
selectively.
2. The changes in the trunk have been made with happy disregard of jcc
On 11/20/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Kristian Waagan wrote:
> Rick Hillegas wrote:
>> Hi Kristian,
>>
>> I agree that we should stabilize the 10.2 tests soon since we're
>> planning a 10.2.2 release in early December. If we don't merge the
>> JUnit infrastructure into 10.
[
http://issues.apache.org/jira/browse/DERBY-2106?page=comments#action_12451832 ]
Daniel John Debrunner commented on DERBY-2106:
--
Though I have to say the phrase Army highlighted:
"When outputting a newline character in the instance
[
http://issues.apache.org/jira/browse/DERBY-1758?page=comments#action_12451842 ]
A B commented on DERBY-1758:
> The approach of enabling all code to read the DTD files is also "cheating".
True. But my attempts to selectively give the JAXP parser p
Knut Anders Hatlen <[EMAIL PROTECTED]> writes:
> For one client, there was not much gained, but for two clients, the
> throughput increased 20% compared to trunk. For three clients, the
> increase was 40%, and it was 145% for 30 clients. This was a lot more
> than I expected! I also ran a TPC-B li
Anders Morken <[EMAIL PROTECTED]> writes:
> The major benefit of reworking the lock manager is scalability - right
> now it's pretty much single threaded, which is fine for a lot of the
> scenarios Derby was written to perform in. However, for "benchmark
> compliance" in a world of multicore deskt
[ http://issues.apache.org/jira/browse/DERBY-2100?page=all ]
Øystein Grøvlen updated DERBY-2100:
---
Summary: Convert derbynet/prepStmt.java to Junit (was: Convert
derby/prepStmt.java to Junit)
Description:
Convert derbynet/prepStmt.java to Juni
[ http://issues.apache.org/jira/browse/DERBY-2102?page=all ]
Øystein Grøvlen updated DERBY-2102:
---
Attachment: derby2102v2.diff
Thanks for the review, Knut Anders. I have attached a new patch,
derby2102v2.diff, which fixes the null pointer issue. I h
[
http://issues.apache.org/jira/browse/DERBY-2106?page=comments#action_12451830 ]
Daniel John Debrunner commented on DERBY-2106:
--
XML processing says the 'XML processor MUST behave' as though all line endings
have been converted to
[
http://issues.apache.org/jira/browse/DERBY-1758?page=comments#action_12451839 ]
Daniel John Debrunner commented on DERBY-1758:
--
Switching the security manager hasn't been tested, the first time I ran a test
using the no security m
Improve Derby SQL/XML processing to account for Xalan's use of
platform-specific newlines when serializing.
---
Key: DERBY-2106
URL: http://issues.apache.org/j
Thanks Rajesh,
Just a heads-up that I'm still planning to cat-herd a 10.2.2 release in
early December. I think we have two solid weeks to port fixes to 10.2
before I cut a release candidate.
Regards,
-Rick
Rajesh Kartha wrote:
Hello,
I am yet to find a simple way in JIRA to review the list
[ http://issues.apache.org/jira/browse/DERBY-859?page=all ]
Myrna van Lunteren updated DERBY-859:
-
Affects Version/s: 10.1.3.1
> Resolve the IBM15 test failures by updating the corresponding master files
>
[ http://issues.apache.org/jira/browse/DERBY-859?page=all ]
Myrna van Lunteren reopened DERBY-859:
--
I'll port this back to 10.1 as the same failure happen there when running the
tests with ibm15.
> Resolve the IBM15 test failures by updat
[
http://issues.apache.org/jira/browse/DERBY-2106?page=comments#action_12451828 ]
Daniel John Debrunner commented on DERBY-2106:
--
I'm trying to clear my thoughts on this issue. Forgetting about how XML values
are stored within Derby
[
http://issues.apache.org/jira/browse/DERBY-2106?page=comments#action_12451837 ]
A B commented on DERBY-2106:
> Just as confused as I was at the beginning. :-(
I think we took different routes but ended up at the same place. Thank you (a
ton) for
[
http://issues.apache.org/jira/browse/DERBY-1758?page=comments#action_12451844 ]
Daniel John Debrunner commented on DERBY-1758:
--
On the JAXP code source being null, I don't know the answer, but the real issue
is how does an applica
Kristian Waagan wrote:
Rick Hillegas wrote:
Hi Kristian,
I agree that we should stabilize the 10.2 tests soon since we're
planning a 10.2.2 release in early December. If we don't merge the
JUnit infrastructure into 10.2, then porting a bug fix to the 10.2
branch may involve re-writing the te
[
http://issues.apache.org/jira/browse/DERBY-1758?page=comments#action_12451843 ]
Daniel John Debrunner commented on DERBY-1758:
--
I think having the XML test/suite running even without a security manager is a
good step forward. As l
[ http://issues.apache.org/jira/browse/DERBY-1758?page=all ]
A B updated DERBY-1758:
---
Attachment: d1758_newSecMgr_doNotCommit.patch
While trying to add lang/XMLBindingTest.java to a JUnit suite so that it can
run as part of suites.All, I ran into a problem where
55 matches
Mail list logo
