Re: [jira] Updated: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network conf

[Satheesh Bandaram]

Thanks for contributing the test. It does need some time to make it work on Derby by modifying some of the items I mentioned earlier. Also need to setup users referenced in the test and enable authentication. I am not sure when I will be able to get to this.
I did work on getting nist suite to pass with SQL authorization enabled. Once I confirm test changes I made, I will submit that.Satheesh
On 3/28/06, Michelle Caisse (JIRA)  wrote:
 [ http://issues.apache.org/jira/browse/DERBY-464?page=all ]Michelle Caisse updated DERBY-464:--
Attachment: Privileges2.javaThis attachment, Privileges2.java supercedes the previous one.  It contains the Apache license test.  My management at Sun Microsystems has authorized me to donated this code to Apache Derby. It will need substantial rework for use with Derby outside of the test framework for which it was written.  I hope that it is useful.
> Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations.> ---
>>  Key: DERBY-464>  URL: http://issues.apache.org/jira/browse/DERBY-464>  Project: Derby> Type: New Feature
>   Components: SQL> Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0>  Environment: generic> Reporter: Satheesh Bandaram
> Assignee: Satheesh Bandaram>  Attachments: GrantRevokePartII.stat, GrantRevokePartII.txt, GrantRevokePartII.txt, Privileges.java, Privileges2.java, changeDescriptionPartII, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5
, grantRevokeSpec.html, grantRevokeSpec_v2.html>> Derby currently provides a very simple permissions scheme, which is quite suitable for an embedded database system. End users of embedded Derby do not see Derby directly; they talk to a application that embeds Derby. So Derby left most of the access control work to the application. Under this scheme, Derby limits access on a per database or per system basis. A user can be granted full, read-only, or no access.
> This is less suitable in a general purpose SQL server. When end users or diverse applications can issue SQL commands directly against the database, Derby must provide more precise mechanisms to limit who can do what with the database.
> I propose to enhance Derby by implementing a subset of grant/revoke capabilities as specified by the SQL standard. I envision this work to involve the following tasks, at least:> 1) Develop a specification of what capabilities I would like to add to Derby.
> 2) Provide a high level implementation scheme.> 3) Pursue a staged development plan, with support for DDL added to Derby first.> 4) Add support for runtime checking of these privileges.> 5) Address migration and upgrade issues from previous releases and from old scheme to newer database.
> Since I think this is a large task, I would like to invite any interested people to work with me on this large and important enhancement to Derby.--This message is automatically generated by JIRA.
-If you think it was sent incorrectly contact one of the administrators:   http://issues.apache.org/jira/secure/Administrators.jspa-For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Satheesh Bandaram]

David W. Van Couvering wrote:

>
> If we want to also provide a guarantee that any feature will not be
> broken for five years, that's OK, but I think it would be odd to break
> compatibility in a minor release just because it's been five years...
>
> Or am I not fully understanding your proposal, Kathey?
>
I think Kathey probably meant compatibility should be maintained for a
specific amount of time AND can only be broken in a major release.

Satheesh

> David
>
> Kathey Marsden wrote:
>
>> Rick Hillegas wrote:
>>
>>
>>> I think you may have already addressed the following issues in email,
>>> but I don't see the results rolled onto the wiki page. Please pardon
>>> my nitpicking. This kind of discussion turns me into a tiresome,
>>> pedantic Mr. Hyde:
>>>
>>> 1) The cardinal rule. I recommend wordsmithing the cardinal rule: "The
>>> goal is to allow any application written against the public interfaces
>>> an older version of Derby can run, without any changes, against a
>>> newer version of Derby." To me the following formulation reads better
>>> "This is our goal: An application which ran against Derby yesterday
>>> will run against a higher version of Derby tomorrow."
>>>
>>
>> I prefer the original wording with only a small grammatical change to
>> instead of can.
>>
>> "The goal is to allow any application written against the public
>> interfaces an older version of Derby to run, without any changes,
>> against a newer version of Derby."
>>
>> It is good to think past tomorrow.
>>
>>
>>> But is that really the cardinal rule? Maybe we really mean this: "This
>>> is our goal: An application which runs against a Derby release today
>>> will also run tomorrow against the next minor release. 
>>
>>
>>
>> I  do not like this wording .It might seem to imply that you cannot
>> skip minor releases e.g. go from 10.l  to 10.3.
>> It might also seem to imply that you cannot  run a 10.1 client with a
>> 10.3 server for example. 
>>
>>> We strive to minimize churn for applications migrating to the next
>>> major release of Derby. However these migrations may entail
>>> application changes."
>>>
>>
>> The way  major releases are described in this mail is the way I have
>> seen them  in the past,  where we break upgrade,  client/server
>> compatibility and many other things  and it is like switching to a new
>> product, but I want better for the users of  Derby 10 when they switch
>> to 11.
>>
>> I still need to think a lot about the whole major version boundary
>> thing.  It seems like we like solaris will be set at the same major
>> version for a very long time.   As I stated before I think for some
>> things a time based approach seems most appropriate. You can expect your
>> client to work with new servers for the next five years for example. We
>> should  not just leave users trying to figure out how to upgrade  their
>> server and all of their clients all in one night because we  bumped from
>> 10 to 11.
>> If we expect upgrade=true to work from 10 to 11 we should expect
>> client/server compatibility to be maintained as well.
>> So either the time based approach or for major versions  have
>> compatibility with the previous and next  major versions.For example
>> with Derby 11 you can use Derby 10 or Derby 12, but not Derby 13.
>>
>>
>>> 2b) Our DRDA implementation may incorrectly transport datatypes not
>>> recognized by DRDA. Conforming to the DRDA spec may mean removing this
>>> transport capability and breaking applications which select the
>>> unsupported datatypes.
>>>
>>
>> Protocol has an impact on client JDBC, SQL  and even the ability to
>> connect and those cannot be broken.
>> Client and server can have version dependent behaviour to mitigate the
>> change to DRDA compliant behavior.
>>
>>
>>
>>> 3) Client/server compatibility.
>>>
>>> I would expect to find these rules spelled out on the wiki page. 
>>
>>
>>
>>
>>
>> Yes I agree these should be spelled out because obviously different
>> readers can deduce different things.
>>
>>
>>
>
>
>

Re: code coverage results for trunk - svn revision no 390306

[Ramandeep Kaur]

Hi David,
 
That is good idea. I will look into it. I am taking time off for about 2 weeks. Will propose some solution on this thread once I am back. 
 
-- Ramandeep Kaur[EMAIL PROTECTED]  
On 3/31/06, Andrew McIntyre <[EMAIL PROTECTED]> wrote:
On 3/31/06, Ramandeep Kaur <[EMAIL PROTECTED]> wrote:
> The zip file CodeCoverageResults_svn390306.zip with code> coverage results will be posted soon on> http://people.apache.org/~fuzzylogic/  (Thanks to Andrew).
Now visible at:http://people.apache.org/~fuzzylogic/codecoverage/390306/andrew

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Jeff Levitt]

P.S. David, I read my original reply and even I didn't
understand it!  I think my latest response is slightly
more clear  Sorry all,
Jeff

--- "David W. Van Couvering"
<[EMAIL PROTECTED]> wrote:

> Hi, Jeff.  I've been quiet on this comment because I
> didn't fully 
> understand it.
> 
> I *think* what you're saying is that an interface
> can not be considered 
> Stable or Unstable unless it's actually documented. 
> Is that right?
> 
> David
> 
> Jeff Levitt wrote:
> > From a documentation perspective, I think if we
> are
> > going to say on this page that items are stable AS
> > DOCUMENTED in the user documentation, then we also
> > need to put in some sort of requirement on this
> page
> > that says any changes made to the stability of an
> item
> > MUST be documented as well in order to be
> committed an
> > considered stable.  Its not stable if its not
> > documented and we are telling people that it is
> stable
> > as documented.  Agreed?
> > 
> > I think this is something that would be good to
> put in
> > to make sure that developers understand the
> importance
> > of documenting their work, whether its something
> new
> > or a change to something that exists, and that its
> not
> > just going to magically show up in the
> documentation
> > if they put it in the code (unless its javadoc) :)
> > 
> > --- "David W. Van Couvering"
> > <[EMAIL PROTECTED]> wrote:
> > 
> > 
> >>Thanks for your comments, Kathey, and yes, it can
> >>definitely wait a 
> >>week.  It was just so quiet that I thought I'd do
> a
> >>"ping" and see if 
> >>there was more to come from everyone.
> >>
> >>Responses below...
> >>
> >>Kathey Marsden wrote:
> >>
> >>>I wish I had more time to look at this but  I 
> >>
> >>think that  I would add
> >>
> >>>these things.
> >>> -  In general any documented behaviour is a
> >>
> >>stable interface, unless
> >>
> >>>specifically documented  here or in the
> >>
> >>documentation as unstable.
> >>
> >>I'm not sure how to handle this.  What does it
> mean
> >>to "incompatibly 
> >>change" documented behavior?
> >>
> >>Usually the behavior is in relation to a given
> >>interface.  So perhaps in 
> >>our definition of what it means to incompatibly
> >>change an interface 
> >>means you can't change the documented behavior of
> >>that interface (e.g. 
> >>the "contract" of that interface).
> >>
> >>I think it's also fair to say that unless
> explicitly
> >>called out in the 
> >>table as otherwise, one can assume a publicly
> >>documented interface is 
> >>Stable.
> >>
> >>
> >>>-   Derby will at a minimum negotiate down to the
> >>
> >>lower interface
> >>
> >>>revision level:
> >>>-   When different versions of Derby client
> >>
> >>and server are used
> >>
> >>>together (in the same or different JVM's)
> >>>-  When different jvm versions are used on
> >>
> >>client and server.
> >>
> >>I think this is a solution that provides a
> guarantee
> >>of stability to the 
> >>client/server interfaces.  I can add this as a
> note,
> >>however.
> >>
> >>I think by calling out the *specific* interfaces
> >>that the client depends 
> >>upon (DRDA, metadata procedures, system stored
> >>procedures, ???) and 
> >>marking them as Stable or Private Stable is a
> Really
> >>Good Idea in our 
> >>attempts to provide the guarantee of client/server
> >>compatiblity.  Note, 
> >>for example, some of us newbies changing the
> >>metadata procedures willy 
> >>nilly because we were unaware of the impact on
> >>compatibility.  Having 
> >>these called out will make us all more conscious
> of
> >>what we can and 
> >>can't do within the system.
> >>
> >>
> >>>In the interface table I would add:
> >>>- Defaults returned by DatabaseMetaData methods  
> 
> >>
> >>   Stable
> >>
> >>>- Documented  defaults   
> 
> >>
> >>
> >>
> >>>Stable
> >>>- console output format for tools and network
> >>
> >>server  Unstable
> >>
> >>>- System stored procedures   
> 
> >>
> >> Stable
> >>
> >>OK, I'll add these.  I think the console output
> >>format for tools and 
> >>server should actually be marked Private -- it's
> not
> >>documented in the 
> >>user documentation, and can change at any time.
> >>
> >>Dumb question: are system stored procedures in the
> >>user documentation? 
> >>If not, perhaps they should be Private Stable
> rather
> >>than Stable?  If 
> >>they're not documented, what is driving the
> >>requirement that they be 
> >>stable - client/server compatibility?
> >>
> >>
> >>>Under notes  It would be good to mention:
> >>>
> >>>   .
> >>>
> >>
> >>OK
> >>
> >>
> >>
> >>>Could we wait a week for a vote?I think I
> need
> >>
> >>to study this some more.
> >>
> >>>Thanks David for doing this.
> >>>
> >>
> >>Yes, sure, and you're welcome.
> >>
> >>David
> >>
> >>
> >>>Kathey
> >>>
> >>>
> >>
> > 
> 

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Jeff Levitt]

Hi David,

Yes I thinnk thats what I'm trying to say.  Of course
something can be implemented and not documented, or
the other way around, but my sense is that we are
trying to make acontract here for ourselves, and with
our users, and I think that if part of that contract
is to tell our users that what they see in the doc is
fact, then we should strive to always make that true. 
That means a new contribution would not be accepted
unless it included corresponding documentation.  If we
add a new function then either a patch to the DITA
source referencing that function is included, or at
the very least a full function spec is submitted so
that documentation can be written by someone else.

The bottom line would be that documentation would be
considered as important as codeline itself; quality
considerations would include documentation, just as
proper code consistency and standards are required.

Most contributors are not documentation specialists,
so maybe it is too much to ask, but I think if we are
telling users to accept the doc as the final word,
then we need to have some sort of MINIMUM doc
contribution requirement.  What do other people think?

--- "David W. Van Couvering"
<[EMAIL PROTECTED]> wrote:

> Hi, Jeff.  I've been quiet on this comment because I
> didn't fully 
> understand it.
> 
> I *think* what you're saying is that an interface
> can not be considered 
> Stable or Unstable unless it's actually documented. 
> Is that right?
> 
> David
> 
> Jeff Levitt wrote:
> > From a documentation perspective, I think if we
> are
> > going to say on this page that items are stable AS
> > DOCUMENTED in the user documentation, then we also
> > need to put in some sort of requirement on this
> page
> > that says any changes made to the stability of an
> item
> > MUST be documented as well in order to be
> committed an
> > considered stable.  Its not stable if its not
> > documented and we are telling people that it is
> stable
> > as documented.  Agreed?
> > 
> > I think this is something that would be good to
> put in
> > to make sure that developers understand the
> importance
> > of documenting their work, whether its something
> new
> > or a change to something that exists, and that its
> not
> > just going to magically show up in the
> documentation
> > if they put it in the code (unless its javadoc) :)
> > 
> > --- "David W. Van Couvering"
> > <[EMAIL PROTECTED]> wrote:
> > 
> > 
> >>Thanks for your comments, Kathey, and yes, it can
> >>definitely wait a 
> >>week.  It was just so quiet that I thought I'd do
> a
> >>"ping" and see if 
> >>there was more to come from everyone.
> >>
> >>Responses below...
> >>
> >>Kathey Marsden wrote:
> >>
> >>>I wish I had more time to look at this but  I 
> >>
> >>think that  I would add
> >>
> >>>these things.
> >>> -  In general any documented behaviour is a
> >>
> >>stable interface, unless
> >>
> >>>specifically documented  here or in the
> >>
> >>documentation as unstable.
> >>
> >>I'm not sure how to handle this.  What does it
> mean
> >>to "incompatibly 
> >>change" documented behavior?
> >>
> >>Usually the behavior is in relation to a given
> >>interface.  So perhaps in 
> >>our definition of what it means to incompatibly
> >>change an interface 
> >>means you can't change the documented behavior of
> >>that interface (e.g. 
> >>the "contract" of that interface).
> >>
> >>I think it's also fair to say that unless
> explicitly
> >>called out in the 
> >>table as otherwise, one can assume a publicly
> >>documented interface is 
> >>Stable.
> >>
> >>
> >>>-   Derby will at a minimum negotiate down to the
> >>
> >>lower interface
> >>
> >>>revision level:
> >>>-   When different versions of Derby client
> >>
> >>and server are used
> >>
> >>>together (in the same or different JVM's)
> >>>-  When different jvm versions are used on
> >>
> >>client and server.
> >>
> >>I think this is a solution that provides a
> guarantee
> >>of stability to the 
> >>client/server interfaces.  I can add this as a
> note,
> >>however.
> >>
> >>I think by calling out the *specific* interfaces
> >>that the client depends 
> >>upon (DRDA, metadata procedures, system stored
> >>procedures, ???) and 
> >>marking them as Stable or Private Stable is a
> Really
> >>Good Idea in our 
> >>attempts to provide the guarantee of client/server
> >>compatiblity.  Note, 
> >>for example, some of us newbies changing the
> >>metadata procedures willy 
> >>nilly because we were unaware of the impact on
> >>compatibility.  Having 
> >>these called out will make us all more conscious
> of
> >>what we can and 
> >>can't do within the system.
> >>
> >>
> >>>In the interface table I would add:
> >>>- Defaults returned by DatabaseMetaData methods  
> 
> >>
> >>   Stable
> >>
> >>>- Documented  defaults   
> 
> >>
> >>
> >>
> >>>Stable
> >>>- console output format for tools and network
> >>
> >>server  Unstable
> >>
> >>>- System stored procedures

[jira] Commented: (DERBY-1163) Add jdbc4.0 implementation of EmbedPooledConnection and EmbedXAConnection

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1163?page=comments#action_12372751 ] 

Rick Hillegas commented on DERBY-1163:
--

Looks good. The jdbc4 tests pass. Derbyall has the usual errors: wisconsin, 
sysinfo, and sysinfo_withproperties.

> Add jdbc4.0 implementation of EmbedPooledConnection and EmbedXAConnection
> -
>
>  Key: DERBY-1163
>  URL: http://issues.apache.org/jira/browse/DERBY-1163
>  Project: Derby
> Type: New Feature
>  Environment: jdk1.6, jdbc4.0
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
>  Fix For: 10.2.0.0
>  Attachments: derby-1163.diff, derby-1163_2.diff
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: ColumnMetaData methods not in use - would like to comment out

[Satheesh Bandaram]

I vote for removing this dead code. Probably was created during
development and didn't really get used in the final version. Dead code
like this makes maintaining product little harder, confuse developers
and reduces our code coverage numbers. :-)

Satheesh

David W. Van Couvering wrote:

> Oh, two more:
>
> private void guessParameterMetaDataBasedOnSupportedDriverType(int,
> boolean, int, int)
> guessParameterMetaData(int, int, int, int, int) (only called by the
> method above)
>
> Thanks,
>
> David
>
> David W. Van Couvering wrote:
>
>> There are some methods in client.am.ColumnMetaData.java that are not
>> being used at all right now, and rather than internationalize their
>> messages, which are somewhat odd, I'd rather comment them out.
>>
>> They are
>>
>> void guessInputParameterMetaData(int, int)
>> void guessInputParameterMetaData(int, int, int)
>> void guessOutputParameterMetaData(int, int, int)
>>
>> I double-checked -- they are not in our documented APIs, and these
>> methods are not part of java.sql.ResultSetMetaData, which this class
>> implements.
>>
>> Anyone object?
>>
>> David
>>
>
>
>

[jira] Commented: (DERBY-1139) Division operator may give wrong results with NUMERIC operands

