I thought we had a JIRA issue logged about tracking improvements
to query plan output. Something along the lines of:
[snip]
I think you might be referring to DERBY-2487, does that sound right?
Army
Myrna van Lunteren wrote:
Giving Army the point since he came up with the fix.
I think you should give yourself 1/2 point for the testing and pushing
to completion...
+1!
In truth I think you could just assign it to yourself, as all I did was
suggest a code change that demonstrated
, and that in turn
reflects the join order chosen by the optimizer.
Army
-trivial.
So it seems like the easiest approach would be to follow Kathey's
suggestion, but make sure that all tests which use the new method pass
in a full list of all base table names in the query (not just a targeted
subset).
Army
in OptimizerImpl and print out the results of those
calls...?
Army
Rick Hillegas wrote:
DERBY-3023 fixes a bug in queries which mix INNER and OUTER joins.
Could we get a release note for this one?
I can try to write something up later tonight (PST),
Army
on the data).
But maybe that's the best way to go...
Army
. If for some reason such a change causes any
issues, the commit can be of course be reverted.
Thanks again,
Army
Army wrote:
I assume it's okay for this change to be checked into the codeline, so I
plan to commit it shortly.
Committed with svn # 634773:
URL: http://svn.apache.org/viewvc?rev=634773view=rev
Thanks again for the pointer, John.
Army
I've tried running ant javadoc on the trunk several times over the
past few days and have been unsuccessful every time. The process starts
okay, issues a bunch of javadoc warnings for the engine (there were 12
warnings the last I checked), then starts in on the derbyTesting
package. At that
Army wrote:
I've tried running ant javadoc on the trunk several times over the
past few days and have been unsuccessful every time.
When I run ant javadoc on the 10.3 branch it finishes in a minute or
two with no problems.
By the way, I have ant 1.6.5. Is that still an acceptable version
!
Army
this; if not, I guess I'll file a Jira for it...
Army
Rick Hillegas wrote:
Please vote on whether we should make Kim Haase a committer.
+1
Army
for DERBY-3299 are entirely language-layer, but perhaps it's
something that can be used here? Again, I don't really know since I
haven't been on top of this issue, but I thought I'd mention it...
Army
not an issue with the current set of upgrade tests...but I could of
course be mistaken...
Army
an oversight in the
testing for such flattening...but that would be a separate issue
altogether (not something you'd have to address for DERBY-3301).
Army
, ugly formatting, ...
Just a note that if you're looking for issues that fall into category
#3, DERBY-2034 is a good place to start, as it has a relatively
consolidated list. Whether or not any of those should block 10.4, I
don't know.
Army
earlier this week; I sent it in for repairs and will not get it
back for another 3-5 business days...
Army
that this approach is
not going to work, it would at least be good to understand more about
why--and maybe that'll provide pointers to an alternate approach, if
needed...
Army
.
You could perhaps change ref.pointsToColumnReference() in the above
code to account for OLAP-related functions like ROW_NUMBER(), but I do
not know off-hand if that would/could lead to problems down the road.
Might be worth a shot, though, to see what happens...
Does that help?
Army
=true) and things look good from what I can tell.
+1,
Army
Rick Hillegas wrote:
Please vote on whether we should make Øystein Grøvlen a committer. The
vote will close at 5:00 pm San Francisco time on Tuesday August 28.
+1
Army
you figure out where to trace while debugging, as well. If you
have any questions, please feel free to ask.
Army
/derbyTesting/functionTests/tests/lang/xmlTestFiles/personal.xsd,
Army
Army wrote:
Thanks for catching these, Jean. I'll try to take care of the following:
trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/AnsiTrimTest.java,
trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/xmlTestFiles/dtdDoc.xml,
trunk/java/testing/org
that satisfy
the query ... as the rows are retrieved should allow different results
when index and scan are used.
Thank you *very* much for investigating this, Jørgen! Both of your emails were
very helpful--and ultimately provided exactly the info that I was looking for.
Many many thanks!
Army
with Test. But I've changed it back to Bug
again. Thanks for the feedback.
Army
missing something obvious...
Army
on the underlying Derby scan type...
But for now this is a good enough answer. I don't think this blocks
DERBY-2805, it was just a question that came from investigation of that issue.
Thank you again to Mike and Knut Anders for the feedback; it's much appreciated!
Army
JDBC repro
Daniel John Debrunner wrote:
Myrna van Lunteren wrote:
mamta, army, dan, can you please verify your commits.
I reverted 545329 locally and the test still fails.
I reverted to 545320 (which is just before the commit for DERBY-2758) and
AuthenticationTest ran cleanly. I then sync'd
in the testInvalidXMLBindings()
method of lang/XMLBindingTest.java? I.e. are we adding this test case here for
collation purposes, or just as a general test case for XMLSERIALIZE?
Army
all that would be needed, though
I haven't actually tried it out...
Army
that junit/XML.java relies on the same class (org.apache.xpath.XPath) to
assume Xalan exists, as well. Hmm.
Army
of classes
that are only present in Sun jdks. That makes me a little uncomfortable...
Army
(to my knowledge...), so Derby has specific dependencies on
the Xalan package. Unlike Xerces, Xalan cannot be swapped out unless the Derby
code is itself changed.
Army
for tackling the release manager effort this time around!
Army
/gmane.comp.apache.db.derby.devel/40594/focus=40840
But do the other ones?
Army
a Jira, but I'm not real sure where the bug is.
Should the VALUES clause be throwing an error? Or should the CREATE TABLE AS
... WITH NO DATA functionality be responsible for checking the column
definition? Or is the problem someplace else entirely?
Army
guess a new Jira should be opened for this...?
Army
. If this proves to be an invalid assumption once
DERBY-2559 has been resolved, then I will of course work to rectify the situation :)
Running tests with DERBY-2488 now...
Army
reported in DERBY-2370,
which means existing applications are already going to be affected (in a good
way), I'm thinking this is the right way to go.
But I'm curious to know what others may think about this particular change in
behavior...comments/feedback?
Army
character string of [XMLSERIALIZE] will have the same collation as current
schema's character set. The collation derivation will be implicit.
Does that sound right?
Sorry if that's a tad off-topic...
Army
Mamta Satoor wrote:
Army, I just finished updating the wiki page to reflect the fact that the
result character string from XMLSERIALIZE will have the same collation as
current schema's character set. It is part of number 6 on the wiki page
under section Collation Determination.
Thanks Mamta
classpath and that should be it.
Army
Rick Hillegas wrote:
Thanks Army, Bryan, and Narayanan. I can now run the XML tests.
Good to hear!
I think this deserves being documented somewhere. Maybe under Running
Tests on the DerbyJUnitTesting wiki page? Is there a better place
for this advice?
I think the wiki would be helpful
Army wrote:
I think the wiki would be helpful, yes. It also might be helpful to
include these as javadoc comments somehow, perhaps for the
checkXalanVersion() method of junit/XML.java? Or maybe someplace else
that you looked when you yourself were trying to figure out why the
tests
Rick Hillegas wrote:
I like the idea of recording this advice in the javadoc too. Another
possibility would be to beef up the javadoc header for the XML class.
+1, works for me.
Army
worth investigating, though. Is this
something you might be looking at more? Either way, can you file a Jira for
tracking?
Army
Army wrote:
Since a parameter maker does not have a defined schema, does current
schema mean the schema when the statement is prepared, or the schema
when it is executed?
For example I can do the following in JDBC:
// Default schema (APP).
PreparedStatement ps = conn.prepareStatement
). That
consistency would probably be a good thing (less confusing for users).
Army
Daniel John Debrunner wrote:
I'm a little lost by this. What do these two terms mean to you?
run correctly
run without error
would only work if
run without error
Sorry for the confusion.
Army
Army wrote:
snip
Oops, clicked send too quickly on that last one. Will try this again once I
clarify the terminology in my head, then will post.
Daniel John Debrunner wrote:
I'm a little lost by this. What do these two terms mean to you?
run correctly
run without error
would
again,
Army
on DERBY-2487, or by
reviewing patches for other feature development currently happening in Derby.
Of course, this is just a suggestion, not a requirement :)
Thanks again,
Army
SQLSTATE
1. So I think this should have an explicit statement severity, as well.
I admit I don't really know much about severity actions, so I don't know if I've
answered your question or not...apologies for my ignorance here.
Army
has to include an XPath expression that compiles without error but
then throws a Xalan-produced execution time error. There is exactly one such
test today, and that's in XMLTypeAndOpsTest.textXMLQuery().
Army
along the way, (the fixup patch currently there is a bit
outdated).
Thanks!
Army
think Knut Anders just checked in an assertUnorderedResultSet() method this
morning for exactly that reason. So we're moving in the right direction...
Army
it as part of a nightly checkin.
Ah, okay. I agree that would be useful.
Army
.
Thank you for bringing this up!
Army
...
Army
will at that point have no effect on the test.
But in the interest of regression testing we still want to make sure the query
is run with optimizeJoinOrder=true (the default) as proof that DERBY-2500 is fixed.
Maybe something similar once existed for ruleBasedOptimization=true...?
*shrug*
Army
them to consider any of the ones linked
to DERBY-2034...
proverbial 2c,
Army
won't automatically delete the old canon from classes.
Thanks for the reply, Knut Anders. I think that was indeed the problem.
Army
from the above?
If that's too much to ask, no problem--you've already helped me a great deal by
looking at the diff and providing feedback. Just piqued my curiosity, that's all :)
Thank you again,
Army
Bryan Pendleton (JIRA) wrote:
Hi Army, just wanted to let you know that I've been reading your notes and
reading the patches.
Thank you very much, Bryan! I'm *really* glad to hear this--it's good to know
someone else is at least sanity-checking the notes and changes. More eyes the
better
sure, probably fine or no, probably a bad thing, then I
encourage him/her/them to speak up. It's a tiny patch so review should be quick...
Army
this particular problem? If you're expecting an empty result set then
when you drain it you should get 0 rows, so wouldn't this be an appropriate check?
Army
Army wrote:
Would
JDBC.assertDrainResults(rs, 0);
solve this particular problem? If you're expecting an empty result set
then when you drain it you should get 0 rows, so wouldn't this be an
appropriate check?
Oh, and I just noticed there's also:
JDBC.assertEmpty(rs);
which does
...
Thank you for taking the time to work on this project, and for your willingness
to contribute back to the community. I look forward to using your contributions
in the near future!
Army
+ ';
}
-private static Test suite() {
+public static Test suite() {
return TestConfiguration.defaultSuite(CastingTest.class);
So that's what I did with svn #513573
Please feel free to revert or otherwise change if that was wrong...
Army
, but it was so unexpected (to me anyways)
that I thought I'd mention it.
Feel free to ignore.
Army
: a magazine article about Derby on page 7, and that was about it. No
reference to the Derby home page that I could see.
So my guess is that adding open source to the Derby home pages isn't going to
help much. Which is too bad, 'cause that would have been easy... ;)
Army
? If not, I'd like to commit
d47_relOpPredCheck_v1.patch to trunk and proceed from there...
Thanks again for the feedback!
Army
Jean T. Anderson wrote:
As required by the ASF ip-clearance process in the Incubator [1],
please vote to accept the NetworkServer system tests contributed by IBM
that are attached to the following Jira issue:
+1
Army
Manjula Kutty wrote:
Can any one please review the patch attached to
http://issues.apache.org/jira/browse/DERBY-2249. A long running test for
optimizer.
I will try to look at this before the end of the week.
Army
this matter? If I create the database with 10.2 and then connect from
the latest 10.3 the describe command works as expected. So maybe this is just a
side-effect from working on the development branch and there's nothing more to
worry about...?
Just curious,
Army
Steps to reproduce
and Dan for your replies!
Army
Bryan Pendleton wrote:
If anyone can spare some time to review my proposals for
DERBY-1861, I'd be grateful.
I'll try to review this early next week. Anyone who can reviewier it earlier
than that should of course feel free to do so, as well :)
Army
the theory could be wrong).
I think Knut Anders made some good observations regarding the predicatePushdown
failure; see his comments on DERBY-1902. If anyone knows the answers to the
questions he posted there (I don't), that might be a good place to start...
Army
than answers, so my apologies for lack
of helpful information. Unfortunately, the particular area of the optimizer
with which you are working (preprocessing and/or rewrite) is one that is still
relatively unexplored for me...
Army
(...)
bindVTITables(...)
bindExpressions(...)
See DMLStatementNode.bind(). So would it be possible to make those calls on the
SelectNode in question?
Army
if-block angle for the sake of addressing the performance
regression seen between 10.1 and 10.2. I.e. to specifically address the 10.2
slowdown filed as DERBY-2130.
Army
at the moment to pursue those changes and will not be able to until at
least next year...
Army
against the 10.2.2 candidate jars--and all JUnit
XML tests passed (I used ibm142).
So I vote +1 for the 10.2.2 candidate from an ODBC and XML perspective.
Army
[1] The xmlSuite suite is not currently run as part of derbyall for 10.2,
thus one must run the XML tests explicitly (after
the description again and see if anything else comes to mind.
Thank you for filing the issue and for your interest in resolving it.
Army
PS. I ran the repro on my laptop with a bunch of apps running in the
background, and it took a full 35 minutes to complete. It *did* complete,
though, which rules
interest in the optimizer!
Army
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
across platforms.
Any additional thoughts/suggestions/corrections?
Thanks to Dan, Jean, and Bryan for taking the time to reply thus far...
Army
.
Thanks,
Army
[1]
I searched Jira for this and found a couple of relevant Xalan issues, especially
XALANJ-2093 and XALANJ-1701. There is apparently a new property introduced in
Xalan 2.7 to allow the user to indicate what should happen with newlines, but
that property is non-standard
it. But the serialization itself seems like something to
address...or at least, something on which we agree to not address.
Army
kind of workaround to
address the issue as it pertains to the SQL/XML operators.
Good information to have, though; thanks again for the pointers. I feel better
having confirmation that this is a Xalan problem. Now we just have to figure
out what, if anything, to do about it...
Army
worth looking into more.
#1 is just an inquiry and should *not* be seen as a reason to block #2. As I
said, this was just the first question that came to me when I read your email,
so I thought I'd share it...
Army
Jean T. Anderson wrote:
Please vote +1 if you approve of Laura as a committer.
+1
Army
what comes of your work...
Army
Andrew McIntyre wrote:
Please vote +1 if you approve of Myrna as a committer.
+1
Army
Mike Matrigali wrote:
Please vote +1 if you approve of Mamta as a committer.
+1
Army
that we allow some functions in a GROUP BY clause but not others, I
think that's probably something worth including in whatever documentation is
written for DERBY-883. Assuming, of course, that I'm not just missing something
obvious.
Sorry if I'm being dense here...
Army
for a DERBY-1758 patch. I had a several other apps running on my machine
at the time (some of which require a lot of memory) so I just figured it was a
glitch...
Army
1 - 100 of 339 matches
Mail list logo