[Satheesh Bandaram (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1139?page=comments#action_12372750 ] 

Satheesh Bandaram commented on DERBY-1139:
--

Thanks Andrew for the link... I looked at Derby documentation. Based on what I 
find here, Derby may be doing the right thing, just the comments in the code 
may need to be changed.

Matthias, can you follow up on DECIMAL/NUMERIC arithmetic discussion in Derby 
reference guide and may be try adjusting your datatype precision and scale?

Scale for decimal arithmetic
---
SQL statements can involve arithmetic expressions that use decimal data types of
different precisions (the total number of digits, both to the left and to the 
right of the
decimal point) and scales (the number of digits of the fractional component). 
The
precision and scale of the resulting decimal type depend on the precision and 
scale of the
operands.
Given an arithmetic expression that involves two decimal operands:
• lp stands for the precision of the left operand
• rp stands for the precision of the right operand
• ls stands for the scale of the left operand
• rs stands for the scale of the right operand
Use the following formulas to determine the scale of the resulting data type 
for the
following kinds of arithmetical expressions:
• multiplication
ls + rs
• division
31 - lp + ls - rs
• AVG()
max(max(ls, rs), 4)
• all others
max(ls, rs)

> Division operator may give wrong results with NUMERIC operands
> --
>
>  Key: DERBY-1139
>  URL: http://issues.apache.org/jira/browse/DERBY-1139
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.1.2.1
> Reporter: Matthias Ohlemeyer
> Priority: Critical

>
> The division operator '/' may give wrong results when used with NUMRERIC 
> operands.
> Example (copied from ij):
> CREATE TABLE t (d1 DOUBLE, d2 DOUBLE, n1 NUMERIC(31,11), n2
> NUMERIC(31,11));
> INSERT INTO t VALUES (1.5, 2.5, 1.5, 2.5);
> SELECT d1/d2, n1/n2, n1*(1.0/n2) FROM t;
> 1   |2 |3
> 
> 0.6 |0 |0.60
> 1 row selected
> The result in column 2 should not be zero, but 0.6.
> It seems there is something wrong with the calculation of the scale. Hint 
> from Satheesh Bandaram:
> If you look at NumericTypeCompiler code, which calculates the scale and 
> precision of operation result type, the comments and the code doesn't seem to 
> match. (getScale() method):
> NumericTypeCompiler.java
> else if (TypeCompiler.DIVIDE_OP.equals(operator))
> {
> /*
> ** Take max left scale + right precision - right scale + 1,
> ** or 4, whichever is biggest
> */
> LanguageConnectionContext lcc = (LanguageConnectionContext)
> 
> (ContextService.getContext(LanguageConnectionContext.CONTEXT_ID));
> // Scale: 31 - left precision + left scale - right scale
> val = Math.max(NumberDataValue.MAX_DECIMAL_PRECISION_SCALE - 
> lprec + lscale - rscale, 0);
> }
> Here val is returning zero for scale, it seems.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[ optimizer ] Some questions on optimization cost estimates?

[Army]

While trying to complete the Phase 4 work for DERBY-805 I've come across some 
behavior in the optimizer's treatment of cost estimates that I don't fully 
understand.  If anyone out there can offer answers/feedback for any of the 
following three questions, I'd appreciate it...



1) Multiplication by outer rows.


There are four classes--ProjectRestrictNode, UnionNode, JoinNode, and 
FromTable--that implement the "optimizeIt()" method and, in that method, call 
"getJoinStrategy().estimateCost(...)".  One of the arguments to optimizeIt() is 
an outerCost value which holds the estimated cost for FromTables left of the 
current one for this join order.  So if we have a FROM list that is [ FT1, FT2, 
FT3 ] and the current FromTable (the one we're optimizing) is FT2, then 
outerCost will hold the estimated cost for FT1.  For the sake of this question, 
assume FT1, FT2, and FT3 are instances of one of the above-mentioned classes. 
outerCost is then used in two ways by these FTs: a) it's passed down to the 
children nodes, where it's factored into the cost estimates of those children, 
and b) it's passed into a call to estimate the cost of the current FT itself. 
As an example, take UnionNode.  The a) code is like this:


leftResultSet = optimizeSource(
optimizer,
leftResultSet,
getLeftOptPredicateList(),
outerCost);  // <==

rightResultSet = optimizeSource(
optimizer,
rightResultSet,
getRightOptPredicateList(),
outerCost);  // <==

The b) code is then:

/*
** Get the cost of this result set in the context of the whole plan.
*/
getCurrentAccessPath().
getJoinStrategy().
estimateCost(
this,
predList,
(ConglomerateDescriptor) null,
outerCost,   // <==
optimizer,
costEstimate
);

In both cases, the only part of outerCost that's actually used is the estimated 
row count.  In cases where we're costing a Nested Loop Join (either for the 
current FT or for any of it's children), we multiply the cost of the current FT 
(or its children) by the number of outer rows, since we will in effect be 
incurring the cost of the inner FT for each row of the outer FT.


All of that said, my question is this: why do we need to pass the outerCost down 
to the children, where it will be multiplied by their costs, AND at the same 
time pass it into the "getJoinStrategy().estimateCost()" method, where it will 
be multiplied (again) by the cost of the current FT?  It seems to me the like 
the correct thing to do here is to _not_ pass outerCost to the children and to 
instead just let the current FT do the multiplication if necessary.


As a trivialized example, assume our FT2 is a UnionNode over two subqueries, 
each of which just has a single table:


FT2 = (select * from T1) UNION (select * from T2)

And assume FT1 is an outer table with row count of 100.  Then in the part a) 
code above, we'll pass "100" down to the left child, where it will eventually 
make it down to T1 and we'll multiply the cost of T1 by 100.  Likewise we'll 
pass "100" down to the right child and multiply the cost of T2 by 100:


T1 estimated cost: 100 * T1_cost
T2 estimated cost: 100 * T2_cost

Then we'll set the cost of the UnionNode to be the sum of the estimated costs of 
its children:


FT2 estimated cost: (100 * T1_cost) + (100 * T2_cost)

That done, if the current join strategy for FT2 is NestedLoop, the call in part 
b) above will pass "100" to NestedLoopJoinStrategy.estimateCost(), where it will 
be multiplied by the cost of FT2:


FT2 estimatedCost: 100 * ((100 * T1_cost) + (100 * T2_cost))

In other words, we've ended up multiplying the cost of FT2 by the outer row 
count *TWICE*.


I guess this could be intentional in order to make sure we favor hash joins 
(which won't do the second multiplication--see below) over nested loop joins, 
but it'd be great if someone could confirm this one way or the other.  As it is, 
it seems a bit odd to me.


--
2) HashJoinStrategy.estimateCost()
--

As mentioned at the end of question 1, if the join strategy that we're currently 
costing is a HashJoin and we make a call to HashJoinStrategy.estimateCost() (see 
above for an example), we get here:


/** @see JoinStrategy#estimateCost */
public void estimateCost(Optimizable innerTable,
 OptimizablePredicateList predList,
 ConglomerateDescri

Re: ColumnMetaData methods not in use - would like to comment out

[David W. Van Couvering]

Oh, two more:

private void guessParameterMetaDataBasedOnSupportedDriverType(int, 
boolean, int, int)
guessParameterMetaData(int, int, int, int, int) (only called by the 
method above)


Thanks,

David

David W. Van Couvering wrote:
There are some methods in client.am.ColumnMetaData.java that are not 
being used at all right now, and rather than internationalize their 
messages, which are somewhat odd, I'd rather comment them out.


They are

void guessInputParameterMetaData(int, int)
void guessInputParameterMetaData(int, int, int)
void guessOutputParameterMetaData(int, int, int)

I double-checked -- they are not in our documented APIs, and these 
methods are not part of java.sql.ResultSetMetaData, which this class 
implements.


Anyone object?

David

ColumnMetaData methods not in use - would like to comment out

[David W. Van Couvering]

There are some methods in client.am.ColumnMetaData.java that are not 
being used at all right now, and rather than internationalize their 
messages, which are somewhat odd, I'd rather comment them out.


They are

void guessInputParameterMetaData(int, int)
void guessInputParameterMetaData(int, int, int)
void guessOutputParameterMetaData(int, int, int)

I double-checked -- they are not in our documented APIs, and these 
methods are not part of java.sql.ResultSetMetaData, which this class 
implements.


Anyone object?

David

Re: code coverage results for trunk - svn revision no 390306

[Andrew McIntyre]

On 3/31/06, Ramandeep Kaur <[EMAIL PROTECTED]> wrote:
> The zip file CodeCoverageResults_svn390306.zip with code
> coverage results will be posted soon on
> http://people.apache.org/~fuzzylogic/  (Thanks to Andrew).

Now visible at:

http://people.apache.org/~fuzzylogic/codecoverage/390306/

andrew

[jira] Commented: (DERBY-1139) Division operator may give wrong results with NUMERIC operands

[Andrew McIntyre (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1139?page=comments#action_12372742 ] 

Andrew McIntyre commented on DERBY-1139:


Satheesh, based on the comment shouldn't this be changed to: 

val = Math.max(NumberDataValue.MAX_DECIMAL_PRECISION_SCALE - lprec + lscale - 
rscale, 4);

FWIW, the algorithm that DB2 uses is described here: 

http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2.doc.sqlref/bjnrmstr156.htm

> Division operator may give wrong results with NUMERIC operands
> --
>
>  Key: DERBY-1139
>  URL: http://issues.apache.org/jira/browse/DERBY-1139
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.1.2.1
> Reporter: Matthias Ohlemeyer
> Priority: Critical

>
> The division operator '/' may give wrong results when used with NUMRERIC 
> operands.
> Example (copied from ij):
> CREATE TABLE t (d1 DOUBLE, d2 DOUBLE, n1 NUMERIC(31,11), n2
> NUMERIC(31,11));
> INSERT INTO t VALUES (1.5, 2.5, 1.5, 2.5);
> SELECT d1/d2, n1/n2, n1*(1.0/n2) FROM t;
> 1   |2 |3
> 
> 0.6 |0 |0.60
> 1 row selected
> The result in column 2 should not be zero, but 0.6.
> It seems there is something wrong with the calculation of the scale. Hint 
> from Satheesh Bandaram:
> If you look at NumericTypeCompiler code, which calculates the scale and 
> precision of operation result type, the comments and the code doesn't seem to 
> match. (getScale() method):
> NumericTypeCompiler.java
> else if (TypeCompiler.DIVIDE_OP.equals(operator))
> {
> /*
> ** Take max left scale + right precision - right scale + 1,
> ** or 4, whichever is biggest
> */
> LanguageConnectionContext lcc = (LanguageConnectionContext)
> 
> (ContextService.getContext(LanguageConnectionContext.CONTEXT_ID));
> // Scale: 31 - left precision + left scale - right scale
> val = Math.max(NumberDataValue.MAX_DECIMAL_PRECISION_SCALE - 
> lprec + lscale - rscale, 0);
> }
> Here val is returning zero for scale, it seems.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: code coverage results for trunk - svn revision no 390306

[David W. Van Couvering]

Thanks, Raman.

Did I ask this before?  Do we want to agree upon a "low water mark" for 
code coverage and send out a "Quality Regression" email if our testing 
coverage falls below that mark?  I think this would have a lot of value.


David

Ramandeep Kaur wrote:

Hi  All,
 
I ran code coverage for trunk - svn revision no 390306 with sun jdk131, 
sun jdk142, sun jdk15 on Windows 2000, and results are as following:-
 


*OVERALL COVERAGE SUMMARY*

Classes: 91%  (1122/1232)
Methods: 75%  (15585/20815)
Blocks: 73%  (484308/663784)
Lines: 73%  (99030.4/136438)

*OVERALL STATS SUMMARY*

total packages: 80
total executable files: 1175
total classes: 1232
total methods: 20815
total executable lines: 136438

The zip file CodeCoverageResults_svn390306.zip with code coverage 
results will be posted soon on http://people.apache.org/~fuzzylogic/ 
 (Thanks to Andrew).


--
Ramandeep Kaur
[EMAIL PROTECTED] 

code coverage results for trunk - svn revision no 390306

[Ramandeep Kaur]

Hi  All,
 
I ran code coverage for trunk - svn revision no 390306 with sun jdk131, sun jdk142, sun jdk15 on Windows 2000, and results are as following:-

 

OVERALL COVERAGE SUMMARY
Classes: 91%  (1122/1232) Methods: 75%  (15585/20815) Blocks: 73%  (484308/663784) Lines: 73%  (99030.4/136438) 
OVERALL STATS SUMMARY

total packages: 80 total executable files: 1175 total classes: 1232 total methods: 20815 total executable lines: 136438 
The zip file CodeCoverageResults_svn390306.zip with code coverage
 results will be posted soon on http://people.apache.org/~fuzzylogic/  (Thanks to Andrew).
-- Ramandeep Kaur[EMAIL PROTECTED] 

Re: pushing back release date for jdbc4-capable Derby

[Ramandeep Kaur]

+1for bothRamandeep Kaur[EMAIL PROTECTED] 

Java DB now available

[David W. Van Couvering]

Good news for Apache Derby - another Big Company has gotten behind Derby 
and is providing support for it.  Sun's Java DB is now officially 
available for download at


  http://www.sun.com/download/products.xml?id=44244f49

Java DB's "home" can be found at

  http://developers.sun.com/prodtech/javadb

Also, the article talking about how to use Java DB in the desktop got 
top billing at http://java.sun.com


  http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javadb/

Disclaimer: if you hadn't noticed by my email address and my enthusiasm 
for Java DB, I work for Sun :)

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[David W. Van Couvering]

Hi, John, thanks for reviewing this.

I agree "Private Unstable" sounds more unstable than "Private."  I don't 
know if we need "Private Unstable" and I can remove it.  Alternately, we 
could rename "Private" to "Private Volatile" :)


I'll get rid of Private Unstable for now since we don't have any 
interfaces that meet that requirement, and may never.  We can always add 
it in later.


David

John Embretsen wrote:

Friday, March 31, 2006, 9:34:30 PM CET, David W. Van Couvering wrote:


I've updated the Wiki page to reflect some of this discussion and my 
sense of where things are ending up.  You can use the diff mechanism of 
the Wiki to see what's changed.



I was trying to understand all the different stability levels you
suggested on http://wiki.apache.org/db-derby/ForwardCompatibility, and
have one question:

Do we really have to differentiate between between a "Private" and a
"Private Unstable" interface?

If so, can you also explain to me why you are saying that "Private"
interfaces allow incompatible change at any time, while "Private
Unstable" only allows such changes at minor release? To me the term
"Private Unstable" certainly sounds less stable than "Private"...

Re: Regression checkbox (was Re: Can we change SQL State?)

[David W. Van Couvering]

Great, thanks for the quick attention to this!

David

Andrew McIntyre wrote:

On 3/31/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:


It is the other way around.  ":Existing Application Impact" is for
things that are not regressions but  rather intentional behaviour
changes or fixes that might affect existing applications. An example
might be a bug fix that made Derby comply with standard behaviour where
it did not before.It may have existing application impact but is not
a regression.



Ah, I see. I don't think that was clear from the previous comments.
I've added a checkbox for that as well.

andrew

Re: Regression checkbox (was Re: Can we change SQL State?)

[Andrew McIntyre]

On 3/31/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
>
> It is the other way around.  ":Existing Application Impact" is for
> things that are not regressions but  rather intentional behaviour
> changes or fixes that might affect existing applications. An example
> might be a bug fix that made Derby comply with standard behaviour where
> it did not before.It may have existing application impact but is not
> a regression.

Ah, I see. I don't think that was clear from the previous comments.
I've added a checkbox for that as well.

andrew

Re: Regression checkbox (was Re: Can we change SQL State?)

[Kathey Marsden]

Andrew McIntyre wrote:

>On 3/31/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
>  
>
>>I think notification is great.  I don't understand why what you are
>>suggesting should be "components" they really seem to me to make sense
>>as checkboxes -- how are these "components" of the system?  Andrew, can
>>you explain?
>>
>>
>
>I had misunderstood Kathey's request earlier. I agree that checkboxes
>for this behavior would be good to have to flag issues as regressive
>behavior, with an additional checkbox for release notes impact, and
>leaving the Regression Test Failure component specifically for test
>failures. I'm wondering though, if "Existing Application Impact" is
>perhaps redundant? In what situations would a behavior be a
>regression, need specific mentioning in the release notes, and not
>have an impact on existing applications?
>
>  
>
It is the other way around.  ":Existing Application Impact" is for
things that are not regressions but  rather intentional behaviour
changes or fixes that might affect existing applications. An example
might be a bug fix that made Derby comply with standard behaviour where
it did not before.It may have existing application impact but is not
a regression.


Kathey

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[John Embretsen]

Friday, March 31, 2006, 9:34:30 PM CET, David W. Van Couvering wrote:

> I've updated the Wiki page to reflect some of this discussion and my 
> sense of where things are ending up.  You can use the diff mechanism of 
> the Wiki to see what's changed.

I was trying to understand all the different stability levels you
suggested on http://wiki.apache.org/db-derby/ForwardCompatibility, and
have one question:

Do we really have to differentiate between between a "Private" and a
"Private Unstable" interface?

If so, can you also explain to me why you are saying that "Private"
interfaces allow incompatible change at any time, while "Private
Unstable" only allows such changes at minor release? To me the term
"Private Unstable" certainly sounds less stable than "Private"...


-- 
John

Re: Regression checkbox (was Re: Can we change SQL State?)

[Andrew McIntyre]

On 3/31/06, Andrew McIntyre <[EMAIL PROTECTED]> wrote:
>
> I had misunderstood Kathey's request earlier. I agree that checkboxes
> for this behavior would be good to have to flag issues as regressive
> behavior, with an additional checkbox for release notes impact, and
> leaving the Regression Test Failure component specifically for test
> failures.

Sorry for the JIRA blast, I needed to move the issues with Patch
Available to a new custom field so that we could add additional
checkboxes. But, seems like a good opportunity for the committers to
review the issues with patches available.

andrew

[jira] Updated: (DERBY-805) Push join predicates into union and other set operations. DERBY-649 implemented scalar (single table) predicate pushdown. Adding join predicate push down could improve perf

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-805?page=all ]

Andrew McIntyre updated DERBY-805:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Push join predicates into union and other set operations. DERBY-649 
> implemented scalar (single table) predicate pushdown. Adding join predicate 
> push down could improve performance significantly.
> --
>
>  Key: DERBY-805
>  URL: http://issues.apache.org/jira/browse/DERBY-805
>  Project: Derby
> Type: Sub-task
>   Components: SQL
> Versions: 10.1.2.0, 10.2.0.0
>  Environment: generic
> Reporter: Satheesh Bandaram
> Assignee: A B
>  Fix For: 10.2.0.0
>  Attachments: DERBY-805.html, DERBY-805_v2.html, DERBY-805_v3.html, 
> d805_phase1_v1.patch, d805_phase1_v1.stat, d805_phase1_v2.patch, 
> d805_phase1_v2.stat, d805_phase1_v3.patch, d805_phase1_v3.stat, 
> d805_phase2_v1.patch, d805_phase2_v1.stat, d805_phase3_v1.patch, 
> d805_phase3_v1.stat, phase2_javadocFix.patch, predPushdown_testFix.patch
>
> Fix for DERBY-649 implemented scalar (single table) predicate push down into 
> UNIONs. While this improves performance for one set of queries, ability to 
> push join-predicates further improves Derby performance by enabling use of 
> indices where possible.
> For example,
> create view V1 as select i, j from T1 union all select i,j from T2; 
> create view V2 as select a,b from T3 union all select a,b from T4; 
> insert into T1 values (1,1), (2,2), (3,3), (4,4), (5,5); 
> For a query like
> select * from V1, V2 where V1.j = V2.b and V1.i =1;
> If the join order choosen is V1,V2, V1 can use index on V1.i (if present) 
> following fix for DERBY-649. But if there is a index on V2.b also, Derby 
> currently can't use that index. By pushing join predicate, Derby would be 
> able to use the index and improve performance. Some of the queries I have 
> seen (not the one shown here...) could improve from 70-120 seconds to about 
> one second.
> Note there is a good comment by Jeff Lichtman about join-predicate push down. 
> I am copying parts of it here for completeness of this report: (Modified)
> If predicate push down is done during optimization, it would be possible to 
> push joins into the union as long as it's in the right place in the join 
> order.
> For example:
> create view v as select * from t1 union all select * from t2;
> select * from v, t3 where v.c1 = t3.c2;
> In this select, if t3 is the outer table then the qualification could be 
> pushed into the union and optimized there, but if t3 is the inner table the 
> qualification can't be pushed into the union.
> If the pushing is done at preprocess time (i.e. before optimization) it is 
> impossible to know whether a join qualification like this can be safely 
> pushed.
> There's a comment in UnionNode.optimizeIt() saying:
> /* RESOLVE - don't try to push predicated through for now */
> This is where I'd expect to see something for pushing predicates into the 
> union during optimization.
> BTW, the business of pushing and pulling predicates during optimization can 
> be hard to understand and debug, so maybe it's best to only handle the simple 
> cases and do it during preprocessing.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-482) GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities guide under "Importing into tables with identity columns" section.

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-482?page=all ]

Andrew McIntyre updated DERBY-482:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> GENERATED BY DEFAULT option should be documented in Derby Tools and Utilities 
> guide under "Importing into tables with identity columns" section.
> 
>
>  Key: DERBY-482
>  URL: http://issues.apache.org/jira/browse/DERBY-482
>  Project: Derby
> Type: Improvement
>   Components: Documentation
> Versions: 10.1.1.0
> Reporter: Mamta A. Satoor
>  Attachments: ctoolsimportidentitycol.html, derby482.diff
>
> Tomohito added support for import into identity columns by adding GENERATED 
> BY DEFAULT option. This is documented in the Reference Guide but not in the 
> Tools and Utilites Guide which is where a user would look for details on 
> import. IMHO, there should be information about this in "Importing into 
> tables with identity columns" section in Tools and Utilities Guide.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-981) Errors in Tuning Guide's "Properties case study"

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-981?page=all ]

Andrew McIntyre updated DERBY-981:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Errors in Tuning Guide's "Properties case study"
> 
>
>  Key: DERBY-981
>  URL: http://issues.apache.org/jira/browse/DERBY-981
>  Project: Derby
> Type: Bug
>   Components: Documentation
> Versions: 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.0.2.0, 10.2.0.0, 10.1.2.2, 
> 10.1.2.1, 10.1.2.0, 10.1.1.2
>  Environment: All
> Reporter: John H. Embretsen
> Assignee: John H. Embretsen
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: DERBY-981_v1.diff, DERBY-981_v1.stat, ctunsetprop32443_v1.html
>
> The tuning guide contains a "Properties case study", demonstrating precedence 
> and persistence of derby properties; see 
> http://db.apache.org/derby/docs/dev/tuning/ctunsetprop32443.html. There is at 
> least one factual error and a couple of inaccurate details in this case study:
> 1) The value of the property derby.storage.pageSize that is being used in the 
> last example should be 32768, not 8192:
> After the example statement 
> CREATE TABLE table4 (a INT, b VARCHAR(10))
> the case study states
> "Derby uses the persistent database-wide property of 8192 for this table, 
> since the database-wide property set in the previous session is persistent 
> and overrides the system-wide property set in the derby.properties file."
> In the previous session, however, the database-wide property 
> derby.storage.pageSize is set to 32768 (not 8192), by doing the following:
> === start quote ===
> You establish a connection to the database and set the value of the page size 
> for all new tables to 32768 as a database-wide property: 
> CallableStatement cs = 
> conn.prepareCall("CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?, ?)"); 
> cs.setString(1, "derby.storage.pageSize"); 
> cs.setString(2, "32768"); 
> cs.execute(); 
> cs.close(); 
> === end quote ===
> 8192 is the value that is specified in the derby.properties file, which is 
> overridden by the value (32768) specified in the database.
> (Assuming that the same database is being used).
> 2) Inconsistent use of application name:
> The case study describes persistence/precedence of a derby property by 
> showing different ways of specifying this property when starting/running an 
> application (embedded Derby). It seems that the intention was to show this 
> using the same application and database. However, different application names 
> are used throughout the case study:
> a) java -Dderby.system.home=c:\system_directory MyApp
> b) java -Dderby.system.home=c:\system_directory  
> -Dderby.storage.pageSize=4096 myApp
> c) java -Dderby.system.home=c:\system_directory myApplication
> Potential confusion may be avoided by using the same application name 
> throughout the case study.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-402) INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-402?page=all ]

Andrew McIntyre updated DERBY-402:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> INTERSECT/EXCEPT/UNION operators don't agree with documented behavior.
> --
>
>  Key: DERBY-402
>  URL: http://issues.apache.org/jira/browse/DERBY-402
>  Project: Derby
> Type: Bug
>   Components: Documentation
> Versions: 10.1.1.0, 10.0.2.2
> Reporter: A B
>  Fix For: 10.2.0.0
>  Attachments: derby402Final.diff, rrefselectexpression.html, 
> rrefsqlj1083019.html
>
> I noticed the following two differences between what the documentation 
> (Reference Manual) says about UNION/INTERSECT/EXCEPT queries and what the 
> actual Derby behavior is.  I'm filing this issue as a single "bug" against 
> Derby, but if it turns out later that this is really just a documentation 
> issue, or that these are "improvements" instead of bugs, anyone should feel 
> free to change the relevant fields in this issue...
> 1) -- p. 63 of the Reference Manual (PDF version): "SelectExpression" -> 
> "Naming columns"
> First paragraph in this section includes the following:
> When the SelectExpression appears in a UNION, INTERSECT,
> or EXCEPT operator, the names from the first SelectExpression
> are taken as the names for the columns in the result of
> the operation.
> But this doesn't appear to be true.  Ex:
> ij> select a from t1 union select b from t2;
> 1 // This "1" should be "A", according to doc.
> ---
> 1
> 2
> If this behavior is intentional, then an ORDER BY clause on a 
> UNION/INTERSECT/EXCEPT result set can only reference the result columns by 
> position (ex. would have to use "order by 1" in the above query since "order 
> by  a" doesn't work (because the name of the result column isn't "a")).
> Note that if both SelectExpressions have the same column name, then things 
> work  differently:
> ij> select a from t1 union select b as a from t2;
> A // Now it's "A" instead of "1".
> ---
> 1
> 2
> So what needs to be corrected here?  The documentation or the code?
> 2) -- p. 133 of  the Reference Manual: "Dynamic Parameters" ->  "Where 
> dynamic parameters are allowed"
> Number 16 says "a dynamic parameter is allowed to represent a column if it 
> appears in a UNION, INTERSECT, or EXCEPT expression."  But the two examples 
> that it gives both fail:
> ij> SELECT ? FROM t UNION SELECT 1 FROM t;
> ERROR 42X34: There is a ? parameter in the select list.  This is not allowed.
> ij> VALUES 1 UNION VALUES ?;
> ERROR 42X34: There is a ? parameter in the select list.  This is not allowed.
> I also tried preparing these statements using JDBC, but they failed there 
> with the same error..

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-920) small delta's to replace cloudscape etc with derby in comments/code

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-920?page=all ]

Andrew McIntyre updated DERBY-920:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> small delta's to replace cloudscape etc with derby in comments/code
> ---
>
>  Key: DERBY-920
>  URL: http://issues.apache.org/jira/browse/DERBY-920
>  Project: Derby
> Type: Task
>  Environment: N/A
> Reporter: scott hutinger
> Priority: Trivial
>  Attachments: sysinfo-main.diff.gz
>
> Smaller delta's to modify older source code comments which in some cases 
> should be updated.  Many cases older owners of the source should be kept 
> intact, as it refers to past or future tenses in a context where changes are 
> not needed/wanted.
> Smaller delta's so this might happen some day :-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-787) cursor closed as a sideeffect of closing another cursor with the same name on another connection

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-787?page=all ]

Andrew McIntyre updated DERBY-787:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> cursor closed as a sideeffect of closing another cursor with the same name on 
> another connection
> 
>
>  Key: DERBY-787
>  URL: http://issues.apache.org/jira/browse/DERBY-787
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.1.2.1
>  Environment: Java 1.4
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
>  Attachments: CursorIsClosedIssue.java, DERBY-787.diff, DERBY-787.stat, 
> derbyall_report.txt
>
> I was writing some tests for the Scrollable updatable ResultSet feature, and  
> found some tests failing with 
> ERROR XCL07: Cursor 'SQLCUR0' is closed. Verify that autocommit is OFF.
> in ResultSet.updateRow(). 
> The test does the following:
> 1. set up a connection, and run a query which selects one tuple
> 2. update the tuple using updateXXX and updateRow
> 3. rollback the transaction and close the connection
> Then, repeat the process, however this time use a different string in the 
> query.  This time updateRow() may fail with the error above. 
> The problem has been reproduced on forward only, updatable resultsets.
> Workaround:
> It does not seem to fail if I
> a, set another cursorname on the statement object,
> b, use the same query string.
> I will attach the program to reproduce the problem. Below is the output:
> ~:/<3>db-derby-10.1.2.1-bin/lib> java -cp 
> /home/ak136785/devel/derbytesting/derbytest/build/classes/:derby.jar 
> derbytest.CursorIsClosedIssue
> 1,1,19,Tuple 1
> 2,2,21,Tuple 2
> ERROR XCL07: Cursor 'SQLCUR0' is closed. Verify that autocommit is OFF.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown 
> Source)
> at 
> org.apache.derby.impl.sql.execute.CurrentOfResultSet.getCursor(Unknown Source)
> at 
> org.apache.derby.impl.sql.execute.CurrentOfResultSet.openCore(Unknown Source)
> at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(Unknown 
> Source)
> at 
> org.apache.derby.impl.sql.execute.NormalizeResultSet.openCore(Unknown Source)
> at org.apache.derby.impl.sql.execute.UpdateResultSet.setup(Unknown 
> Source)
> at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown 
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source)
> at org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(Unknown Source)
> at derbytest.CursorIsClosedIssue.runTest(CursorIsClosedIssue.java:80)
> at derbytest.CursorIsClosedIssue.main(CursorIsClosedIssue.java:103)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configur

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-464?page=all ]

Andrew McIntyre updated DERBY-464:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner 
> level of privileges than currently provided by Derby that is especially 
> useful in network configurations.
> ---
>
>  Key: DERBY-464
>  URL: http://issues.apache.org/jira/browse/DERBY-464
>  Project: Derby
> Type: New Feature
>   Components: SQL
> Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0
>  Environment: generic
> Reporter: Satheesh Bandaram
> Assignee: Satheesh Bandaram
>  Attachments: GrantRevokePartII.stat, GrantRevokePartII.txt, 
> GrantRevokePartII.txt, Privileges.java, Privileges2.java, 
> changeDescriptionPartII, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5, 
> grantRevokeSpec.html, grantRevokeSpec_v2.html
>
> Derby currently provides a very simple permissions scheme, which is quite 
> suitable for an embedded database system. End users of embedded Derby do not 
> see Derby directly; they talk to a application that embeds Derby. So Derby 
> left most of the access control work to the application. Under this scheme, 
> Derby limits access on a per database or per system basis. A user can be 
> granted full, read-only, or no access. 
> This is less suitable in a general purpose SQL server. When end users or 
> diverse applications can issue SQL commands directly against the database, 
> Derby must provide more precise mechanisms to limit who can do what with the 
> database.
> I propose to enhance Derby by implementing a subset of grant/revoke 
> capabilities as specified by the SQL standard. I envision this work to 
> involve the following tasks, at least:
> 1) Develop a specification of what capabilities I would like to add to Derby.
> 2) Provide a high level implementation scheme.
> 3) Pursue a staged development plan, with support for DDL added to Derby 
> first.
> 4) Add support for runtime checking of these privileges.
> 5) Address migration and upgrade issues from previous releases and from old 
> scheme to newer database.
> Since I think this is a large task, I would like to invite any interested 
> people to work with me on this large and important enhancement to Derby.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-815) Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-815?page=all ]

Andrew McIntyre updated DERBY-815:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Prevent unneeded object creation and excessive decoding in parseSQLDTA_work()
> -
>
>  Key: DERBY-815
>  URL: http://issues.apache.org/jira/browse/DERBY-815
>  Project: Derby
> Type: Sub-task
>   Components: Network Server, Performance
> Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.3.0, 
> 10.1.2.2, 10.0.2.2
> Reporter: Knut Anders Hatlen
> Assignee: Dyre Tjeldvoll
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: d815_regress.diff, d815_regress.java, derby-815.diff, 
> derby-815.html, derby-815.v3.diff, derby-815.v3.html, derby-815.v3.stat, 
> derby-815_2.diff, derbyall_report_with_jdk1.4.v3.txt
>
> Reported by Kathey Marsden in DERBY-212:
> In reviewing the Network Server Code and profiling there were several
> areas that showed potential for providing performance
> improvement. Functions that need optimizing to prevent unneeded object
> creation and excessive decoding: parseSQLDTA_work()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1121) jdbcapi/checkDriver.java fails in remote server testing

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1121?page=all ]

Andrew McIntyre updated DERBY-1121:
---

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> jdbcapi/checkDriver.java fails in remote server testing
> ---
>
>  Key: DERBY-1121
>  URL: http://issues.apache.org/jira/browse/DERBY-1121
>  Project: Derby
> Type: Test
>  Environment: Remote server test
> Reporter: Deepa Remesh
> Assignee: Deepa Remesh
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.2.4
>  Attachments: derby-1121.diff, derby-1121.status
>
> This was reported by Myrna in derby-dev: 
> http://www.nabble.com/checkDriver-test-for-DB-with-spaces-t1257197.html#a847

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-936) Main branch docs display version as 10.1, should be 10.2.

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-936?page=all ]

Andrew McIntyre updated DERBY-936:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Main branch docs display version as 10.1, should be 10.2.
> -
>
>  Key: DERBY-936
>  URL: http://issues.apache.org/jira/browse/DERBY-936
>  Project: Derby
> Type: Improvement
>   Components: Documentation
> Versions: 10.0.2.0
> Reporter: Andrew McIntyre
>  Attachments: derby936.diff
>
> Currently the output for the PDF and HTML Book formats of the manuals on the 
> main branch display the version 10.1. Documentation changes have been 
> committed which make the main branch of the documentation no longer proper 
> for 10.1, so the version the main branch of the documentation displays should 
> be 10.2.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-970) Add new metadata methods to network client driver

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-970?page=all ]

Andrew McIntyre updated DERBY-970:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Add new metadata methods to network client driver
> -
>
>  Key: DERBY-970
>  URL: http://issues.apache.org/jira/browse/DERBY-970
>  Project: Derby
> Type: Sub-task
>   Components: JDBC
> Reporter: David Van Couvering
> Assignee: Knut Anders Hatlen
>  Fix For: 10.2.0.0
>  Attachments: derby-970-part1-v1.diff, derby-970-part1-v1.stat, 
> derby-970-part2-v1.diff, derby-970-part2-v1.stat, derby-970-part3-v1.diff, 
> derby-970-part3-v1.stat
>
> Implement new JDBC 4.0 DatabaseMetaData methods in the client driver:
>   - supportsStoredFunctionsUsingCallSyntax()
>   - autoCommitFailureClosesAllResultSets()
>   - getClientInfoProperties()
>   - providesQueryObjectGenerator()
>   - getSchemas()
>   - getRowIdLifetime()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1172?page=all ]

Andrew McIntyre updated DERBY-1172:
---

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> incorrect error message in updateRow() after a commit on a held scroll 
> insensitive resultset
> 
>
>  Key: DERBY-1172
>  URL: http://issues.apache.org/jira/browse/DERBY-1172
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
>  Attachments: DERBY-1172.diff, DERBY-1172.stat
>
> If an application does updateRow() right after a commit on a held cursor, 
> (without repositioning the cursor), an incorrect error message is given if 
> the ResultSet is of type TYPE_SCROLL_INSENSITIVE.
> "SQL 2003, Part 2: Foundation (SQL/Foundation) p 827,
> paragraph numbered 6):
> 6)If CR is a holdable cursor and a has not been
>   issued against CR within the current SQL- transaction,then an
>   exception condition is raised: invalid cursor state .
> and that exception has state 24000"
> Currently, if the ResultSet is of type TYPE_SCROLL_INSENSITIVE, it fails with
> SQL Exception: The scan is not positioned. state: XSCH7 : code=2
> If the ResultSet is of type TYPE_FORWARD_ONLY, it gives the correct error 
> message:
> SQL Exception: Invalid cursor state - no current row. state: 24000 : 
> code=2
> The first exception is given from the store layer. The SQL layer seems to 
> catch the store exception and rethrow a new exception with correct SQL state 
> and error message. However this is not done in 
> TableScanResultset.getRowLocation(), which is used by scrollinsensitve 
> cursors.
> A fix could be to add this logic into TableScanResultset.getRowLocation(). Or 
> alternatively, make the store layer throw the expected exception, and remove 
> logic to rethrow the exception.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-542) Update documentation for DERBY-470

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-542?page=all ]

Andrew McIntyre updated DERBY-542:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Update documentation for DERBY-470
> --
>
>  Key: DERBY-542
>  URL: http://issues.apache.org/jira/browse/DERBY-542
>  Project: Derby
> Type: Sub-task
>   Components: Documentation
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Deepa Remesh
> Priority: Minor
>  Attachments: derby542.diff, rtoolsijcomref88554.html
>
> To reflect the change for DERBY-470, the following information has to be 
> added to Derby Tools and Utilities Guide:
> Section ij commands and errors reference-->LocalizedDisplay:
> NUMERIC and DECIMAL values are not localized on J2ME/CDC/Foundation Profile 
> because of platform limitations.
> Please review this. Also, is there any other place in the documents where 
> this info needs to be added? 
> It would be great if someone working on documents can make this change.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1002) Check that DRDAStatement and DRDAResultSet states are reset when they are re-used

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1002?page=all ]

Andrew McIntyre updated DERBY-1002:
---

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Check that DRDAStatement and DRDAResultSet states are reset when they are 
> re-used
> -
>
>  Key: DERBY-1002
>  URL: http://issues.apache.org/jira/browse/DERBY-1002
>  Project: Derby
> Type: Bug
>   Components: Network Server
> Reporter: Deepa Remesh
>  Fix For: 10.2.0.0
>  Attachments: derby1002-patch1-draft1.diff, derby1002-patch1-draft1.status, 
> derby1002-patch1-v1.diff, derby1002-patch1-v1.status, 
> derby1002-patch2-v2.diff, derby1002-patch2-v2.status, derby1002.java
>
> Network server re-uses DRDAStatement and DRDAResultSet objects when client 
> sends a request with same section number. When re-using DRDAStatement, it's 
> close() method is called which inturn calls close() method of DRDAResultSet. 
> For re-use to work properly, we have to ensure the states of these objects 
> are reset. This is not a bug but it is an area for possible improvements like:
> * The reset of all states are not in the close() methods. The states get 
> re-initialized at different places in the code. Fo example, in case of 
> DRDAResultSet, they get initialized in some other DRDAStatement methods - 
> like addResultSet, setRsDefaultOptions, setOPNQRYOptions, setQueryOptions 
> etc. It will be good to have all resets in one method.
> * The method name "close" is confusing since it is also called when objects 
> get re-used. For clarity, it may be good to have a method named reset(). And 
> then have the close method call reset.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-654) unit/T_RawStoreFactory.unit fails with an assert failure in J2ME/CDC/FP

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-654?page=all ]

Andrew McIntyre updated DERBY-654:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> unit/T_RawStoreFactory.unit fails with an assert failure in J2ME/CDC/FP
> ---
>
>  Key: DERBY-654
>  URL: http://issues.apache.org/jira/browse/DERBY-654
>  Project: Derby
> Type: Bug
>   Components: Store
> Versions: 10.2.0.0
>  Environment: IBM WCTME5.7 j9 foundation VM 
> Reporter: Deepa Remesh
> Priority: Minor
>  Attachments: Derby654.stat.txt, derby654.diff.txt
>
> I am thinking this is a bug and opening a JIRA issue since I did not get any 
> response to my question in derby-dev. One more thing I noticed is this test 
> passes in 10.1 branch.  It is failing only in trunk.
> The test unit/T_RawStoreFactory.unit fails with an assert failure in CDC/FP. 
> This failure looks like an intermittent one though it is failing all the time 
> now. I have run this test successfully some time back. I would like to find 
> out if this is a bug (Derby or jvm) or just an intermittent failure. I am 
> using j9 foundation  from IBM WCTME5.7.
> -
> diff for the test:
> -
>  < -- Unit Test T_RawStoreFactory finished
>  2 add
>  > There should be 0 observers, but we still have 1 observers.
> > Shutting down due to unit test failure.
> -
> stack trace for AssertFailure in derby.log is:
> -
>  FAIL - org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT
> FAILED still on observer list
> [EMAIL PROTECTED]
> org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT FAILED
> still on observer list
> [EMAIL PROTECTED]
>at 
> org.apache.derby.iapi.services.sanity.SanityManager.THROWASSERT(SanityManager.java:150)
>at 
> org.apache.derby.impl.store.raw.data.TruncateOnCommit.update(TruncateOnCommit.java:69)
>at java.util.Observable.notifyObservers(Observable.java:117)
>at 
> org.apache.derby.iapi.store.raw.xact.RawTransaction.notifyObservers(RawTransaction.java:313)
>at org.apache.derby.impl.store.raw.xact.Xact.doComplete(Xact.java:1927)
>at 
> org.apache.derby.impl.store.raw.xact.Xact.preComplete(Xact.java:1880)
>at 
> org.apache.derby.impl.store.raw.xact.Xact.prepareCommit(Xact.java:726)
>at org.apache.derby.impl.store.raw.xact.Xact.commit(Xact.java:839)
>at org.apache.derby.impl.store.raw.xact.Xact.commit(Xact.java:636)
>at 
> org.apache.derbyTesting.unitTests.store.T_Util.t_commit(T_Util.java:838)
>at 
> org.apache.derbyTesting.unitTests.store.T_RawStoreFactory.TC001(T_RawStoreFactory.java:7435)
>at 
> org.apache.derbyTesting.unitTests.store.T_RawStoreFactory.runTempTests(T_RawStoreFactory.java:420)
>at 
> org.apache.derbyTesting.unitTests.store.T_RawStoreFactory.runTestSet(T_RawStoreFactory.java:247)
>at 
> org.apache.derbyTesting.unitTests.harness.T_MultiIterations.runTests(T_MultiIterations.java:94)
>at 
> org.apache.derbyTesting.unitTests.harness.T_MultiThreadedIterations.runTests(T_MultiThreadedIterations.java:91)
>at 
> org.apache.derbyTesting.unitTests.harness.T_Generic.Execute(T_Generic.java:117)
>at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.runATest(BasicUnitTestManager.java:183)
>at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.runTests(BasicUnitTestManager.java:245)
>at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.boot(BasicUnitTestManager.java:92)
>at 
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:2008)
>at 
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290)
>at 
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1846)
>at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startServices(BaseMonitor.java:966)
>at 
> org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:398)
>at 
> org.apache.derby.impl.services.monitor.FileMonitor.(FileMonitor.java:59)
>at 
> org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:288)
>at 
> org.apache.derbyTesting.unitTests.harness.UnitTestMain.main(UnitTestMain.java:50)
> -
> On looking at the code, I did not understand how this assert failure can 
> happen. The assert is thrown in following code in TruncateOnCommit: 
> public void update(Observable obj, Object arg) {
>if (SanityManager.DEBUG) {
>  

[jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-210?page=all ]

Andrew McIntyre updated DERBY-210:
--

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Network Server will leak prepared statements if not explicitly closed by the 
> user until the connection is closed
> 
>
>  Key: DERBY-210
>  URL: http://issues.apache.org/jira/browse/DERBY-210
>  Project: Derby
> Type: Bug
>   Components: Network Client
> Reporter: Kathey Marsden
>  Attachments: DOTS_ATCJ2_Derby-noPatch.png, DOTS_ATCJ2_Derby-withPatch.png, 
> StatementStress.java, derby-210-patch1.diff, derby-210-patch2.diff, 
> derby-210-patch2.status, derby-210-patch3.diff, derby-210-patch4-v2.diff, 
> derby-210-patch4-v2.status, derby-210-patch4-v3.diff, 
> derby-210-patch4-v3.status, derby-210-patch5-v1.diff, 
> derby-210-patch5-v1.status, derby-210-v2-draft.diff, 
> derby-210-v2-draft.status, derbyStress.java, runtimeinfo_DOTS-OOME.txt
>
> Network server will not garbage collect prepared statements that are not 
> explicitly closed by the user.  So  a loop like this will leak.
> ...
> PreparedStatement ps;
>  for (int i = 0 ; i  < numPs; i++)
>   {
>ps = conn.prepareStatement(selTabSql);
>rs =ps.executeQuery();
>while (rs.next())
>   {
>   rs.getString(1);
>   }
>   rs.close();
>   // I'm a sloppy java programmer
>   //ps.close();
>   }
>   
> To reproduce run the attached program 
> java derbyStress
> Both client and server will grow until the connection is closed.
>  
> It is likely that the fix for this will have to be in the client.  The client 
> does not send protocol to close the prepared statement, but rather reuses the 
> PKGNAMCSN on the PRPSQLSTT request once the prepared statement has been 
> closed. This is how the server knows to close the old statement and create a 
> new one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1109) lang/predicatePushdown.sql fails with wsdd5.6

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1109?page=all ]

Andrew McIntyre updated DERBY-1109:
---

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> lang/predicatePushdown.sql fails with wsdd5.6
> -
>
>  Key: DERBY-1109
>  URL: http://issues.apache.org/jira/browse/DERBY-1109
>  Project: Derby
> Type: Test
>   Components: Regression Test Failure
> Versions: 10.2.0.0
>  Environment: IBM wsdd5.6 j9_13
> Reporter: Deepa Remesh
> Assignee: A B
>  Attachments: d1109.patch, d1109.stat
>
> This test fails with the following diff:
> 7507a7508,7509
> > 2  |1  
> > 4  |2  
> 7509,7510d7510
> < 4  |2  
> < 2  |1  
> 7632a7633,7636
> > 2  |1  
> > 2  |1  
> > 4  |2  
> > 4  |2  
> 7635,7638d7638
> < 4  |2  
> < 4  |2  
> < 2  |1  
> < 2  |1 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1093) Make DatabaseMetaData.getProcedures() JDBC4 compliant

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1093?page=all ]

Andrew McIntyre updated DERBY-1093:
---

Other Info:   (was: [Patch available])
Derby Info: [Patch Available]

> Make DatabaseMetaData.getProcedures() JDBC4 compliant
> -
>
>  Key: DERBY-1093
>  URL: http://issues.apache.org/jira/browse/DERBY-1093
>  Project: Derby
> Type: Sub-task
>   Components: JDBC, Newcomer
> Versions: 10.2.0.0
> Reporter: Dyre Tjeldvoll
> Assignee: Dyre Tjeldvoll
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: derby-1093.v1.diff, derby-1093.v1.stat, derbyall_report.txt, 
> upgrade.txt
>
> JDBC 4.0 requires that the result set returned from getProcedures must 
> contain a new column SPECIFIC_NAME"and that the result set must be ordered by
> PROCEDURE_SCHEM, PROCEDURE_NAME and SPECIFIC_ NAME.
> The SYSALIASES table already has a column called SPECIFICNAME, so it should 
> only be necessary to modify the query in metadata.properties.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (DERBY-1085) java.lang.NullPointerException with char for bit data column and subquery

[Satheesh Bandaram (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1085?page=all ]

Satheesh Bandaram reassigned DERBY-1085:


Assign To: Satheesh Bandaram

> java.lang.NullPointerException with char for bit data column  and subquery
> --
>
>  Key: DERBY-1085
>  URL: http://issues.apache.org/jira/browse/DERBY-1085
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.1.2.2, 10.2.0.0, 10.1.3.0, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: Satheesh Bandaram

>
> The repro below gives a NullPointerException with 10.1 and trunk with query 
> involving char for bit data column and subquery:
> ij> connect 'wombat;create=true';
> ij> create table npetest1 (col1 char(36) for bit data not null, constraint
> pknpe1 primary
> key (col1));
> 0 rows inserted/updated/deleted
> ij> create table npetest2 (col2 char(36) for bit data, constraint fknpe1 
> foreign
> key
> (col2) references npetest1 (col1) on delete cascade);
> 0 rows inserted/updated/deleted
> ij> insert into npetest1 (col1) values
> (x'0001');
> 1 row inserted/updated/deleted
> ij> insert into npetest1 (col1) values
> (x'0002');
> 1 row inserted/updated/deleted
> ij> insert into npetest1 (col1) values
> (x'0003');
> 1 row inserted/updated/deleted
> ij> insert into npetest2 (col2) values
> (x'0001');
> 1 row inserted/updated/deleted
> ij> insert into npetest2 (col2) values (NULL);
> 1 row inserted/updated/deleted
> ij> insert into npetest2 (col2) values
> (x'0002');
> 1 row inserted/updated/deleted
> ij> select col1 from npetest1 where col1 not in (select col2 from
> npetest2);
> COL1
> 
> ERROR 38000: The exception 'java.lang.NullPointerException' was thrown while 
> evaluating an expression.
> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> ERROR 38000: The exception 'java.lang.NullPointerException' was thrown while 
> evaluating an expression.
>   at 
> org.apache.derby.iapi.error.StandardException.newException(StandardException.java:315)
>   at 
> org.apache.derby.iapi.error.StandardException.unexpectedUserException(StandardException.java:564)
>   at 
> org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:163)
>   at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:270)
>   at 
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:474)
>   at 
> org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:401)
>   at 
> org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:346)
>   at 
> org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:334)
>   at 
> org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:271)
>   at 
> org.apache.derby.tools.JDBCDisplayUtil.DisplayResults(JDBCDisplayUtil.java:260)
>   at 
> org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:381)
>   at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:434)
>   at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310)
>   at org.apache.derby.impl.tools.ij.Main.go(Main.java:203)
>   at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169)
>   at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
>   at org.apache.derby.tools.ij.main(ij.java:60)
> = begin nested exception, level (1) ===
> java.lang.NullPointerException
>   at org.apache.derby.iapi.types.SQLBinary.getLength(SQLBinary.java:230)
>   at 
> org.apache.derby.impl.sql.execute.BaseActivation.materializeResultSetIfPossible(BaseActivation.java:1430)
>   at 
> org.apache.derby.exe.acfe120070x0109xd801x02acx00142bf86.g0(Unknown 
> Source)
>   at 
> org.apache.derby.exe.acfe120070x0109xd801x02acx00142bf86.e1(Unknown 
> Source)
>   at 
> org.apache.derby.impl.services.reflect.DirectCall.invoke(ReflectGeneratedClass.java:140)
>   at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(ProjectRestrictResultSet.java:270)
>   at 
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(BasicNoPutResultSetImpl.java:474)
>   at 
> org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet.java:401)
>   at 
> org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:346)
>   at 
> org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:334)
>   at 
> org.apache.derby.tools.JDBCDisplayUtil.indent_DisplayResults(JDBCDisplayUtil.java:271)
>   at 
> org.apache.d

[jira] Commented: (DERBY-940) Add JDBC 4 Wrapper support

[Rick Hillegas (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-940?page=comments#action_12372723 ] 

Rick Hillegas commented on DERBY-940:
-

Hi Narayanan,

Thanks for all the good work. I think that, going forward, we should stop 
writing the old-style tests and concentrate on writing JUnit tests. With a 
little effort, you should be able to recast TestDataSourceMethods as a junit 
test extending BaseJDBCTestCase. If you do that, then you can eliminate the 
main() method and the "if(usingEmbeddedClient())" logic. Thanks to some recent 
work, you can now get the DataSource in a client-agnostic way from 
BaseJDBCTestCase.getDataSource(). To prevent the test from running under the 
Network client, you should add the test name (and a comment) to 
java/testing/org/apache/derbyTesting/functionTests/suites/DerbyNetClient.exclude.

I think that Kristian has a good solution to the problem of excluding 
individual test cases from client-specific runs. In any event, the exclusion is 
a temporary piece of scaffolding which you will be removing soon enough.

> Add JDBC 4 Wrapper support
> --
>
>  Key: DERBY-940
>  URL: http://issues.apache.org/jira/browse/DERBY-940
>  Project: Derby
> Type: New Feature
>   Components: JDBC
> Reporter: Rick Hillegas
> Assignee: V.Narayanan
>  Fix For: 10.2.0.0
>  Attachments: DERBY940_embedded.html, wrapper_ver1_embedded.diff, 
> wrapper_ver1_embedded.stat, wrapper_ver2_embedded.diff, 
> wrapper_ver2_embedded.stat, wrapper_ver3_embedded.diff, 
> wrapper_ver3_embedded.stat
>
> As described in the JDBC 4 spec, sections 21 and 3.1.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Regression checkbox (was Re: Can we change SQL State?)

[Andrew McIntyre]

On 3/31/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
>
> I think notification is great.  I don't understand why what you are
> suggesting should be "components" they really seem to me to make sense
> as checkboxes -- how are these "components" of the system?  Andrew, can
> you explain?

I had misunderstood Kathey's request earlier. I agree that checkboxes
for this behavior would be good to have to flag issues as regressive
behavior, with an additional checkbox for release notes impact, and
leaving the Regression Test Failure component specifically for test
failures. I'm wondering though, if "Existing Application Impact" is
perhaps redundant? In what situations would a behavior be a
regression, need specific mentioning in the release notes, and not
have an impact on existing applications?

andrew

Re: [web] Derby site reorganization (resend)

[Jean T. Anderson]

Andrew McIntyre wrote:
> On 3/31/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote:

default expansion isn't available, so ...

>>>... I would recommend
>>>removing the ASF and DB links to keep the list short:
>>>
>>>  Apache Derby
>>>  Charter
>>>  Quick Start
>>>  ASF <- remove
>>>  Apache DB Project   <- remove
>>>  Derby Wiki
>>>  License
>>>  FAQS
> ...
> Seems fine to me, they're still accessible via the breadcrumbs at the
> top of the page.

so, this is what the list would look like:

Apache Derby
Charter
Quick Start
Derby Wiki
License
FAQS

any changes?

 -jean

[jira] Commented: (DERBY-1076) Resolve the ouput differences in upgrade test

[Knut Anders Hatlen (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1076?page=comments#action_12372722 ] 

Knut Anders Hatlen commented on DERBY-1076:
---

The patch looks good, but the recent DERBY-690 check-in added some lines to the 
output from the metadata test. I can commit the patch if you update it with the 
new output.

> Resolve the ouput differences in upgrade test
> -
>
>  Key: DERBY-1076
>  URL: http://issues.apache.org/jira/browse/DERBY-1076
>  Project: Derby
> Type: Sub-task
>   Components: Test, Regression Test Failure
> Reporter: Deepa Remesh
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: derby-1076_master_update.diff, derby-1076_metadata_test.diff, 
> phaseTester.diff, phaseTester.out
>
> The output of running the upgrade test script (runphases.ksh) differs from 
> what is checked into the master file 
> (java\testing\org\apache\derbyTesting\functionTests\master\phaseTester.out). 
> These differences need to be checked to see there are no real issues in the 
> upgrade itself.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-1046) JVMInfo is duplicated in derbyclient.jar

[Knut Anders Hatlen (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1046?page=all ]
 
Knut Anders Hatlen closed DERBY-1046:
-

Fix Version: 10.2.0.0
 Resolution: Fixed

Seems like this has been fixed. Closing the issue.

> JVMInfo is duplicated in derbyclient.jar
> 
>
>  Key: DERBY-1046
>  URL: http://issues.apache.org/jira/browse/DERBY-1046
>  Project: Derby
> Type: Bug
>   Components: Build tools
> Versions: 10.2.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: derby-1046.diff
>
> The JVMInfo class is included twice in derbyclient.jar, as
> org.apache.derby.iapi.services.info.JVMInfo and
> org.apache.derby.shared.common.info.JVMInfo. The only one of them
> actually used by the client code is the one found in
> org.apache.derby.shared.common.info.
> org.apache.derby.iapi.services.info.JVMInfo is also included in
> derby.jar, so one could run into problems if the classpath contains
> derbyclient.jar and derby.jar with different versions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [web] Derby site reorganization (resend)

[Andrew McIntyre]

On 3/31/06, Jean T. Anderson <[EMAIL PROTECTED]> wrote:
>
> > If default expansion isn't
> > available yet, then a simple list would work, but I would recommend
> > removing the ASF and DB links to keep the list short:
> >
> >   Apache Derby
> >   Charter
> >   Quick Start
> >   ASF <- remove
> >   Apache DB Project   <- remove
> >   Derby Wiki
> >   License
> >   FAQS
> >
> > what do you think?

Seems fine to me, they're still accessible via the breadcrumbs at the
top of the page.

andrew

Re: [web] Derby site reorganization (resend)

[Jean T. Anderson]

Jean T. Anderson wrote:
> Daniel John Debrunner wrote:
> 
>>http://db.apache.org/derby/index.html
>>
>>On the home page we have the "Quick Links" section but in my mind they
>>are not "quick" as I have to expand to see the list before I can click
>>on them.
>>
>>Can we just get them as a simple list, or even expanded by default?
> 
> I asked forrest about expanding by default some time ago and was told we
> could do that in the "next release". I'll check the archives and see if
> that meant 0.7 (what we use now) or 0.8. 

The feature was intended for 0.7, but hasn't been implemented (yet):

   http://issues.apache.org/jira/browse/FOR-339

So, expanded by default is out for now unless we want to write our own
code to do it (and I don't).

Any comments on what I wrote below?

> If default expansion isn't
> available yet, then a simple list would work, but I would recommend
> removing the ASF and DB links to keep the list short:
> 
>   Apache Derby
>   Charter
>   Quick Start
>   ASF <- remove
>   Apache DB Project   <- remove
>   Derby Wiki
>   License
>   FAQS
> 
> what do you think?

> The other tab with lots of subcategories is the Resources tab. If
> default expansion isn't possible, would it be best to just list everything?

Regarding the Resources tab, listing everything would create a great
mishmash. I suggested leaving it as is with the "blocked" menu (i.e.,
you have to click to expand). An alternative might be to add more tabs.

thoughts?

thanks,

 -jean

Re: Help with CTRL-M in test output on Windows

[David W. Van Couvering]

Just for posterity, it turns out *I* was the one who added these output 
files (jdk16 output files) and my .config did *not* have ".out" as a 
prefix for svn:eol-style=native.  The template I cut-and-pasted from did 
not have it.  Others of you out there may want to fix this.


David

David W. Van Couvering wrote:
Thanks, Andrew.  I have this property set by default for new files I 
create, but it looks like it was never set for this existing output file.


I'll try the fix you suggest and see if it works.

David

Andrew McIntyre wrote:


On 3/31/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:


When I look at the diffs I have on some test output based on message
text changes, I get only the lines that have changed.  But in svn diff
it shows the old contents completely removed and new contents put in its
place, all with ^M characters at the end of each line.

Any advice on how to address this?  I would like reviewers to see the
actual changes made versus a global replace.




Sounds like it's missing the svn:eol-style native property in svn. I
think it might work to just set the property on a Windows machine,
remove the file and then svn up to restore it with the property added.
If that doesn't work, you'll need to commit the property change from a
Unix machine and then update your Windows checkout to get the correct
line-endings.

Also, its been mentioned before, but I'll mention it again in case
anyone missed it the first time. If you add the following to your
local ~/subversion/.config:

http://www.apache.org/dev/svn-eol-style.txt

then svn will automatically add the right property when new files are
added. You'll need to add *.out to this list as well.

andrew

[jira] Created: (DERBY-1173) Possible regression: jdbcapi/checkDataSource test hangs with client. After test is aborted, if rerun it gives he conglomerate (129) requested does not exist.

[Kathey Marsden (JIRA)]

Possible regression: jdbcapi/checkDataSource test hangs with client. After test 
is aborted,  if rerun it gives he conglomerate (129) requested does not exist.
--

 Key: DERBY-1173
 URL: http://issues.apache.org/jira/browse/DERBY-1173
 Project: Derby
Type: Bug
  Components: JDBC, Network Client  
Versions: 10.0.2.1
Reporter: Kathey Marsden
Priority: Critical
 Fix For: 10.2.0.0


I had been working on the checkDataSource test a few weeks ago, to get it 
working with client but did not bring it into a suite at that time 
unfortunately.

jdbcapi/checkDataSource.java now hangs with client.  If I abort the test with 
 c and rerun it fails on create table with:


 Booting Derby version The Apache Software Foundation - Apache Derby - 10.2.0.0 
alpha - (1): instance c013800d-010a-51bb-ae54-048a8d0f
on database directory D:\testout4\DerbyNetClient\checkDataSource\wombat  


Database Class Loader started - derby.database.classpath=''

Could not listen on port 1527 on host localhost.

2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200), 
(SESSIONID = 1), (DATABASE = wombat), (DRDAID = 
NF01.G90E-1097469790362120575{12}), Cleanup action starting

2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200), 
(SESSIONID = 1), (DATABASE = wombat), (DRDAID = 
NF01.G90E-1097469790362120575{12}), Failed Statement is: create table y(i 
int)

ERROR XSAI2: The conglomerate (129) requested does not exist.

at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:311)

at 
org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(B2IFactory.java:241)

at 
org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.java:484)

at 
org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction.java:389)

at 
org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1315)

at 
org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRowListImpl(TabInfoImpl.java:525)

at 
org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRow(TabInfoImpl.java:419)

at 
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptorNow(DataDictionaryImpl.java:1637)

at 
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(DataDictionaryImpl.java:1624)

at 
org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(CreateTableConstantAction.java:223)

at 
org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56)

at 
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361)

at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1160)

at 
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567)

at 
org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:158)

at 
org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:4395)

at 
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:645)

at 
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:236)

Cleanup action completed

Apache Derby Network Server - 10.2.0.0 alpha shutdown at 2006-03-31 
19:18:48.601 GMT


There is some relevant revison history:

At r 380672   I made some changes to the test and the test passed with client
At r 387611   I made some comment changes and accidently enabled one of the 
failing client cases.
At r 390481   I disabled the test for DERBY-1047 with client again, so the 
tests at 380672 (which passed) and the current test are the same.



With the following patch for  DERBY-1144 the test does not normally hang.  I 
don't know why and am a bit hesitant to check this patch in since it might be 
masking something serious.



Index: java/client/org/apache/derby/client/ClientPooledConnection.java

===

--- java/client/org/apache/derby/client/ClientPooledConnection.java
(revision 
387603)

+++ java/client/org/apache/derby/client/ClientPooledConnection.java(working 
copy)

@@ -172,11 +172,14 @@

 }
 createLogicalConnection();
 
+   
 if (!newPC_) {
-physicalConnection_.reset(logWriter_, user_, password_, ds_, 
false); // false means do not recompute
+// DERBY-1144 changed the last parameter of this method to true
+// to reset the connection state to the default on
+// PooledConnection.getConnection() otherwise the
+// isolation level was not correct and out of sync w

Re: Help with CTRL-M in test output on Windows

[David W. Van Couvering]

Thanks, Andrew.  I have this property set by default for new files I 
create, but it looks like it was never set for this existing output file.


I'll try the fix you suggest and see if it works.

David

Andrew McIntyre wrote:

On 3/31/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:


When I look at the diffs I have on some test output based on message
text changes, I get only the lines that have changed.  But in svn diff
it shows the old contents completely removed and new contents put in its
place, all with ^M characters at the end of each line.

Any advice on how to address this?  I would like reviewers to see the
actual changes made versus a global replace.



Sounds like it's missing the svn:eol-style native property in svn. I
think it might work to just set the property on a Windows machine,
remove the file and then svn up to restore it with the property added.
If that doesn't work, you'll need to commit the property change from a
Unix machine and then update your Windows checkout to get the correct
line-endings.

Also, its been mentioned before, but I'll mention it again in case
anyone missed it the first time. If you add the following to your
local ~/subversion/.config:

http://www.apache.org/dev/svn-eol-style.txt

then svn will automatically add the right property when new files are
added. You'll need to add *.out to this list as well.

andrew

Re: JDBC ResultSets from DatabaseMetaData

[Lance J. Andersen]

That's because it is not there in the public copy, just my working
copy.  Will be there in the PFD as well as the javadocs for these
interfaces.

It will be in the DatabaseMetaData chapter and  ResultSet chapter in
the ResultSetMetaData section.

regards
lance

Daniel John Debrunner wrote:

  Lance J. Andersen wrote:

  
  
This has been clarified in the JDBC 4.0 spec.

  
  
Great, I couldn't see anything related to this in the JDBC 4.0 proposed
final draft, do you have a section number?

Thanks,
Dan.


  

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[David W. Van Couvering]

Hi, Jeff.  I've been quiet on this comment because I didn't fully 
understand it.


I *think* what you're saying is that an interface can not be considered 
Stable or Unstable unless it's actually documented.  Is that right?


David

Jeff Levitt wrote:

From a documentation perspective, I think if we are
going to say on this page that items are stable AS
DOCUMENTED in the user documentation, then we also
need to put in some sort of requirement on this page
that says any changes made to the stability of an item
MUST be documented as well in order to be committed an
considered stable.  Its not stable if its not
documented and we are telling people that it is stable
as documented.  Agreed?

I think this is something that would be good to put in
to make sure that developers understand the importance
of documenting their work, whether its something new
or a change to something that exists, and that its not
just going to magically show up in the documentation
if they put it in the code (unless its javadoc) :)

--- "David W. Van Couvering"
<[EMAIL PROTECTED]> wrote:



Thanks for your comments, Kathey, and yes, it can
definitely wait a 
week.  It was just so quiet that I thought I'd do a
"ping" and see if 
there was more to come from everyone.


Responses below...

Kathey Marsden wrote:

I wish I had more time to look at this but  I 


think that  I would add


these things.
-  In general any documented behaviour is a


stable interface, unless


specifically documented  here or in the


documentation as unstable.

I'm not sure how to handle this.  What does it mean
to "incompatibly 
change" documented behavior?


Usually the behavior is in relation to a given
interface.  So perhaps in 
our definition of what it means to incompatibly
change an interface 
means you can't change the documented behavior of
that interface (e.g. 
the "contract" of that interface).


I think it's also fair to say that unless explicitly
called out in the 
table as otherwise, one can assume a publicly
documented interface is 
Stable.




-   Derby will at a minimum negotiate down to the


lower interface


revision level:
   -   When different versions of Derby client


and server are used


together (in the same or different JVM's)
   -  When different jvm versions are used on


client and server.

I think this is a solution that provides a guarantee
of stability to the 
client/server interfaces.  I can add this as a note,

however.

I think by calling out the *specific* interfaces
that the client depends 
upon (DRDA, metadata procedures, system stored
procedures, ???) and 
marking them as Stable or Private Stable is a Really
Good Idea in our 
attempts to provide the guarantee of client/server
compatiblity.  Note, 
for example, some of us newbies changing the
metadata procedures willy 
nilly because we were unaware of the impact on
compatibility.  Having 
these called out will make us all more conscious of
what we can and 
can't do within the system.




In the interface table I would add:
- Defaults returned by DatabaseMetaData methods   


  Stable

- Documented  defaults


   


Stable
- console output format for tools and network


server  Unstable

- System stored procedures


Stable

OK, I'll add these.  I think the console output
format for tools and 
server should actually be marked Private -- it's not
documented in the 
user documentation, and can change at any time.


Dumb question: are system stored procedures in the
user documentation? 
If not, perhaps they should be Private Stable rather
than Stable?  If 
they're not documented, what is driving the
requirement that they be 
stable - client/server compatibility?




Under notes  It would be good to mention:

.



OK




Could we wait a week for a vote?I think I need


to study this some more.


Thanks David for doing this.



Yes, sure, and you're welcome.

David



Kathey

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Rick Hillegas]

Kathey Marsden wrote:



I still need to think a lot about the whole major version boundary
thing.  It seems like we like solaris will be set at the same major
version for a very long time.   As I stated before I think for some
things a time based approach seems most appropriate. You can expect your
client to work with new servers for the next five years for example. We
should  not just leave users trying to figure out how to upgrade  their
server and all of their clients all in one night because we  bumped from
10 to 11.
 

This is quite puzzling. I've never worked for an engineering operation 
which could make this five-year guarantee. Personally, I don't know 
anyone who has this kind of foresight. Five years is the classic 
lifetime of a complex product before it needs an incompatible 
overhaul/rewrite. What happens to the clients released in the last year 
of that usable lifetime? Please provide more detail here.


Thanks,
-Rick

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[David W. Van Couvering]

I've updated the Wiki page to reflect some of this discussion and my 
sense of where things are ending up.  You can use the diff mechanism of 
the Wiki to see what's changed.


David

Kathey Marsden wrote:

Rick Hillegas wrote:



I think you may have already addressed the following issues in email,
but I don't see the results rolled onto the wiki page. Please pardon
my nitpicking. This kind of discussion turns me into a tiresome,
pedantic Mr. Hyde:

1) The cardinal rule. I recommend wordsmithing the cardinal rule: "The
goal is to allow any application written against the public interfaces
an older version of Derby can run, without any changes, against a
newer version of Derby." To me the following formulation reads better
"This is our goal: An application which ran against Derby yesterday
will run against a higher version of Derby tomorrow."



I prefer the original wording with only a small grammatical change to
instead of can.

"The goal is to allow any application written against the public
interfaces an older version of Derby to run, without any changes,
against a newer version of Derby."

It is good to think past tomorrow.



But is that really the cardinal rule? Maybe we really mean this: "This
is our goal: An application which runs against a Derby release today
will also run tomorrow against the next minor release. 



I  do not like this wording .It might seem to imply that you cannot
skip minor releases e.g. go from 10.l  to 10.3.
It might also seem to imply that you cannot  run a 10.1 client with a
10.3 server for example.  




We strive to minimize churn for applications migrating to the next
major release of Derby. However these migrations may entail
application changes."



The way  major releases are described in this mail is the way I have
seen them  in the past,  where we break upgrade,  client/server
compatibility and many other things  and it is like switching to a new
product, but I want better for the users of  Derby 10 when they switch
to 11.

I still need to think a lot about the whole major version boundary
thing.  It seems like we like solaris will be set at the same major
version for a very long time.   As I stated before I think for some
things a time based approach seems most appropriate. You can expect your
client to work with new servers for the next five years for example. We
should  not just leave users trying to figure out how to upgrade  their
server and all of their clients all in one night because we  bumped from
10 to 11.

If we expect upgrade=true to work from 10 to 11 we should expect

client/server compatibility to be maintained as well.
So either the time based approach or for major versions  have
compatibility with the previous and next  major versions.For example
with Derby 11 you can use Derby 10 or Derby 12, but not Derby 13.



2b) Our DRDA implementation may incorrectly transport datatypes not
recognized by DRDA. Conforming to the DRDA spec may mean removing this
transport capability and breaking applications which select the
unsupported datatypes.



Protocol has an impact on client JDBC, SQL  and even the ability to
connect and those cannot be broken.
Client and server can have version dependent behaviour to mitigate the
change to DRDA compliant behavior.




3) Client/server compatibility.

I would expect to find these rules spelled out on the wiki page. 





Yes I agree these should be spelled out because obviously different
readers can deduce different things.

Re: JDBC ResultSets from DatabaseMetaData

[Daniel John Debrunner]

Lance J. Andersen wrote:

> This has been clarified in the JDBC 4.0 spec.

Great, I couldn't see anything related to this in the JDBC 4.0 proposed
final draft, do you have a section number?

Thanks,
Dan.

Re: Help with CTRL-M in test output on Windows

[Andrew McIntyre]

On 3/31/06, David W. Van Couvering <[EMAIL PROTECTED]> wrote:
> When I look at the diffs I have on some test output based on message
> text changes, I get only the lines that have changed.  But in svn diff
> it shows the old contents completely removed and new contents put in its
> place, all with ^M characters at the end of each line.
>
> Any advice on how to address this?  I would like reviewers to see the
> actual changes made versus a global replace.

Sounds like it's missing the svn:eol-style native property in svn. I
think it might work to just set the property on a Windows machine,
remove the file and then svn up to restore it with the property added.
If that doesn't work, you'll need to commit the property change from a
Unix machine and then update your Windows checkout to get the correct
line-endings.

Also, its been mentioned before, but I'll mention it again in case
anyone missed it the first time. If you add the following to your
local ~/subversion/.config:

http://www.apache.org/dev/svn-eol-style.txt

then svn will automatically add the right property when new files are
added. You'll need to add *.out to this list as well.

andrew

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[David W. Van Couvering]

I don't know the specific bug and the impact.  My intuition says 
document the change.  But if it were a significant enough change, I 
might consider providing support for the old, broken behavior.  I hope 
that this is a discussion that can be had around this bug by the 
contributor and his/her reviewers.


David

Rick Hillegas wrote:
We already have to cross this bridge for the next release of Derby. 
DERBY-280 is a correctness bug, which while not fixed, was patched. This 
changes the behavior of a family of queries which were returning wrong 
results. What should we do:


1) Add and document a tracepoint allowing customers to get the previous 
incorrect behavior? Please say no. I think we all believe this is a 
crummy solution.
2) Document the changed behavior in the Release Notes. If an important 
customer complains, then we can evaluate how to satisfy that customer in 
a follow-on release.

3) Something else?

-Rick

David W. Van Couvering wrote:

I agree this sounds like a terrible model.  But we have to accept 
reality, we *are* going to have bugs.  And if we can't fix those bugs 
in a backward-compatible way, then it is more than likely that some 
Big Huge Customer will refuse to upgrade.  I saw that at Sybase as 
well. Perhaps the cost of supporting older codelines is ultimately a 
better choice for our product than the spaghetti of micro-compatbility 
if-statements and weird "behavior plugins" in the code.


I don't have an easy answer.  I agree we should strive for 
correctness, and perhaps we'll just have to cross that bridge when we 
come to it.  I think Rick's caveats are valuable, but I don't want 
them to be a loophole that we then use to feel we have more free rein 
to break compatibility.  But, saying that, knowing this lot I suspect 
we don't have to worry about this, you can't sneeze around here 
without someone worrying whether than sneeze was compatible with your 
last sneeze :)


David

Daniel John Debrunner wrote:


Rick Hillegas wrote:


Thanks, David. I think this discussion is raising some interesting 
issues.


David W. Van Couvering wrote:



2) Bug fixing policy.





I am glad that we are bothering to make these rules explicit. In a
previous life at Sybase, we solved this problem by adding special
tracepoints for big, important customers who relied on old, incorrect
behavior. As I recall, we didn't know up front who would object to a
correction. The tracepoints went into patch releases based on customer
dissatisfaction with the last minor release.

Do you think the Sybase model will work for us? Or do we need to add
tracepoints to the minor release as we fix the incorrect behavior? 
Maybe

it is not good enough to add a master tracepoint with the semantics
"Simulate all incorrect implementations of the standards fixed in this
release, X.y." Customers may want something more granular, say, a
tracepoint per obnoxious correction. Over time, these tracepoints will
pile up and the code will  become a more exciting pinball machine. What
are your thoughts?





I think it's a terrible model. This moves the project into a state where
the number of possible execution time modes will increase rapidly,
causing nightmares for those who have to support it or answer questions
on the user list.

For any change we as a community should be confident it is the correct
change.

[disclaimer - I was at Sybase during those times ]

Dan.

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Daniel John Debrunner]

Rick Hillegas wrote:

> We already have to cross this bridge for the next release of Derby.
> DERBY-280 is a correctness bug, which while not fixed, was patched. This
> changes the behavior of a family of queries which were returning wrong
> results. What should we do:
> 

> 2) Document the changed behavior in the Release Notes. If an important
> customer complains, then we can evaluate how to satisfy that customer in
> a follow-on release.

Remember this is open-source, there are no customers or "important
customers", only users and developers.

If a user doesn't like the solution they have at least two options:

   - get involved in the Derby developer community
   - patch the source

I prefer the first.

Dan.

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[David W. Van Couvering]

I'll let you go ponder, but I guess I don't fully understand.  It is a 
Bad Thing at any time to break client/server compatibility.  Hopefully 
we never have to do it.  I guess my only point, and I think the point of 
this Wiki, is that *when* we have to do it, we have to do it at a major 
release boundary, and we will document clearly that there is an 
incompatibility.


If we can make a change such that it only breaks compatibility with 
major release - 2 (e.g. the change in 12.0 works with 11.x clients but 
not with 10.x clients), that's great.  We can even agree to make this a 
policy.  But to me that doesn't meant we can make the change at a minor 
release boundary.


David

Kathey Marsden wrote:

David W. Van Couvering wrote:



I also wanted to respond to the suggestion that compatibility be
guaranteed for a given time period, versus tying it to release levels.

If we don't *require* that major releases be incompatible, but simply
say this is the only time you *can* do it, then I don't see what the
issue is.  We can do as many major releases as we want in five years.

If we want to also provide a guarantee that any feature will not be
broken for five years, that's OK, but I think it would be odd to break
compatibility in a minor release just because it's been five years...

Or am I not fully understanding your proposal, Kathey?



It is not a proposal, kind of more of a typical user requirement.   I
need to think some more on how to that might be implemented from a
product perspective.  Perhaps the  guarantee of   client/server
compatibility with the previous and next major release  would be a  
more realistic approach.  Certainly the kind of jump suggested where

there is no compatibility between v10 and v11 clients and servers would
be a very hard move for users. Upgrade is another area I need to 
understand better across major version boundaries.  Anyway, all just

random thoughts at this point.   As I said I need to think more. I will
study your proposal and all this just as soon as I can and get back.

Kathey

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Rick Hillegas]

We already have to cross this bridge for the next release of Derby. 
DERBY-280 is a correctness bug, which while not fixed, was patched. This 
changes the behavior of a family of queries which were returning wrong 
results. What should we do:


1) Add and document a tracepoint allowing customers to get the previous 
incorrect behavior? Please say no. I think we all believe this is a 
crummy solution.
2) Document the changed behavior in the Release Notes. If an important 
customer complains, then we can evaluate how to satisfy that customer in 
a follow-on release.

3) Something else?

-Rick

David W. Van Couvering wrote:

I agree this sounds like a terrible model.  But we have to accept 
reality, we *are* going to have bugs.  And if we can't fix those bugs 
in a backward-compatible way, then it is more than likely that some 
Big Huge Customer will refuse to upgrade.  I saw that at Sybase as 
well. Perhaps the cost of supporting older codelines is ultimately a 
better choice for our product than the spaghetti of micro-compatbility 
if-statements and weird "behavior plugins" in the code.


I don't have an easy answer.  I agree we should strive for 
correctness, and perhaps we'll just have to cross that bridge when we 
come to it.  I think Rick's caveats are valuable, but I don't want 
them to be a loophole that we then use to feel we have more free rein 
to break compatibility.  But, saying that, knowing this lot I suspect 
we don't have to worry about this, you can't sneeze around here 
without someone worrying whether than sneeze was compatible with your 
last sneeze :)


David

Daniel John Debrunner wrote:


Rick Hillegas wrote:


Thanks, David. I think this discussion is raising some interesting 
issues.


David W. Van Couvering wrote:



2) Bug fixing policy.





I am glad that we are bothering to make these rules explicit. In a
previous life at Sybase, we solved this problem by adding special
tracepoints for big, important customers who relied on old, incorrect
behavior. As I recall, we didn't know up front who would object to a
correction. The tracepoints went into patch releases based on customer
dissatisfaction with the last minor release.

Do you think the Sybase model will work for us? Or do we need to add
tracepoints to the minor release as we fix the incorrect behavior? 
Maybe

it is not good enough to add a master tracepoint with the semantics
"Simulate all incorrect implementations of the standards fixed in this
release, X.y." Customers may want something more granular, say, a
tracepoint per obnoxious correction. Over time, these tracepoints will
pile up and the code will  become a more exciting pinball machine. What
are your thoughts?




I think it's a terrible model. This moves the project into a state where
the number of possible execution time modes will increase rapidly,
causing nightmares for those who have to support it or answer questions
on the user list.

For any change we as a community should be confident it is the correct
change.

[disclaimer - I was at Sybase during those times ]

Dan.

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Kathey Marsden]

David W. Van Couvering wrote:

> I also wanted to respond to the suggestion that compatibility be
> guaranteed for a given time period, versus tying it to release levels.
>
> If we don't *require* that major releases be incompatible, but simply
> say this is the only time you *can* do it, then I don't see what the
> issue is.  We can do as many major releases as we want in five years.
>
> If we want to also provide a guarantee that any feature will not be
> broken for five years, that's OK, but I think it would be odd to break
> compatibility in a minor release just because it's been five years...
>
> Or am I not fully understanding your proposal, Kathey?

It is not a proposal, kind of more of a typical user requirement.   I
need to think some more on how to that might be implemented from a
product perspective.  Perhaps the  guarantee of   client/server
compatibility with the previous and next major release  would be a  
more realistic approach.  Certainly the kind of jump suggested where
there is no compatibility between v10 and v11 clients and servers would
be a very hard move for users. Upgrade is another area I need to 
understand better across major version boundaries.  Anyway, all just
random thoughts at this point.   As I said I need to think more. I will
study your proposal and all this just as soon as I can and get back.

Kathey

Re: Another good article for Apache Derby

[Jean T. Anderson]

David W. Van Couvering wrote:
> Hm, I didn't add that :)

oh -- sorry! it was John Embretsen. (Thanks, John!)

 -jean

> Jean T. Anderson wrote:
>> David W. Van Couvering wrote:
>>> This talks about Java DB, Sun's distribution of Apache Derby, but I
>>> thought the tutorial/example for how to build a desktop app using
>>> NetBeans and Java DB still would be useful to Derby users.  Jean, if you
>>> agree, perhaps we can put this on the web site?
>>>
>>> http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javadb/
>>
>> I noticed your Wiki entry for it at
>> http://wiki.apache.org/db-derby/DerbyInstruction#Examples -- thanks for
>> adding that.
...

Re: Another good article for Apache Derby

[David W. Van Couvering]

Hm, I didn't add that :)

Jean T. Anderson wrote:

David W. Van Couvering wrote:


This talks about Java DB, Sun's distribution of Apache Derby, but I
thought the tutorial/example for how to build a desktop app using
NetBeans and Java DB still would be useful to Derby users.  Jean, if you
agree, perhaps we can put this on the web site?

http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javadb/



I noticed your Wiki entry for it at
http://wiki.apache.org/db-derby/DerbyInstruction#Examples -- thanks for
adding that.

Right now
http://db.apache.org/derby/quick_start.html#Next+Steps+For+Users has
this list, which sometimes links to the Wiki:

   * Examples
   * Demos
   * How to use Derby with other products
   o Database Tools
 + DdlUtils
   o IDEs
 + Eclipse
 + JBuilder
 + NetBeans
   o Data and Object/Relational Mappers
 + iBATIS
 + JPOX JDO
 + Torque
   o Web Applications
 + Geronimo
 + Tomcat 5.0
 + Tomcat 5.5
 + WebSphere

How about providing specific links for Examples and Demos?

   * Examples
  o Using Java DB in Desktop Applications
   * Demos
  o Database-in-a-browser

What else should be listed?

One minor scheduling note:  I'll be gone all next week. These edits to
the web page are actually pretty simple, once people decide what should
be listed. Would you or another committer be willing to do the edits and
publish the site? I'd be more than happy to work with you (or whomever)
on the forrest logistics.

 -jean

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[David W. Van Couvering]

I also wanted to respond to the suggestion that compatibility be 
guaranteed for a given time period, versus tying it to release levels.


If we don't *require* that major releases be incompatible, but simply 
say this is the only time you *can* do it, then I don't see what the 
issue is.  We can do as many major releases as we want in five years.


If we want to also provide a guarantee that any feature will not be 
broken for five years, that's OK, but I think it would be odd to break 
compatibility in a minor release just because it's been five years...


Or am I not fully understanding your proposal, Kathey?

David

Kathey Marsden wrote:

Rick Hillegas wrote:



I think you may have already addressed the following issues in email,
but I don't see the results rolled onto the wiki page. Please pardon
my nitpicking. This kind of discussion turns me into a tiresome,
pedantic Mr. Hyde:

1) The cardinal rule. I recommend wordsmithing the cardinal rule: "The
goal is to allow any application written against the public interfaces
an older version of Derby can run, without any changes, against a
newer version of Derby." To me the following formulation reads better
"This is our goal: An application which ran against Derby yesterday
will run against a higher version of Derby tomorrow."



I prefer the original wording with only a small grammatical change to
instead of can.

"The goal is to allow any application written against the public
interfaces an older version of Derby to run, without any changes,
against a newer version of Derby."

It is good to think past tomorrow.



But is that really the cardinal rule? Maybe we really mean this: "This
is our goal: An application which runs against a Derby release today
will also run tomorrow against the next minor release. 



I  do not like this wording .It might seem to imply that you cannot
skip minor releases e.g. go from 10.l  to 10.3.
It might also seem to imply that you cannot  run a 10.1 client with a
10.3 server for example.  




We strive to minimize churn for applications migrating to the next
major release of Derby. However these migrations may entail
application changes."



The way  major releases are described in this mail is the way I have
seen them  in the past,  where we break upgrade,  client/server
compatibility and many other things  and it is like switching to a new
product, but I want better for the users of  Derby 10 when they switch
to 11.

I still need to think a lot about the whole major version boundary
thing.  It seems like we like solaris will be set at the same major
version for a very long time.   As I stated before I think for some
things a time based approach seems most appropriate. You can expect your
client to work with new servers for the next five years for example. We
should  not just leave users trying to figure out how to upgrade  their
server and all of their clients all in one night because we  bumped from
10 to 11.

If we expect upgrade=true to work from 10 to 11 we should expect

client/server compatibility to be maintained as well.
So either the time based approach or for major versions  have
compatibility with the previous and next  major versions.For example
with Derby 11 you can use Derby 10 or Derby 12, but not Derby 13.



2b) Our DRDA implementation may incorrectly transport datatypes not
recognized by DRDA. Conforming to the DRDA spec may mean removing this
transport capability and breaking applications which select the
unsupported datatypes.



Protocol has an impact on client JDBC, SQL  and even the ability to
connect and those cannot be broken.
Client and server can have version dependent behaviour to mitigate the
change to DRDA compliant behavior.




3) Client/server compatibility.

I would expect to find these rules spelled out on the wiki page. 





Yes I agree these should be spelled out because obviously different
readers can deduce different things.

Help with CTRL-M in test output on Windows

[David W. Van Couvering]

When I look at the diffs I have on some test output based on message 
text changes, I get only the lines that have changed.  But in svn diff 
it shows the old contents completely removed and new contents put in its 
place, all with ^M characters at the end of each line.


Any advice on how to address this?  I would like reviewers to see the 
actual changes made versus a global replace.


Thanks,

David

XML support in 10.2 - selecting values of an XML element in an order by query?

[Susan Cline]

Hi,

I've looked at some of the tests for the XML support but I am still 
confused if this is possible or not.  Given a table created with
an xml column:

create table xmlTab (id integer, xml_col xml);

Containing these two xml documents:


1
Susan
Cline



2
Apache
User


I'd like to come up with a query that returns results ordered by 
firstname (or any other element in the XML document.)

So, in this example the document with the id of "2" would appear in 
the result of the select before the document with the id of "1".  

If this query is possible, can someone please post an example?

The other question I have is which other supporting jar files I need 
to issue this query?  I think I need the following (but can someone 
confirm if specific versions are required?):

xml-apis.jar 
xercesImpl.jar
xalan.jar

Thanks,

Susan

Re: Another good article for Apache Derby

[Jean T. Anderson]

David W. Van Couvering wrote:
> This talks about Java DB, Sun's distribution of Apache Derby, but I
> thought the tutorial/example for how to build a desktop app using
> NetBeans and Java DB still would be useful to Derby users.  Jean, if you
> agree, perhaps we can put this on the web site?
> 
> http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javadb/

I noticed your Wiki entry for it at
http://wiki.apache.org/db-derby/DerbyInstruction#Examples -- thanks for
adding that.

Right now
http://db.apache.org/derby/quick_start.html#Next+Steps+For+Users has
this list, which sometimes links to the Wiki:

   * Examples
   * Demos
   * How to use Derby with other products
   o Database Tools
 + DdlUtils
   o IDEs
 + Eclipse
 + JBuilder
 + NetBeans
   o Data and Object/Relational Mappers
 + iBATIS
 + JPOX JDO
 + Torque
   o Web Applications
 + Geronimo
 + Tomcat 5.0
 + Tomcat 5.5
 + WebSphere

How about providing specific links for Examples and Demos?

   * Examples
  o Using Java DB in Desktop Applications
   * Demos
  o Database-in-a-browser

What else should be listed?

One minor scheduling note:  I'll be gone all next week. These edits to
the web page are actually pretty simple, once people decide what should
be listed. Would you or another committer be willing to do the edits and
publish the site? I'd be more than happy to work with you (or whomever)
on the forrest logistics.

 -jean

Re: Does in-place compress really defragment?

[Manjula G Kutty]

Øystein Grøvlen wrote:


I tried an experiment with on-line compress and it seems like no space
is freed unless I delete records at the end of the heap:

1. Deleted every third record of a table
2. Inline compress with purge&defragment. File size did not change
3. Deleted every second of the remaining records
4. Inline compress with purge&defragment. File size did not change
5. Deleted the last third of the remaining records
6. Inline compress with purge&defragment. File size reduced by 1/3. 
7. Deleted first half of the remaining records

8. Inline compress with purge&defragment. File size did not change

Is this how it is supposed to be?  I would have thought that each
compress would defragment the table and free space, but it seems like
only empty space at the end of a table is freed.  Trace of what I did
below.  (There are 1536 records in t.  The records have primary keys
in range [0,1535] and was inserted in sorted order on primary key.
For all records j==mod(i,3).)

--
Øystein

ij> create table t1 (i integer primary key, j integer, c varchar(300));
0 rows inserted/updated/deleted
ij> insert into t1 select * from t;
1536 rows inserted/updated/deleted
ij> delete from t1 where j=1;
512 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> delete from t1 where j=2;
512 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> delete from t1 where i > 1024;
170 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> delete from t1 where i < 512;
171 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> 



 


Hi,

I have used inplace compression in my test , which is a java program,. I 
called inpleace compression every one hour intervel and I'm deleting 
rows randomly. So I'm sure that they are not getting deleted from the 
bottom of the table. I 'm seeing notable increase in the free space 
after using inplace compression.


Thanks
Manjula

Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

[David W. Van Couvering]

Kathey Marsden wrote:

David W. Van Couvering wrote:



This is an example where we find our code throwing the wrong SQL
State, but are we allowed to fix it?  Lance says yes.  Others
providing support for customers say (I think) no.

This ties into the discussion about the stability classification for
SQL States.  If we mark it as Stable, then we can't change this.  If
we mark it as Unstable, then we can.

Comments, thoughts?



 I think it is ok and good to change an SQLState or any behaviour  to
fix a bug if our current behaviour is non-standard.


OK, I can add that as a note to the row for SQL States.


The question becomes what level of notification do we need to users and
what strategy will we give them to  mitigate the impact of the change?

In this case,  I think  this is  new functionality,  so all very good it
is caught now and dealt with.   If it were existing functionality, I
think that  user notification would be very important.  I think we need
some way of  marking changes that might affect existing users.  I made
this proposal a while back for Jira that I think would help:

http://www.nabble.com/New-Jira-Checkbox-proposal-t1200029.html#a3166517

Feedback from Andrew indicated that components  are preferred to
checkboxes but being able to query Jira for changes that might affect
users I think is important.  What do people think of adding components
for "Release Note Needed", "Existing Application Impact"  and "Regression" ?


I think notification is great.  I don't understand why what you are 
suggesting should be "components" they really seem to me to make sense 
as checkboxes -- how are these "components" of the system?  Andrew, can 
you explain?


David




Kathey

Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

[David W. Van Couvering]

Daniel John Debrunner wrote:

David W. Van Couvering wrote:



This is an example where we find our code throwing the wrong SQL State,
but are we allowed to fix it?  Lance says yes.  Others providing support
for customers say (I think) no.



Well in this case the functionality has never been in an official
release so I'm sure it can change.



This ties into the discussion about the stability classification for SQL
States.  If we mark it as Stable, then we can't change this.  If we mark
it as Unstable, then we can.



I'm beginning to think that the classifications are too broad. I think
there are some exception SQLStates that should should not change and
some that could. In my mind it depends on if a application could be
using the old state in a reasonable way. Very subjective of course, not
sure if we could re-write into a more formal form.


I don't think we can.  One suggestion I received offline was to mark the 
standard SQL States as Standard and the Derby-specific SQL States as 
Unstable.  And then I think I can add a note to the SQLState column that 
changes may be permitted in some circumstances, and will be decided on a 
case-by-case basis by the community.




Another example if JDBC deprecates some method then how is that
represented in the table?


I don't think it is.  I'm not sure if this table is intended for that 
level of detail.  Do you think it's needed?




Dan.

Re: [web] Derby site reorganization (resend)

[Jean T. Anderson]

Daniel John Debrunner wrote:
> http://db.apache.org/derby/index.html
> 
> On the home page we have the "Quick Links" section but in my mind they
> are not "quick" as I have to expand to see the list before I can click
> on them.
> 
> Can we just get them as a simple list, or even expanded by default?

I asked forrest about expanding by default some time ago and was told we
could do that in the "next release". I'll check the archives and see if
that meant 0.7 (what we use now) or 0.8. If default expansion isn't
available yet, then a simple list would work, but I would recommend
removing the ASF and DB links to keep the list short:

  Apache Derby
  Charter
  Quick Start
  ASF <- remove
  Apache DB Project   <- remove
  Derby Wiki
  License
  FAQS

what do you think?

The other tab with lots of subcategories is the Resources tab. If
default expansion isn't possible, would it be best to just list everything?

thanks for the feedback,

 -jean

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[David W. Van Couvering]

I agree this sounds like a terrible model.  But we have to accept 
reality, we *are* going to have bugs.  And if we can't fix those bugs in 
a backward-compatible way, then it is more than likely that some Big 
Huge Customer will refuse to upgrade.  I saw that at Sybase as well. 
Perhaps the cost of supporting older codelines is ultimately a better 
choice for our product than the spaghetti of micro-compatbility 
if-statements and weird "behavior plugins" in the code.


I don't have an easy answer.  I agree we should strive for correctness, 
and perhaps we'll just have to cross that bridge when we come to it.  I 
think Rick's caveats are valuable, but I don't want them to be a 
loophole that we then use to feel we have more free rein to break 
compatibility.  But, saying that, knowing this lot I suspect we don't 
have to worry about this, you can't sneeze around here without someone 
worrying whether than sneeze was compatible with your last sneeze :)


David

Daniel John Debrunner wrote:

Rick Hillegas wrote:



Thanks, David. I think this discussion is raising some interesting issues.

David W. Van Couvering wrote:



2) Bug fixing policy.





I am glad that we are bothering to make these rules explicit. In a
previous life at Sybase, we solved this problem by adding special
tracepoints for big, important customers who relied on old, incorrect
behavior. As I recall, we didn't know up front who would object to a
correction. The tracepoints went into patch releases based on customer
dissatisfaction with the last minor release.

Do you think the Sybase model will work for us? Or do we need to add
tracepoints to the minor release as we fix the incorrect behavior? Maybe
it is not good enough to add a master tracepoint with the semantics
"Simulate all incorrect implementations of the standards fixed in this
release, X.y." Customers may want something more granular, say, a
tracepoint per obnoxious correction. Over time, these tracepoints will
pile up and the code will  become a more exciting pinball machine. What
are your thoughts?



I think it's a terrible model. This moves the project into a state where
the number of possible execution time modes will increase rapidly,
causing nightmares for those who have to support it or answer questions
on the user list.

For any change we as a community should be confident it is the correct
change.

[disclaimer - I was at Sybase during those times ]

Dan.

Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

[Kathey Marsden]

Kathey Marsden wrote:

>  What do people think of adding components
>for "Release Note Needed", "Existing Application Impact"  and "Regression" ?
>
>
>  
>
Oops, should have made this a separate  thread.  I will do that some
time soon unless someone else wants to start one.


Kathey

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[David W. Van Couvering]

I think we should clarify the page, then.  My intent was not that a 
major release *will* be incompatible.  My intent was that a major 
release *might* be incompatible, whereas minor releases can *not* be 
incompatible.


David

Daniel John Debrunner wrote:

Kathey Marsden wrote:



Rick Hillegas wrote:




I think you may have already addressed the following issues in email,
but I don't see the results rolled onto the wiki page. Please pardon
my nitpicking. This kind of discussion turns me into a tiresome,
pedantic Mr. Hyde:

1) The cardinal rule. I recommend wordsmithing the cardinal rule: "The
goal is to allow any application written against the public interfaces
an older version of Derby can run, without any changes, against a
newer version of Derby." To me the following formulation reads better
"This is our goal: An application which ran against Derby yesterday
will run against a higher version of Derby tomorrow."



I prefer the original wording with only a small grammatical change to
instead of can.

"The goal is to allow any application written against the public
interfaces an older version of Derby to run, without any changes,
against a newer version of Derby."

It is good to think past tomorrow.



+1

The push towards allowing a major release to change things worries me.
It may be that we need to do this from time to time, but it should not
be the primary goal.
Dan.

Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

[Kathey Marsden]

David W. Van Couvering wrote:

> This is an example where we find our code throwing the wrong SQL
> State, but are we allowed to fix it?  Lance says yes.  Others
> providing support for customers say (I think) no.
>
> This ties into the discussion about the stability classification for
> SQL States.  If we mark it as Stable, then we can't change this.  If
> we mark it as Unstable, then we can.
>
> Comments, thoughts?

 I think it is ok and good to change an SQLState or any behaviour  to
fix a bug if our current behaviour is non-standard.
The question becomes what level of notification do we need to users and
what strategy will we give them to  mitigate the impact of the change?

In this case,  I think  this is  new functionality,  so all very good it
is caught now and dealt with.   If it were existing functionality, I
think that  user notification would be very important.  I think we need
some way of  marking changes that might affect existing users.  I made
this proposal a while back for Jira that I think would help:

http://www.nabble.com/New-Jira-Checkbox-proposal-t1200029.html#a3166517

Feedback from Andrew indicated that components  are preferred to
checkboxes but being able to query Jira for changes that might affect
users I think is important.  What do people think of adding components
for "Release Note Needed", "Existing Application Impact"  and "Regression" ?


Kathey

Re: Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

[Daniel John Debrunner]

David W. Van Couvering wrote:

> This is an example where we find our code throwing the wrong SQL State,
> but are we allowed to fix it?  Lance says yes.  Others providing support
> for customers say (I think) no.

Well in this case the functionality has never been in an official
release so I'm sure it can change.

> 
> This ties into the discussion about the stability classification for SQL
> States.  If we mark it as Stable, then we can't change this.  If we mark
> it as Unstable, then we can.

I'm beginning to think that the classifications are too broad. I think
there are some exception SQLStates that should should not change and
some that could. In my mind it depends on if a application could be
using the old state in a reasonable way. Very subjective of course, not
sure if we could re-write into a more formal form.

Another example if JDBC deprecates some method then how is that
represented in the table?

Dan.

Re: [web] Derby site reorganization (resend)

[Daniel John Debrunner]

http://db.apache.org/derby/index.html

On the home page we have the "Quick Links" section but in my mind they
are not "quick" as I have to expand to see the list before I can click
on them.

Can we just get them as a simple list, or even expanded by default?

Thanks,
Dan.

Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)

[David W. Van Couvering]

This is an example where we find our code throwing the wrong SQL State, 
but are we allowed to fix it?  Lance says yes.  Others providing support 
for customers say (I think) no.


This ties into the discussion about the stability classification for SQL 
States.  If we mark it as Stable, then we can't change this.  If we mark 
it as Unstable, then we can.


Comments, thoughts?

David

Andreas Korneliussen (JIRA) wrote:

 [ http://issues.apache.org/jira/browse/DERBY-1172?page=all ]

Andreas Korneliussen updated DERBY-1172:


Attachment: DERBY-1172.diff
DERBY-1172.stat

The attached patch addresses the bug by catching and rethrowing. It also 
extends jdbcapi/HoldabilityTest.junit with two testcases which verfies that the 
correct exceptions is given.




incorrect error message in updateRow() after a commit on a held scroll 
insensitive resultset


Key: DERBY-1172
URL: http://issues.apache.org/jira/browse/DERBY-1172
Project: Derby
   Type: Bug
 Components: SQL
   Versions: 10.2.0.0
   Reporter: Andreas Korneliussen
   Assignee: Andreas Korneliussen
   Priority: Minor
Attachments: DERBY-1172.diff, DERBY-1172.stat

If an application does updateRow() right after a commit on a held cursor, 
(without repositioning the cursor), an incorrect error message is given if the 
ResultSet is of type TYPE_SCROLL_INSENSITIVE.
"SQL 2003, Part 2: Foundation (SQL/Foundation) p 827,
paragraph numbered 6):
6)If CR is a holdable cursor and a has not been
 issued against CR within the current SQL- transaction,then an
 exception condition is raised: invalid cursor state .
and that exception has state 24000"
Currently, if the ResultSet is of type TYPE_SCROLL_INSENSITIVE, it fails with
SQL Exception: The scan is not positioned. state: XSCH7 : code=2
If the ResultSet is of type TYPE_FORWARD_ONLY, it gives the correct error 
message:
SQL Exception: Invalid cursor state - no current row. state: 24000 : code=2
The first exception is given from the store layer. The SQL layer seems to catch 
the store exception and rethrow a new exception with correct SQL state and 
error message. However this is not done in TableScanResultset.getRowLocation(), 
which is used by scrollinsensitve cursors.
A fix could be to add this logic into TableScanResultset.getRowLocation(). Or 
alternatively, make the store layer throw the expected exception, and remove 
logic to rethrow the exception.

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Daniel John Debrunner]

Rick Hillegas wrote:

> Thanks, David. I think this discussion is raising some interesting issues.
> 
> David W. Van Couvering wrote:
> 
>>
>>>
>>> 2) Bug fixing policy.
>>>

> I am glad that we are bothering to make these rules explicit. In a
> previous life at Sybase, we solved this problem by adding special
> tracepoints for big, important customers who relied on old, incorrect
> behavior. As I recall, we didn't know up front who would object to a
> correction. The tracepoints went into patch releases based on customer
> dissatisfaction with the last minor release.
> 
> Do you think the Sybase model will work for us? Or do we need to add
> tracepoints to the minor release as we fix the incorrect behavior? Maybe
> it is not good enough to add a master tracepoint with the semantics
> "Simulate all incorrect implementations of the standards fixed in this
> release, X.y." Customers may want something more granular, say, a
> tracepoint per obnoxious correction. Over time, these tracepoints will
> pile up and the code will  become a more exciting pinball machine. What
> are your thoughts?

I think it's a terrible model. This moves the project into a state where
the number of possible execution time modes will increase rapidly,
causing nightmares for those who have to support it or answer questions
on the user list.

For any change we as a community should be confident it is the correct
change.

[disclaimer - I was at Sybase during those times ]

Dan.

Another good article for Apache Derby

[David W. Van Couvering]

This talks about Java DB, Sun's distribution of Apache Derby, but I 
thought the tutorial/example for how to build a desktop app using 
NetBeans and Java DB still would be useful to Derby users.  Jean, if you 
agree, perhaps we can put this on the web site?


http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javadb/

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Daniel John Debrunner]

Kathey Marsden wrote:

> Rick Hillegas wrote:
> 
> 
>>I think you may have already addressed the following issues in email,
>>but I don't see the results rolled onto the wiki page. Please pardon
>>my nitpicking. This kind of discussion turns me into a tiresome,
>>pedantic Mr. Hyde:
>>
>>1) The cardinal rule. I recommend wordsmithing the cardinal rule: "The
>>goal is to allow any application written against the public interfaces
>>an older version of Derby can run, without any changes, against a
>>newer version of Derby." To me the following formulation reads better
>>"This is our goal: An application which ran against Derby yesterday
>>will run against a higher version of Derby tomorrow."
>>
> 
> I prefer the original wording with only a small grammatical change to
> instead of can.
> 
> "The goal is to allow any application written against the public
> interfaces an older version of Derby to run, without any changes,
> against a newer version of Derby."
> 
> It is good to think past tomorrow.

+1

The push towards allowing a major release to change things worries me.
It may be that we need to do this from time to time, but it should not
be the primary goal.
Dan.

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Rick Hillegas]

Thanks, David. I think this discussion is raising some interesting issues.

David W. Van Couvering wrote:





2) Bug fixing policy.

I think that the Exceptions section should say explicitly that "It is 
OK for minor releases to fix bugs in our implementation of the 
standards, even if those fixes break existing applications."  
Bugfixes can and do break applications and so violate the cardinal 
rule. Here are some more examples:


2a) Wrong query results. The correct results may break applications 
which are either unaware of the problem or which have already written 
compensatory logic to patch over our error. Correct results may slow 
down the query's performance and the customer may consider this 
degradation intolerable.




Ooh.  I can tell you speak from experience.  I would actually argue 
that this is not acceptable.  You can't just break applications 
without warning.  What I have seen in the past is you provide the user 
to enable the old or new behavior through some kind of flag, e.g. 
derby.use.old.broken.behavior or derby.use.new.fixed.behavior 



I am glad that we are bothering to make these rules explicit. In a 
previous life at Sybase, we solved this problem by adding special 
tracepoints for big, important customers who relied on old, incorrect 
behavior. As I recall, we didn't know up front who would object to a 
correction. The tracepoints went into patch releases based on customer 
dissatisfaction with the last minor release.


Do you think the Sybase model will work for us? Or do we need to add 
tracepoints to the minor release as we fix the incorrect behavior? Maybe 
it is not good enough to add a master tracepoint with the semantics 
"Simulate all incorrect implementations of the standards fixed in this 
release, X.y." Customers may want something more granular, say, a 
tracepoint per obnoxious correction. Over time, these tracepoints will 
pile up and the code will  become a more exciting pinball machine. What 
are your thoughts?




2b) Our DRDA implementation may incorrectly transport datatypes not 
recognized by DRDA. Conforming to the DRDA spec may mean removing 
this transport capability and breaking applications which select the 
unsupported datatypes.




I think it would be unacceptable to remove unsupported datatypes, even 
if they are not spec compliant.  Again, you use versioning and 
capabilities negotiation to change in a compatible way.  For example, 
if someone has an itch to support a network client that can only 
handle the types specified in DRDA, and the network client today 
supports non-standard types, then we should provide an option to run 
in "standard-DRDA" mode and disable those types.


If we want to add new, non-standard types, then we should only support 
these types if the client explicitly says it can handle them.


I'm happy with this approach. I would like to see the wiki state these 
rules explicitly.







3) Client/server compatibility.

I would expect to find these rules spelled out on the wiki page. It 
is not clear to me that you can deduce client/server compatibility 
from the cardinal rule. Are these the rules?



I did add a note based on Kathey's comments.  I think you *can* 
achieve this by declaring the right interfaces as Stable or Private 
Stable, but I agree it's good to call it out.


Thanks.





3a) A major release number defines a family of compatible Derby 
clients and servers. Derby clients and servers can interoperate 
provided that they share the same major release number. Say that an 
application currently runs using a client and server from the same 
family. The application will continue to run if the client upgrades 
to the next minor release. The application will also run if the 
server upgrades to the next minor release.


3b) We strive to minimize incompatiblities across release families. 
However, we do not guarantee that a client will interoperate with a 
server having a different major release number. If an application 
upgrades its client to a new major release, the server may have to 
upgrade to the new release family too. Similarly, if an application 
upgrades its server to a new major release, the client may need to 
upgrade too.




I think this is implied in the definition of Stable and Private Stable 
interfaces, and by ensuring that all interfaces that the network 
client depends upon are marked as either Stable or Private Stable.


I can imagine us providing this kind of wording in our documentation, 
but I am not sure if it is required here, I think it's already covered.


I think your wording does add some clarity about when changes may 
occur, and I may add that to the note about this that I copied from 
Kathey's email onto the Wiki page.


Thanks.

[jira] Commented: (DERBY-940) Add JDBC 4 Wrapper support

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-940?page=comments#action_12372694 ] 

Kristian Waagan commented on DERBY-940:
---

I only had a look at the test code for CallableStatementTest.java.

I have the following comments (also see the separate comment at the end):
1) Tests should be small, and you should consider splitting your single test 
into two. This should be easy, as you have already marked parts of the test 
code "Case1" and "Case2".
2) Use descriptive test method names. Long method names are not frowned upon in 
JUnit :)
3) Remove double spaces in comments (nit-pick).
4) Consider moving the try-catch block for cStmt.unwrap (Case2) into the else 
to more clearly indicate were the exception is expected to be thrown. 
5) Using SQLState is not encouraged, as it is not part of the public API. As I 
understand, you can either hardcore the SQL states to be checked for, create 
you own local constants, or use the newly created file 
'functionTests/util/SQLStateConstants.java'. Also, instead of throwing an 
exception, you can use assertSQLState (from BaseJDBCTestCase).

My last separate comment might need some feedback from others, so I guess you 
can ignore it for now. It is about the "skip if running under DerbyNetClient" 
issue. What is done with the current approach, is that the test passes even 
though nothing is tested. This is in general not good. Another approach would 
be to only add this test to the suite when running under embedded. Since we 
don't keep count of the number of tests run in JUnit, it doesn't matter too 
much now, but by putting logic for skipping the test in the test method itself 
it can be easily forgotten.

Here is a suggestion on how this could have been done in the suite-method, 
which requires that the tests that need special handling are renamed:
TestSuite suite = new TestSuite(CallableStatementTest.class, "suitename");
if (!usingDerbyNetClient()) {
suite.addTest("specialTestWrapperSupport1"); // Name must not start with 
"test"
suite.addTest("specialTestWrapperSupport2");
}
return suite;

Any opinions on this?

> Add JDBC 4 Wrapper support
> --
>
>  Key: DERBY-940
>  URL: http://issues.apache.org/jira/browse/DERBY-940
>  Project: Derby
> Type: New Feature
>   Components: JDBC
> Reporter: Rick Hillegas
> Assignee: V.Narayanan
>  Fix For: 10.2.0.0
>  Attachments: DERBY940_embedded.html, wrapper_ver1_embedded.diff, 
> wrapper_ver1_embedded.stat, wrapper_ver2_embedded.diff, 
> wrapper_ver2_embedded.stat, wrapper_ver3_embedded.diff, 
> wrapper_ver3_embedded.stat
>
> As described in the JDBC 4 spec, sections 21 and 3.1.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Should we vote on it? (was Re: Discussion (in preparation for a vote) on interface stability table)

[Kathey Marsden]

Rick Hillegas wrote:

> I think you may have already addressed the following issues in email,
> but I don't see the results rolled onto the wiki page. Please pardon
> my nitpicking. This kind of discussion turns me into a tiresome,
> pedantic Mr. Hyde:
>
> 1) The cardinal rule. I recommend wordsmithing the cardinal rule: "The
> goal is to allow any application written against the public interfaces
> an older version of Derby can run, without any changes, against a
> newer version of Derby." To me the following formulation reads better
> "This is our goal: An application which ran against Derby yesterday
> will run against a higher version of Derby tomorrow."
>
I prefer the original wording with only a small grammatical change to
instead of can.

"The goal is to allow any application written against the public
interfaces an older version of Derby to run, without any changes,
against a newer version of Derby."

It is good to think past tomorrow.

> But is that really the cardinal rule? Maybe we really mean this: "This
> is our goal: An application which runs against a Derby release today
> will also run tomorrow against the next minor release. 

I  do not like this wording .It might seem to imply that you cannot
skip minor releases e.g. go from 10.l  to 10.3.
It might also seem to imply that you cannot  run a 10.1 client with a
10.3 server for example.  

> We strive to minimize churn for applications migrating to the next
> major release of Derby. However these migrations may entail
> application changes."
>
The way  major releases are described in this mail is the way I have
seen them  in the past,  where we break upgrade,  client/server
compatibility and many other things  and it is like switching to a new
product, but I want better for the users of  Derby 10 when they switch
to 11.

I still need to think a lot about the whole major version boundary
thing.  It seems like we like solaris will be set at the same major
version for a very long time.   As I stated before I think for some
things a time based approach seems most appropriate. You can expect your
client to work with new servers for the next five years for example. We
should  not just leave users trying to figure out how to upgrade  their
server and all of their clients all in one night because we  bumped from
10 to 11.

If we expect upgrade=true to work from 10 to 11 we should expect
client/server compatibility to be maintained as well.
So either the time based approach or for major versions  have
compatibility with the previous and next  major versions.For example
with Derby 11 you can use Derby 10 or Derby 12, but not Derby 13.

>
> 2b) Our DRDA implementation may incorrectly transport datatypes not
> recognized by DRDA. Conforming to the DRDA spec may mean removing this
> transport capability and breaking applications which select the
> unsupported datatypes.
>
Protocol has an impact on client JDBC, SQL  and even the ability to
connect and those cannot be broken.
Client and server can have version dependent behaviour to mitigate the
change to DRDA compliant behavior.


>
> 3) Client/server compatibility.
>
> I would expect to find these rules spelled out on the wiki page. 



Yes I agree these should be spelled out because obviously different
readers can deduce different things.

Re: Does in-place compress really defragment?

[Bryan Pendleton]

Øystein Grøvlen wrote:

I tried an experiment with on-line compress and it seems like no space
is freed unless I delete records at the end of the heap:


It does seem like the documentation allows for this:

  SYSCS_COMPRESS_TABLE is guaranteed to recover the maximum amount
  of free space, at the cost of temporarily creating new tables
  and indexes before the statement in committed. SYSCS_INPLACE_COMPRESS
  attempts to reclaim space within the same table, but cannot guarantee
  it will recover all available space.

Did you try your same experiment with full compress?

thanks,

bryan

[jira] Updated: (DERBY-940) Add JDBC 4 Wrapper support

[V.Narayanan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-940?page=all ]

V.Narayanan updated DERBY-940:
--

Attachment: wrapper_ver3_embedded.diff
wrapper_ver3_embedded.stat

My previous patch made use of TestCallableStatementMethods.java. This is no 
more there in the current derby trunk and has been replaced by 
CallableStatementTest.java. I have moved the wrapper test to this new file. Can 
someone please take a look at this patch and point out issues if they think are 
there so that I can fix them.
thanx in advance
Narayanan

> Add JDBC 4 Wrapper support
> --
>
>  Key: DERBY-940
>  URL: http://issues.apache.org/jira/browse/DERBY-940
>  Project: Derby
> Type: New Feature
>   Components: JDBC
> Reporter: Rick Hillegas
> Assignee: V.Narayanan
>  Fix For: 10.2.0.0
>  Attachments: DERBY940_embedded.html, wrapper_ver1_embedded.diff, 
> wrapper_ver1_embedded.stat, wrapper_ver2_embedded.diff, 
> wrapper_ver2_embedded.stat, wrapper_ver3_embedded.diff, 
> wrapper_ver3_embedded.stat
>
> As described in the JDBC 4 spec, sections 21 and 3.1.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset

[Andreas Korneliussen (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1172?page=all ]

Andreas Korneliussen updated DERBY-1172:


Other Info: [Patch available]

> incorrect error message in updateRow() after a commit on a held scroll 
> insensitive resultset
> 
>
>  Key: DERBY-1172
>  URL: http://issues.apache.org/jira/browse/DERBY-1172
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
>  Attachments: DERBY-1172.diff, DERBY-1172.stat
>
> If an application does updateRow() right after a commit on a held cursor, 
> (without repositioning the cursor), an incorrect error message is given if 
> the ResultSet is of type TYPE_SCROLL_INSENSITIVE.
> "SQL 2003, Part 2: Foundation (SQL/Foundation) p 827,
> paragraph numbered 6):
> 6)If CR is a holdable cursor and a has not been
>   issued against CR within the current SQL- transaction,then an
>   exception condition is raised: invalid cursor state .
> and that exception has state 24000"
> Currently, if the ResultSet is of type TYPE_SCROLL_INSENSITIVE, it fails with
> SQL Exception: The scan is not positioned. state: XSCH7 : code=2
> If the ResultSet is of type TYPE_FORWARD_ONLY, it gives the correct error 
> message:
> SQL Exception: Invalid cursor state - no current row. state: 24000 : 
> code=2
> The first exception is given from the store layer. The SQL layer seems to 
> catch the store exception and rethrow a new exception with correct SQL state 
> and error message. However this is not done in 
> TableScanResultset.getRowLocation(), which is used by scrollinsensitve 
> cursors.
> A fix could be to add this logic into TableScanResultset.getRowLocation(). Or 
> alternatively, make the store layer throw the expected exception, and remove 
> logic to rethrow the exception.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: JDBC ResultSets from DatabaseMetaData

[Daniel John Debrunner]

Fernanda Pizzorno wrote:

> I just came accross that in the book "JDBC API Tutorial and Reference,
> Third Edition". In the last paragraph of section "27.1.19 Queries That
> Produce Updatable Result Sets" (p.715) it stands:
> 
> "Result sets created by means other than the execution of a query, such
> as those returned by several methods in the DatabaseMetaData interface,
> are not scrollable or updatable, nor are they required to be."

Thanks Fernanda, I thought I was losing my mind, I even looked in that
book & couldn't find it.

Thanks for restoring my sanity!
Dan.

Does in-place compress really defragment?

[Øystein Grøvlen]

I tried an experiment with on-line compress and it seems like no space
is freed unless I delete records at the end of the heap:

1. Deleted every third record of a table
2. Inline compress with purge&defragment. File size did not change
3. Deleted every second of the remaining records
4. Inline compress with purge&defragment. File size did not change
5. Deleted the last third of the remaining records
6. Inline compress with purge&defragment. File size reduced by 1/3. 
7. Deleted first half of the remaining records
8. Inline compress with purge&defragment. File size did not change

Is this how it is supposed to be?  I would have thought that each
compress would defragment the table and free space, but it seems like
only empty space at the end of a table is freed.  Trace of what I did
below.  (There are 1536 records in t.  The records have primary keys
in range [0,1535] and was inserted in sorted order on primary key.
For all records j==mod(i,3).)

--
Øystein

ij> create table t1 (i integer primary key, j integer, c varchar(300));
0 rows inserted/updated/deleted
ij> insert into t1 select * from t;
1536 rows inserted/updated/deleted
ij> delete from t1 where j=1;
512 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> delete from t1 where j=2;
512 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> delete from t1 where i > 1024;
170 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> delete from t1 where i < 512;
171 rows inserted/updated/deleted
ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
0 rows inserted/updated/deleted
ij> 

[jira] Updated: (DERBY-1146) Verify that JDBC4 signatures satisfied

[Knut Anders Hatlen (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1146?page=all ]

Knut Anders Hatlen updated DERBY-1146:
--

Attachment: derby-1146-v1.diff
derby-1146-v1.stat

Uploading patch with new test jdbc4/VerifySignatures.junit. The test is not 
enabled in any suite since it currently fails. It requires JVM 1.6 to run.

> Verify that JDBC4 signatures satisfied
> --
>
>  Key: DERBY-1146
>  URL: http://issues.apache.org/jira/browse/DERBY-1146
>  Project: Derby
> Type: Improvement
>   Components: JDBC, Test
> Versions: 10.2.0.0
> Reporter: Rick Hillegas
> Assignee: Knut Anders Hatlen
>  Attachments: client.txt, derby-1146-v1.diff, derby-1146-v1.stat, embedded.txt
>
> Add to the jdbc40 suite a test which verifies that our JDBC4 classes satisfy 
> the expected class/interface signatures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset

[Andreas Korneliussen (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1172?page=all ]

Andreas Korneliussen updated DERBY-1172:


Attachment: DERBY-1172.diff
DERBY-1172.stat

The attached patch addresses the bug by catching and rethrowing. It also 
extends jdbcapi/HoldabilityTest.junit with two testcases which verfies that the 
correct exceptions is given.


> incorrect error message in updateRow() after a commit on a held scroll 
> insensitive resultset
> 
>
>  Key: DERBY-1172
>  URL: http://issues.apache.org/jira/browse/DERBY-1172
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.2.0.0
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
> Priority: Minor
>  Attachments: DERBY-1172.diff, DERBY-1172.stat
>
> If an application does updateRow() right after a commit on a held cursor, 
> (without repositioning the cursor), an incorrect error message is given if 
> the ResultSet is of type TYPE_SCROLL_INSENSITIVE.
> "SQL 2003, Part 2: Foundation (SQL/Foundation) p 827,
> paragraph numbered 6):
> 6)If CR is a holdable cursor and a has not been
>   issued against CR within the current SQL- transaction,then an
>   exception condition is raised: invalid cursor state .
> and that exception has state 24000"
> Currently, if the ResultSet is of type TYPE_SCROLL_INSENSITIVE, it fails with
> SQL Exception: The scan is not positioned. state: XSCH7 : code=2
> If the ResultSet is of type TYPE_FORWARD_ONLY, it gives the correct error 
> message:
> SQL Exception: Invalid cursor state - no current row. state: 24000 : 
> code=2
> The first exception is given from the store layer. The SQL layer seems to 
> catch the store exception and rethrow a new exception with correct SQL state 
> and error message. However this is not done in 
> TableScanResultset.getRowLocation(), which is used by scrollinsensitve 
> cursors.
> A fix could be to add this logic into TableScanResultset.getRowLocation(). Or 
> alternatively, make the store layer throw the expected exception, and remove 
> logic to rethrow the exception.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: JDBC ResultSets from DatabaseMetaData

[Lance J. Andersen]

This has been clarified in the JDBC 4.0 spec.

Again and i cannot say this often enough the tutorial and reference is 
not to be deemed the end-all when it comes to JDBC.  The spec consists 
of the JDBC API javadocs and the PDF spec.


I am trying to correct as many issues that i can for JDBC 4.0.  There 
are things in the tutorial that are wrong and there are some that are 
more correct.  I am addressing them as i find them.


regards
lance

Fernanda Pizzorno wrote:
I just came accross that in the book "JDBC API Tutorial and Reference, 
Third Edition". In the last paragraph of section "27.1.19 Queries That 
Produce Updatable Result Sets" (p.715) it stands:


"Result sets created by means other than the execution of a query, 
such as those returned by several methods in the DatabaseMetaData 
interface, are not scrollable or updatable, nor are they required to be."


Fernanda

Daniel John Debrunner wrote:


I known I've seen a statement somewhere that listed the ResultSet
attributes for ResultSets returned from DatabaseMetaData methods.

It stated that such ResultSets were forward only etc.

Now I can't find that statement in JDBC 4.0/3.0 spec or the javadoc.Does
anyone remember where this statement is?

Thanks,
Dan.

 

[jira] Created: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset

[Andreas Korneliussen (JIRA)]

incorrect error message in updateRow() after a commit on a held scroll 
insensitive resultset


 Key: DERBY-1172
 URL: http://issues.apache.org/jira/browse/DERBY-1172
 Project: Derby
Type: Bug
  Components: SQL  
Versions: 10.2.0.0
Reporter: Andreas Korneliussen
 Assigned to: Andreas Korneliussen 
Priority: Minor


If an application does updateRow() right after a commit on a held cursor, 
(without repositioning the cursor), an incorrect error message is given if the 
ResultSet is of type TYPE_SCROLL_INSENSITIVE.

"SQL 2003, Part 2: Foundation (SQL/Foundation) p 827,
paragraph numbered 6):

6)If CR is a holdable cursor and a has not been
  issued against CR within the current SQL- transaction,then an
  exception condition is raised: invalid cursor state .

and that exception has state 24000"

Currently, if the ResultSet is of type TYPE_SCROLL_INSENSITIVE, it fails with
SQL Exception: The scan is not positioned. state: XSCH7 : code=2

If the ResultSet is of type TYPE_FORWARD_ONLY, it gives the correct error 
message:
SQL Exception: Invalid cursor state - no current row. state: 24000 : code=2

The first exception is given from the store layer. The SQL layer seems to catch 
the store exception and rethrow a new exception with correct SQL state and 
error message. However this is not done in TableScanResultset.getRowLocation(), 
which is used by scrollinsensitve cursors.

A fix could be to add this logic into TableScanResultset.getRowLocation(). Or 
alternatively, make the store layer throw the expected exception, and remove 
logic to rethrow the exception.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: JDBC ResultSets from DatabaseMetaData

[Fernanda Pizzorno]

I just came accross that in the book "JDBC API Tutorial and Reference, 
Third Edition". In the last paragraph of section "27.1.19 Queries That 
Produce Updatable Result Sets" (p.715) it stands:


"Result sets created by means other than the execution of a query, such 
as those returned by several methods in the DatabaseMetaData interface, 
are not scrollable or updatable, nor are they required to be."


Fernanda

Daniel John Debrunner wrote:


I known I've seen a statement somewhere that listed the ResultSet
attributes for ResultSets returned from DatabaseMetaData methods.

It stated that such ResultSets were forward only etc.

Now I can't find that statement in JDBC 4.0/3.0 spec or the javadoc.Does
anyone remember where this statement is?

Thanks,
Dan.

 

[jira] Updated: (DERBY-1163) Add jdbc4.0 implementation of EmbedPooledConnection and EmbedXAConnection

[Anurag Shekhar (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1163?page=all ]

Anurag Shekhar updated DERBY-1163:
--

Attachment: derby-1163_2.diff

the privious patch broke due to changes made in EmbedPoolableConnection as part 
of DERBY-1158.
I have fixed the problem. As the changes are only in 40 class which is unused 
for now I haven't reran derbyall

> Add jdbc4.0 implementation of EmbedPooledConnection and EmbedXAConnection
> -
>
>  Key: DERBY-1163
>  URL: http://issues.apache.org/jira/browse/DERBY-1163
>  Project: Derby
> Type: New Feature
>  Environment: jdk1.6, jdbc4.0
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
>  Fix For: 10.2.0.0
>  Attachments: derby-1163.diff, derby-1163_2.diff
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Regression Test Failure! - Derby 390189 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*Derby* 390189/2006-03-30 19:45:54 CEST
*derbyall*

Failed  TestsOK  Skip  Duration   Platform
---
*Jvm: 1.6*
   NA NA NANA   SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-390189.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/390189M.html
 
*Jvm: 1.5*
4646642 0   104.09% CYGWIN_NT-5.1_i686-unknown
2646644 0   133.92% CYGWIN_NT-5.2_i686-unknown
   NA NA NANA   Linux-2.4.21-27.ELsmp_i686-athlon
0646646 0   113.23% Linux-2.6.14-1.1644_FC4_i686-i686
0646646 0   100.00% Linux-2.6.9-34.ELsmp_x86_64-x86_64
0646646 0   108.67% SunOS-5.10_i86pc-i386
0646646 0   134.04% SunOS-5.10_sun4u-sparc
   NA NA NANA   SunOS-5.11_i86pc-i386
0646646 0   121.94% SunOS-5.9_sun4u-sparc
  Details in  
http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-390189.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/Derby/390189.html 
*Jvm: 1.4*
2643641 2   100.31% CYGWIN_NT-5.1_i686-unknown
   NA NA NANA   Linux-2.4.21-27.ELsmp_i686-athlon
1643642 2   112.68% Linux-2.6.14-1.1644_FC4_i686-i686
0643643 2   100.00% Linux-2.6.9-34.ELsmp_x86_64-x86_64
0643643 2   111.13% SunOS-5.10_i86pc-i386
  Details in  
http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-390189.html
 
  Attempted failure analysis in
  
http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/390189.html 

Changes in  
http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/390189.txt 

( All results in http://www.multinet.no/~solberg/public/Apache/index.html ) 

[jira] Commented: (DERBY-1164) 'show tables' and 'describe' commands in ij

[JIRA]

[ 
http://issues.apache.org/jira/browse/DERBY-1164?page=comments#action_12372646 ] 

Øystein Grøvlen commented on DERBY-1164:


Nice start.  I think some more work is needed to make this really useful:

1. Display length for character types, precision for numerics
2. Display information on primary keys and nullability
3. Not require schema name, and look for tables in current schema in that case. 
 I think many of those who will benefit the most from this command, may not 
necessarily know much about schemas.  They just use the default schema.
4. Would be nice to have a 'show schemas' command
5. Would ne nice to be able to list tables within a given schema.



> 'show tables' and 'describe' commands in ij
> ---
>
>  Key: DERBY-1164
>  URL: http://issues.apache.org/jira/browse/DERBY-1164
>  Project: Derby
> Type: New Feature
>   Components: Tools
> Reporter: Håvard Mork
> Priority: Trivial
>  Attachments: 1164.diff
>
> New users migrating from mysql are familiar with commands 'show tables' and 
> 'describe'  to respectively display all permanent tables, and show fields in 
> a given table. These are not standard sql, but I suggest to implement them 
> only in the IJ tool for user-friendliness.
> As suggested in db-dev, using DatabaseMetaData should provide the necessary 
> query strings.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira