Re: Problem with Jira attachment
Hmm... I just tried to attach my patch but am still having the same exception, I can't seem to attach files to DERBY-1953.YipOn 10/11/06, Mamta Satoor <[EMAIL PROTECTED]> wrote:Yip, I attached my review package to DERBY-737 a little while back and didn't experience any problems. Mamta On 10/11/06, Yip Ng <[EMAIL PROTECTED]> wrote: Anyone have problem attaching patch in jira? I got the following error: Errors Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/DERBY/DERBY-1953 Yip
Re: Problem with Jira attachment
Yip, I attached my review package to DERBY-737 a little while back and didn't experience any problems. Mamta On 10/11/06, Yip Ng <[EMAIL PROTECTED]> wrote: Anyone have problem attaching patch in jira? I got the following error: Errors Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/DERBY/DERBY-1953 Yip
[jira] Updated: (DERBY-737) SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist
[ http://issues.apache.org/jira/browse/DERBY-737?page=all ] Mamta A. Satoor updated DERBY-737: -- Derby Info: [Patch Available] > SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist > - > > Key: DERBY-737 > URL: http://issues.apache.org/jira/browse/DERBY-737 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.1.3.1, 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, > 10.2.1.6, 10.0.2.2 >Reporter: Kathey Marsden > Assigned To: Mamta A. Satoor >Priority: Minor > Attachments: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt, > DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt > > > There must be an entry in the SYSSTATISTICS table in order for the > cardinality statistics in SYSSTATISTICS to be created with > SYSCS_UTIL.SYSCS_COMPRESS_TABLE > SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they don't > exist. The only way to create them if the index was created on an empty > table, seems to be to drop and recreate the index after the table has been > loaded. > The documentation will also need updating if this change is made. > http://db.apache.org/derby/docs/10.1/tuning/ctunstats57373.html -- 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-737) SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist
[ http://issues.apache.org/jira/browse/DERBY-737?page=all ] Mamta A. Satoor reassigned DERBY-737: - Assignee: Mamta A. Satoor > SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist > - > > Key: DERBY-737 > URL: http://issues.apache.org/jira/browse/DERBY-737 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.1.3.1, 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, > 10.2.1.6, 10.0.2.2 >Reporter: Kathey Marsden > Assigned To: Mamta A. Satoor >Priority: Minor > Attachments: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt, > DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt > > > There must be an entry in the SYSSTATISTICS table in order for the > cardinality statistics in SYSSTATISTICS to be created with > SYSCS_UTIL.SYSCS_COMPRESS_TABLE > SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they don't > exist. The only way to create them if the index was created on an empty > table, seems to be to drop and recreate the index after the table has been > loaded. > The documentation will also need updating if this change is made. > http://db.apache.org/derby/docs/10.1/tuning/ctunstats57373.html -- 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-737) SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist
[ http://issues.apache.org/jira/browse/DERBY-737?page=all ] Mamta A. Satoor updated DERBY-737: -- Attachment: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt I would like to submit a patch for this Jira entry. It is attached as DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt The changes have been very localized in AlterTableConstantAction.java!updateIndex() Currently, this method checks if statistics already exist for an index. If yes, then it sets a flag updateStatistics to true. Later, the code checks for this flag and drops the existing statistics and creates new statistics for that index provided the user table at this point is not empty. So, as we can see, if there is an index with no preexisting statistics, the flag updateStatistics will be set to false and hence no statistics related code is executed and hence even though the user table is not empty at the time of compress, no statistics get generated for such an index. I am proposing to fix the problem by still using the flag to see if an index has pre-existing statistics. If yes, then we should drop those statistics. Next, whether the index has pre-existing statistics or not, go ahead and create new statistics for the index provided the user table is not currently empty. I ran the derbyall suite on Windows XP with Sun JDK 1.4 and there were no new failures. In addition, I have added few tests to lang/compressTable.sql Can someone please review this patch for me? > SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they do not exist > - > > Key: DERBY-737 > URL: http://issues.apache.org/jira/browse/DERBY-737 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.1.3.1, 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, > 10.2.1.6, 10.0.2.2 >Reporter: Kathey Marsden >Priority: Minor > Attachments: DERBY737_v1_diff_SYSCS_COMPRESS_TABLE.txt, > DERBY737_v1_stat_SYSCS_COMPRESS_TABLE.txt > > > There must be an entry in the SYSSTATISTICS table in order for the > cardinality statistics in SYSSTATISTICS to be created with > SYSCS_UTIL.SYSCS_COMPRESS_TABLE > SYSCS_UTIL.SYSCS_COMPRESS_TABLE should create statistics if they don't > exist. The only way to create them if the index was created on an empty > table, seems to be to drop and recreate the index after the table has been > loaded. > The documentation will also need updating if this change is made. > http://db.apache.org/derby/docs/10.1/tuning/ctunstats57373.html -- 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] Commented: (DERBY-630) create trigger fails with null pointer exception
[ http://issues.apache.org/jira/browse/DERBY-630?page=comments#action_12441596 ] Bryan Pendleton commented on DERBY-630: --- Hi Yip, sorry I kind of lost track of this issue. Your explanation of the schema handling seems reasonable to me. I intend to commit this patch. If anybody else is reviewing this change, please let us know. > create trigger fails with null pointer exception > > > Key: DERBY-630 > URL: http://issues.apache.org/jira/browse/DERBY-630 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.1.1.0 > Environment: windows 2000, sun jdk 1.5.0 >Reporter: mardacay > Assigned To: Yip Ng > Attachments: derby630-trunk-diff01.txt, derby630-trunk-stat01.txt > > > When i create a brand new database, and execute the following statements all > in one transaction or each of them in their own transaction, then it fails at > trigger creation with null pointer exception. if i exclude the schema names > from statement, then it runs fine. (If S1 is ommited from every statement > then it runs fine). Once the version without the schema names run fine, i can > run the version that has schema names, fine also. > create schema S1; > create table > S1.PRODUCT( > PRODUCT_ID VARCHAR(255) unique not null, > VERSION BIGINT > ); > > create table > S1.CATEGORY( > CAT_ID VARCHAR(255), > NAME varchar(255) not null, > VERSION BIGINT > ); > create table > S1.PROD_IN_CAT( > CAT_ID VARCHAR(255) not null, > PRODUCT_ID VARCHAR(255) not null, > VERSION BIGINT > ); > > create trigger S1.product_v > after update of version on S1.product > referencing new as n > for each row > mode db2sql > update S1.prod_in_cat set version = n.version where > S1.prod_in_cat.product_id=n.product_id; > java.lang.NullPointerException > at > org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown > Source) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown > Source)Stopping progress indicator for: Executing SQL > at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) -- 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] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12441587 ]
Yip Ng commented on DERBY-1953:
---
Having problem submitting patch as attachment:
Exception trying to establish attachment directory. Check that the application
server and JIRA have permissions to write to it:
com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment
directory. Check that the application server and JIRA have permissions to write
to: /usr/local/tomcat/tomcat-jira/attachments/DERBY/DERBY-1953
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | STATEMENT } ]
--
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: [VOTE] Army Brown as a committer
+1 Manish - Original Message From: Mike Matrigali <[EMAIL PROTECTED]> To: Derby Development Sent: Tuesday, October 10, 2006 12:48:00 PM Subject: [VOTE] Army Brown as a committer This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED]
Re: HashJoinStrategy.feasible
James Synge wrote: Army mentioned earlier the analysis he wrote for Derby-781 (Subquery materialization Hash Join). I've read most of that, Thanks for reading the DERBY-781 writeup. It's always nice to know other people are double-checking the analysis and asking questions--especially with the optimizer since, as you probably know by now, there's an endless supply of analysis to do and questions to ask... and am confused by his analysis of this select: Q2. select 1 from tt, (t left outer join (s left outer join r on (f = i)) on (b = e)) where (j=g) Judging from the analysis, this query could be less ambiguously expressed as: select 1 from tt as T0, (t as T1 left outer join (s as T2 left outer join r as T3 on (T2.f = T3.i)) on (T1.b = T2.e)) where (T0.j=T3.g) In particular, I don't understand the claim that the subqueries can not be materialized because of the fact that the (j=g) and (b=e) predicates create a correlation between the levels. I'm glad you mentioned the predicate (b=e). In the discussion I focused on (j=g) but as it turns out, it's actually (b=e) that makes the difference in this particular query. The logic for both queries is the same (w.r.t to the different nesting levels) but for this specific scenario, (b=e) is the predicate of importance. I can't see any theoretical reason why the following table expression couldn't be materialized: s as T2 left outer join r as T3 on (T2.f = T3.i) This expression in and of itself can in fact be materialized. In this *isolated* query the predicate is between two tables that are at the same nesting level--namely, T2 and T3. So if all we look at is (T2.f=T3.i), then yes, as you say, there is no correlation between this expression and the rest of the FROM clause, and thus this piece can be safely materialized. But in the bigger query, (T2.f=T3.i) is not the only predicate. We also have (T0.j=T3.g) and (T1.b=T2.e). And as I mentioned above, it's the predicate (T1.b=T2.e) which, for this example, renders materialization unsafe. Furthermore, there is no correlation between: (t as T1 left outer join (s as T2 left outer join r as T3 on (T2.f = T3.i)) on (T1.b = T2.e)) And the rest of the from clause (just TT in this case). The correlation comes via the predicate (T0.j=T3.g), which is specified as part of the WHERE clause in the top-level query. That predicate joins TT with the HalfOuterJoinNode, hence the correlation. (Is that what you were asking?) My understanding of the semantics of select are that (logically) the FROM clause is executed first to produce a working table (in this case a CROSS JOIN of TT with the result of the left outer joins, which are evaluated independently of TT). Logically, I think you are right here. Put differently, I think what you're expecting is that the HalfOuterJoin node should be evaluated to some result set, and then the hash join can occur between TT and that result set using (T0.j=T3.g) as the equijoin predicate. Or, in the case of (T1.b=T2.e), JoinNode[4] should be evaluated to some result set and then the hash join can occur between T1 and that JoinNode. I agree that logically it seems like this should work. But alas, it seems like something under the covers does not follow this logical separation of hash join vs. result-set-creation. Take, for example, the following tables and data, and then run the less ambiguous version of your query: CREATE TABLE T (A INT NOT NULL, B DECIMAL(10,3) NOT NULL, C VARCHAR(5) NOT NULL); INSERT INTO T VALUES (1, 1.0, '1'), (2, 2.0, '2'), (3, 3.0, '3'); CREATE TABLE S (D INT NOT NULL, E DECIMAL(10,3) NOT NULL, F VARCHAR(5) NOT NULL); INSERT INTO S VALUES (2, 2.0, '2'), (3, 3.0, '3'), (4, 4.0, '4'); CREATE TABLE R (G INT NOT NULL, H DECIMAL(10,3) NOT NULL, I VARCHAR(5) NOT NULL); INSERT INTO R VALUES (3, 3.0, '3'), (4, 4.0, '4'), (5, 5.0, '5'); CREATE TABLE TT (J INT NOT NULL, K DECIMAL(10,3) NOT NULL, L VARCHAR(5) NOT NULL); INSERT INTO TT VALUES (2, 2.0, '2'), (3, 3.0, '3'), (4, 4.0, '4'); Currently Derby will (correctly) return one row: ij> select t0.* from tt as T0, (t as T1 left outer join (s as T2 left outer join r as T3 on (T2.f = T3.i)) on (T1.b = T2.e)) where (T0.j=T3.g); J |K |L -- 3 |3.000 |3 But without the changes for DERBY-781 that led to this discussion, the query returns zero rows. The difference between the two plans is that, in the latter, the optimizer does a hash join between T1 and JoinNode[4], but in the former it does not. So given that I came to the conclusion that hash joins are unsafe if the predicate references FromTables at different nesting levels. And I think that conclusion is still correct based on the Derby behavior. I cannot, however, say for certain *why* such a hash join is unsafe. I think you're right in asking this question and I'm glad you did...but I don't ha
Re: Discussion: Feedback needed on the Documentation Review process
Laura Stewart wrote: For the 10.2 Documentation Review process, a wiki was used to log comments and track the status of those comments. http://wiki.apache.org/db-derby/TenTwoDocReview [snip] Was the wiki a good way to conduct the reviews? I found adding an entry to the wiki was in some ways more painful than entering a Jira issue. The pain was the manual formating of the table and distractions would cause one to lose the edit lock on the wiki page, in one case losing my comments. Then with the wiki there is no good tracking of how the issue was resolved, no link to the patch number or the Jira entry that fixed it. So maybe just using Jira is better as it's fairly quick, doesn't lose issues and allows tracking. Might result in a large number of Jira issues but I'm nt sure that's really a problem. Some direct markup of an html page on the site directly would be much better though. :-) I saw a page with a number of minor mistakes on it the other day, but it seemed a lot of effort to write those up in a Jira entry, namely having to describe the mistake, which document, section, paragraph etc. that it occurs in. Dan.
Problem with Jira attachment
Anyone have problem attaching patch in jira? I got the following error: Errors Exception trying to establish attachment directory. Check that the application server and JIRA have permissions to write to it: com.atlassian.jira.web.util.AttachmentException: Cannot write to attachment directory. Check that the application server and JIRA have permissions to write to: /usr/local/tomcat/tomcat-jira/attachments/DERBY/DERBY-1953Yip
[jira] Updated: (DERBY-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=all ] Kim Haase updated DERBY-1948: - Attachment: DERBY-1948.zip HTML output files for changes. > 10.2 'Working with Derby' manual errors. > > > Key: DERBY-1948 > URL: http://issues.apache.org/jira/browse/DERBY-1948 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 > Environment: Under Fedora core 5 >Reporter: Micky Connor > Assigned To: Kim Haase >Priority: Trivial > Attachments: DERBY-1948.diff, DERBY-1948.zip > > > Going through the 10.2 'Working with Derby' manual I think I > have found several file path errors: > --Under Activity 1, the given path is > $DERBY_HOME/demo/toursdb/*.sql >but it should be > $DERBY_HOME/demo/programs/toursdb/*.sql > --Similary, under Activity 3, in section 1, the given path is > $DERBY_HOME/demo/workingwithderby/* > but it should be > $DERBY_HOME/demo/programs/workingwithderby/* > --Finally under Activity 4, section 3, the CLASSPATH given for Windows refers > to 'derbyclient.jar',but the UNIX version gives 'derby.jar'. The > necessary driver only exists in 'derbyclient.jar'. -- 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] Created: (DERBY-1955) Unquoted path in .bat files may cause errors (Win)
Unquoted path in .bat files may cause errors (Win) -- Key: DERBY-1955 URL: http://issues.apache.org/jira/browse/DERBY-1955 Project: Derby Issue Type: Bug Components: Demos/Scripts Affects Versions: 10.2.1.6 Environment: Windows 2000 (SP4), x86 Reporter: Tom Switzer Priority: Trivial The "CALL %~dp0derby_common.bat %*" command in the .bat files in the bin/ directory are unquoted. So, if the path the scripts live in contains a space, running them will either result in CALL failing or producing an undesired effect. -- 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: [VOTE] Army Brown as a committer
+1 Mike Matrigali wrote On 10/10/06 15:48,: > This vote is for establishing Army Brown as a committer for Derby.
[jira] Updated: (DERBY-1839) Doc Review Updates - Ref Manual
[ http://issues.apache.org/jira/browse/DERBY-1839?page=all ] Laura Stewart updated DERBY-1839: - Derby Info: [Patch Available] > Doc Review Updates - Ref Manual > --- > > Key: DERBY-1839 > URL: http://issues.apache.org/jira/browse/DERBY-1839 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.2.1.6 >Reporter: Laura Stewart > Assigned To: Laura Stewart > Fix For: 10.2.2.0 > > Attachments: 1839_SQLstatements.diff, derby1839_functions1.diff, > derby1839_functions1.zip, derby1839_functions2.diff, > derby1839_functions2_html.zip, derby1839_SQLstatement_4.diff, > derby1839_SQLstatements2.diff, derby1839_SQLstatements2_html.zip, > derby1839_SQLstatements3.diff, derby1839_SQLstatements3_html.zip, > derby1839_SQLstatements4_html.zip, derby1839_SQLstatements_html.zip, > derby1839_TANCEILfunctions.diff, derby1839_TANCEILfunctions_html.zip, > derby1839_XML+functions_1.diff, derby1839_XML+functions_2.diff, > derby1839_XML+functions_html1.zip, derby1839_XML+functions_html2.zip > > > This JIRA issue will be used to track all of the issues found in the 10.2 doc > review of the Reference Manual. -- 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-1954) Update sysinfo output documentation in Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-1954?page=all ] Laura Stewart updated DERBY-1954: - Derby Info: [Patch Available] > Update sysinfo output documentation in Tools and Utilities Guide > > > Key: DERBY-1954 > URL: http://issues.apache.org/jira/browse/DERBY-1954 > Project: Derby > Issue Type: Bug > Components: Documentation >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1954_1.diff, derby1954_html1.zip > > > Section = sysinfo > File = rtoolssysinfo1002629.html > In the example section, the new text = > With derby.jar and derbytools.jar in your classpath the output from running > the sysinfo command is shown below. > $ java org.apache.derby.tools.sysinfo > -- 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-1954) Update sysinfo output documentation in Tools and Utilities Guide
[ http://issues.apache.org/jira/browse/DERBY-1954?page=all ] Laura Stewart updated DERBY-1954: - Attachment: derby1954_1.diff derby1954_html1.zip Updated the example files listed below. I included the comments and added indexes. Additionally, I restructured the dblook examples file significantly and reworded the text. Please look that file over carefully. Filename Title rtoolssysinfo1002629sysinfo example rtoolsdblookexamplesdblook examples > Update sysinfo output documentation in Tools and Utilities Guide > > > Key: DERBY-1954 > URL: http://issues.apache.org/jira/browse/DERBY-1954 > Project: Derby > Issue Type: Bug > Components: Documentation >Reporter: Laura Stewart > Assigned To: Laura Stewart > Attachments: derby1954_1.diff, derby1954_html1.zip > > > Section = sysinfo > File = rtoolssysinfo1002629.html > In the example section, the new text = > With derby.jar and derbytools.jar in your classpath the output from running > the sysinfo command is shown below. > $ java org.apache.derby.tools.sysinfo > -- 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-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=all ] Kim Haase updated DERBY-1948: - Derby Info: [Patch Available] > 10.2 'Working with Derby' manual errors. > > > Key: DERBY-1948 > URL: http://issues.apache.org/jira/browse/DERBY-1948 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 > Environment: Under Fedora core 5 >Reporter: Micky Connor > Assigned To: Kim Haase >Priority: Trivial > Attachments: DERBY-1948.diff > > > Going through the 10.2 'Working with Derby' manual I think I > have found several file path errors: > --Under Activity 1, the given path is > $DERBY_HOME/demo/toursdb/*.sql >but it should be > $DERBY_HOME/demo/programs/toursdb/*.sql > --Similary, under Activity 3, in section 1, the given path is > $DERBY_HOME/demo/workingwithderby/* > but it should be > $DERBY_HOME/demo/programs/workingwithderby/* > --Finally under Activity 4, section 3, the CLASSPATH given for Windows refers > to 'derbyclient.jar',but the UNIX version gives 'derby.jar'. The > necessary driver only exists in 'derbyclient.jar'. -- 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-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=all ] Kim Haase updated DERBY-1948: - Attachment: DERBY-1948.diff Corrections to Working With Derby files. > 10.2 'Working with Derby' manual errors. > > > Key: DERBY-1948 > URL: http://issues.apache.org/jira/browse/DERBY-1948 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 > Environment: Under Fedora core 5 >Reporter: Micky Connor > Assigned To: Kim Haase >Priority: Trivial > Attachments: DERBY-1948.diff > > > Going through the 10.2 'Working with Derby' manual I think I > have found several file path errors: > --Under Activity 1, the given path is > $DERBY_HOME/demo/toursdb/*.sql >but it should be > $DERBY_HOME/demo/programs/toursdb/*.sql > --Similary, under Activity 3, in section 1, the given path is > $DERBY_HOME/demo/workingwithderby/* > but it should be > $DERBY_HOME/demo/programs/workingwithderby/* > --Finally under Activity 4, section 3, the CLASSPATH given for Windows refers > to 'derbyclient.jar',but the UNIX version gives 'derby.jar'. The > necessary driver only exists in 'derbyclient.jar'. -- 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] Commented: (DERBY-1948) 10.2 'Working with Derby' manual errors.
[ http://issues.apache.org/jira/browse/DERBY-1948?page=comments#action_12441509 ] Kim Haase commented on DERBY-1948: -- In addition to the corrections listed above (thanks to Micky for catching them!), I'm adding the following technical corrections. twwdactivity1.dita: - change output 10.2.1.0 to 10.2.1.6 - Build is 452058 twwdactivity2.dita: - command output is not "Server is ready to accept connections on port 1527." but Apache Derby Network Server - 10.2.1.6 - (452058) started and ready to accept connections on port 1527 at 2006-09-22 00:08:30.049 GMT I edited the timestamps to correlate approximately with those in the output examples. - shutdown command also different: Apache Derby Network Server - 10.2.1.6 - (452058) shutdown at 2006-09-22 00:16:30.049 GMT - both messages later in file as well rwwdactivity3.dita: - changed "java program" to "Java program" (2nd paragraph) - changed "SQLException method" to "SQLExceptionPrint method" near end - changed "JAVA" to "Java" at end twwdactivity4.dita: - This activity leaves the Network Server running. Added a step to shut it down. Will attach a diffs file that includes all these changes. > 10.2 'Working with Derby' manual errors. > > > Key: DERBY-1948 > URL: http://issues.apache.org/jira/browse/DERBY-1948 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 > Environment: Under Fedora core 5 >Reporter: Micky Connor > Assigned To: Kim Haase >Priority: Trivial > > Going through the 10.2 'Working with Derby' manual I think I > have found several file path errors: > --Under Activity 1, the given path is > $DERBY_HOME/demo/toursdb/*.sql >but it should be > $DERBY_HOME/demo/programs/toursdb/*.sql > --Similary, under Activity 3, in section 1, the given path is > $DERBY_HOME/demo/workingwithderby/* > but it should be > $DERBY_HOME/demo/programs/workingwithderby/* > --Finally under Activity 4, section 3, the CLASSPATH given for Windows refers > to 'derbyclient.jar',but the UNIX version gives 'derby.jar'. The > necessary driver only exists in 'derbyclient.jar'. -- 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] Resolved: (DERBY-1926) Provide documentation for ALTER TABLE DROP COLUMN
[ http://issues.apache.org/jira/browse/DERBY-1926?page=all ] Bryan Pendleton resolved DERBY-1926. Fix Version/s: 10.3.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Comitted the doc patch to the docs trunk as subversion revision 462850. Once the updated doc appears on the web site I'll close this issue. > Provide documentation for ALTER TABLE DROP COLUMN > - > > Key: DERBY-1926 > URL: http://issues.apache.org/jira/browse/DERBY-1926 > Project: Derby > Issue Type: New Feature > Components: Documentation >Affects Versions: 10.3.0.0 >Reporter: Bryan Pendleton > Assigned To: Bryan Pendleton >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: dropCol1.diff > > > The documentation will need to be updated after DERBY-1489 is committed. The > reference manual will need to describe how to use the new ALTER TABLE DROP > COLUMN feature to drop a column from a table. > The documentation for the ALTER TABLE command is becoming somewhat unwieldy, > so perhaps there is a way to restructure the page to make it easier and more > approachable. > In the documentation, it will be important to clearly describe the RESTRICT > and CASCADE behaviors, as users may be confused by what things cause RESTRICT > to refuse to drop a column. The comments in AlterTableConstantAction.java may > help. > Specifically, the documentation should note these possibly unexpected > behaviors: > - If a column is present in one or more indexes, these indexes by themselves > do not cause >RESTRICT to refuse to drop a column. Instead, the column will simply be > dropped from >the index, and if that was the last column in that index, the entire index > will be dropped. > - Explicitly named CHECK constraints will cause RESTRICT to refuse to drop a > column, as >will PRIMARY KEY, FOREIGN KEY, and UNIQUE constrants. However, an unnamed > simple >NOT NULL constraint on a column will NOT cause RESTRICT to refuse to drop > it. -- 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: [VOTE] Army Brown as a committer
+1. Mamta On 10/11/06, Laura Stewart <[EMAIL PROTECTED]> wrote: > This vote is for establishing Army Brown as a committer for Derby.Army will make a great committer. +1--Laura Stewart
[jira] Updated: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[ http://issues.apache.org/jira/browse/DERBY-1953?page=all ]
Yip Ng updated DERBY-1953:
--
Derby Info: (was: [Patch Available])
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | STATEMENT } ]
--
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] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12441491 ]
Yip Ng commented on DERBY-1953:
---
Originally, I had MODE DB2SQL to be independent but there is a testcase in
db2Compatibility.sql that expects failure when the MODE DB2SQL is specified
without the FOR EACH part. That was why I retain the failure with
the current syntax. But after going through the most recent DB2 documentation,
it appears that MODE DB2SQL can be optional and independent as well. So I am
going to make the correction and change to what Bernt suggested. The syntax is
now:
::=
[ FOR EACH { ROW | STATEMENT } ]
[ MODE DB2SQL ]
Need to rerun derbyall. =)
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | STATEMENT } ]
--
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: DERBY-1434 - Client can send incorrect database name to server after having made multiple connections to different databases.
If #2 is all it takes to fix the trace, and if there are no negative effects, then that's what I vote for. I agree. Fixing the trace is important, sending the right database name in the PKGNAMCSN is important, and solution #2 gets my vote as well. I think it was important to explore the issue to this level of detail, to satisfy ourselves that there were no other functional problems besides the trace (that is, that we didn't execute the wrong queries, or mix up the results from two queries issued at the same time, or something like that). Also, I was hoping that we would be able to construct a regression test for this change, as something other than: - run this test program with these trace flags set - read the trace files and make sure they look ok as I would have preferred to see a more automatic regression test of some sort. But I haven't thought of a simple way to write such a regression test. Julius, I think that it's still worth incorporating your test program(s) into the patch as you construct it, even though using those test programs requires some manual actions (enabling the trace flags, reading the trace files). I think it would be good to include the instructions for how to use the test program(s) to verify the correct operation of the patch as code comments in the test programs themselves. This will be useful at least during the review of the patch, but I think that there's no harm in including the test programs as a permanent part of the regression suite, as they exercise a certain path through the code and shouldn't cause too much of a performance impact. And thanks for the detailed analysis of the problem, Julius; it has been quite illuminating to read your notes. thanks, bryan
Re: [testing]Test fails
On 10/10/06, Leo Li <[EMAIL PROTECTED]> wrote: Hi, I have another problem. I have ran all test using java org.apache.derbyTesting.functionTests.harness.RunSuite derbyall. But some test fails and reports the derbyall_report.txt in my attachment. Is it neccessary to set some options like: java -Xbootclasspath/a:%jardir%\jdbc.jar -Dbootcp=%jardir%\jdbc.jar -Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource -Djvmflags="-Dij.dataSource=org.apache.derby.jdbc.EmbeddedSimpleDataSource" org.apache.derbyTesting.functionTests.harness.RunSuite derbyall Thank you. Hi, Those errors you see are because the test harness wasn't adjusted to a reorganization in the location of the test libraries. If you put all derby*.jar in one place, including the derbyTesting.jar, things will work fine. There is an outstanding bug, see DERBY-1593. The bootcp options are only needed for the special 'j9' jvm that comes with certain IBM products - and the dataSource option is only for j2ME / Jcl foundation libraries. You would know it if that's what you are using, because the executable is j9.exe rather than java.exe... Myrna
Re: [VOTE] Army Brown as a committer
This vote is for establishing Army Brown as a committer for Derby. Army will make a great committer. +1 -- Laura Stewart
Regression Test Report - 454795 - Sun DBTG
[Auto-generated mail] ** 454795/2006-10-10 18:00:06 MEST ** Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 1687686 0 106.16% lin 1687686 0 111.55% sol 1687686 097.02% solN+1 1687686 0 107.20% sparc 1687686 0 161.26% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.6/Limited/testSummary-454795.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.6/454795.html *Jvm: 1.5* 0675675 2 105.42% lin 0675675 2 113.30% sol 0675675 297.05% solN+1 0675675 2 106.18% sparc 0675675 2 170.81% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.5/Limited/testSummary-454795.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.5/454795.html *Jvm: 1.4* 0669669 4 105.67% lin 0669669 4 109.52% sol 0669669 497.61% solN+1 0669669 4 106.54% sparc 0669669 497.40% win Details in http://www.multinet.no/~solberg/public/Apache/Daily/jvm1.4/Limited/testSummary-454795.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Daily/Failures/jvm1.4/454795.html --- Changes in http://www.multinet.no/~solberg/public/Apache/Daily/UpdateInfo/454795.txt ( All results in http://www.multinet.no/~solberg/public/Apache/Daily/index.html )
Re: [VOTE] Army Brown as a committer
> This vote is for establishing Army Brown as a committer for Derby. +1 -jean
Re: DERBY-1434 - Client can send incorrect database name to server after having made multiple connections to different databases.
Julius Stroffek wrote: Query processing is always performed correctly. The only one visible impact is the server trace. To an end-user that might not mean much, but to developers trying to read a trace in order to track down a problem, I think it's important to have correct server traces as much as possible. At the very least, it makes it so that people don't stare at the database name in the trace and think, "Hmm...that looks wrong...I wonder if that's the cause of the problem I'm investigating?"--which is exactly what I spent a half-day doing before I came to the conclusion that it wasn't related :) The PKGNAMCSN is not a mandatory code point according to DRDA DDM. For now I see these alternatives: 1.) Leave the code unchanged. Everything will work fine except the server traces will be confusing. 2.) Remove the static modifier from the fields noHoldPKGNAMCBytes and holdPKGNAMCBytes of the org.apache.derby.client.am.SectionManager class. 3.) Also remove the static modifier as described above, but also do not send PKGNAMCSN when it is not needed and send PKGSN instead. This needs some more changes to code. The function buildPKGNAMCSN of the NetPackageRequest uses function canCommandUseDefaultPKGNAMCSN() to check whether it should send PKGNAMCSN or PKGSN. However this function always returns false. It seems that its not fully implemented. If #2 is all it takes to fix the trace, and if there are no negative effects (esp. would removing the static fields have a performance impact? Would it be enough to cause concern?), then that's what I vote for. #1 seems like a shame since, as I mentioned above, things as they are can lead to confusion and potentially wasted time. #3 seems like a slight overkill if #2 solves the problem and there's no other impact on query processing... Army
[jira] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (12 issues) Subscriber: derby-dev Key Summary DERBY-1953 Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional http://issues.apache.org/jira/browse/DERBY-1953 DERBY-183 Parameter names required in CREATE FUNCTION http://issues.apache.org/jira/browse/DERBY-183 DERBY-1951 Missing directory separator in path construction in 'NetworkServerTestSetup.setUp' http://issues.apache.org/jira/browse/DERBY-1951 DERBY-630 create trigger fails with null pointer exception http://issues.apache.org/jira/browse/DERBY-630 DERBY-1926 Provide documentation for ALTER TABLE DROP COLUMN http://issues.apache.org/jira/browse/DERBY-1926 DERBY-1938 Add support for setObject(, null) http://issues.apache.org/jira/browse/DERBY-1938 DERBY-1893 Convert largedata/lobLengthTests.java to junit http://issues.apache.org/jira/browse/DERBY-1893 DERBY-1930 Move JDBC implementation notes into the published javadoc http://issues.apache.org/jira/browse/DERBY-1930 DERBY-1918 INCREMENT of IDENTITY column described as allowing a value of zero in reference manual http://issues.apache.org/jira/browse/DERBY-1918 DERBY-963 Allow user friendly string values for security mechanism in client connection url. http://issues.apache.org/jira/browse/DERBY-963 DERBY-1808 [PATCH] Inbuilt functions SIGN, SQRT, RAND, RANDOM, COSH, SINH and TANH http://issues.apache.org/jira/browse/DERBY-1808 DERBY-646 In-memory backend storage support http://issues.apache.org/jira/browse/DERBY-646
Re: DERBY-1434 - Client can send incorrect database name to server after having made multiple connections to different databases.
Hi Bryan, Thank You for your answers. I spent more time on this (see updates in JIRA) Bryan Pendleton wrote: I think this is a key question, and we should figure it out before we have a complete change. My hunch is that the reason this doesn't cause many symptoms is because the PKGNAMCSN is basically used as a hash key on the server side, and so it doesn't really care about the contents too much; it is just using those tokens as unique identifiers to distinguish the various different statements that the client and server are currently working with. Exactly, PKGNAMCSN is used only for hashing of statements on server side. The section number in PKGNAMCSN code point is specified correctly (that's why using multiple prepared statements on the same connection works fine). Do you have a test program which demonstrates a concrete, user-visible symptom of this problem? The repro program attached to the bug causes Derby to write some strange looking trace files, but the actual query processing is all performed correctly. Query processing is always performed correctly. The only one visible impact is the server trace. So it would be really good if you could construct a test program which demonstrates the symptoms of the incorrect PKGNAMCSN field more vividly: incorrect query execution, crash or error message on the server side, etc. This is probably not possible. --- The PKGNAMCSN is not a mandatory code point according to DRDA DDM. For now I see these alternatives: 1.) Leave the code unchanged. Everything will work fine except the server traces will be confusing. 2.) Remove the static modifier from the fields noHoldPKGNAMCBytes and holdPKGNAMCBytes of the org.apache.derby.client.am.SectionManager class. 3.) Also remove the static modifier as described above, but also do not send PKGNAMCSN when it is not needed and send PKGSN instead. This needs some more changes to code. The function buildPKGNAMCSN of the NetPackageRequest uses function canCommandUseDefaultPKGNAMCSN() to check whether it should send PKGNAMCSN or PKGSN. However this function always returns false. It seems that its not fully implemented. What do you think? Cheers Julo
[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.
[ http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12441470 ] Julius Stroffek commented on DERBY-1434: The database is also choosed from RDBNAM code point also in these terms: OPNQRY, CNTQRY, PRPSQLSTT, DSCSQLSTT, EXCSQLSTT, EXCSQLIMM, EXCSQLSET, CLSQRY However, it have to be present in terms ACCRDB, ACCSEC or SECCHK in the connection before. If it is not, the error "RDBNAM Mismatch" is produced. > Client can send incorrect database name to server after having made multiple > connections to different databases. > > > Key: DERBY-1434 > URL: http://issues.apache.org/jira/browse/DERBY-1434 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.2.1.6, 10.1.3.1 >Reporter: A B > Assigned To: Julius Stroffek > Fix For: 10.2.2.0 > > Attachments: _driver_1, d1434.java, d1434_v2.java, Server2.trace > > > I have a simple program that connects to a database using the Derby Client, > executes a simple query, then connects to a different database using a > different Connection object and executes another simple query on that second > connection. The queries both execute without error, so it appears that the > connections are correct--i.e. each query will only work on one of the > databases, and both queries work, therefore each must be getting executed > against the correct database. > But in looking at the client and server traces, I noticed that for the query > on the second database, the client is actually sending the name of the > *first* database as RDBNAM, which (I think?) is wrong--it should be sending > the name of the second database, since the query is being executed on the > second Connection object. > This behavior does not appear to occur for JCC. -- 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: [VOTE] Army Brown as a committer
Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. +1. Dan.
HashJoinStrategy.feasible
Army mentioned earlier the analysis he wrote for Derby-781 (Subquery materialization via Hash Join). I've read most of that, and am confused by his analysis of this select: Q2. select 1 from tt, (t left outer join (s left outer join r on (f = i)) on (b = e)) where (j=g) Judging from the analysis, this query could be less ambiguously expressed as: select 1 from tt as T0, (t as T1 left outer join (s as T2 left outer join r as T3 on (T2.f = T3.i)) on (T1.b = T2.e)) where (T0.j=T3.g) In particular, I don't understand the claim that the subqueries can not be materialized because of the fact that the (j=g) and (b=e) predicates create a correlation between the levels. I can't see any theoretical reason why the following table expression couldn't be materialized: s as T2 left outer join r as T3 on (T2.f = T3.i) There is no correlation between this table expression and the rest of the from clause. Furthermore, there is no correlation between: (t as T1 left outer join (s as T2 left outer join r as T3 on (T2.f = T3.i)) on (T1.b = T2.e)) And the rest of the from clause (just TT in this case). My understanding of the semantics of select are that (logically) the FROM clause is executed first to produce a working table (in this case a CROSS JOIN of TT with the result of the left outer joins, which are evaluated independently of TT). Army (or anyone else), can you provide a more detailed explanation of this? Thanks, James
[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.
[ http://issues.apache.org/jira/browse/DERBY-1434?page=comments#action_12441455 ] Julius Stroffek commented on DERBY-1434: Sumarization of behaviour: 1.) For each connection to a database a Session object is created on a server. It is processed by a separate DRDAConnThread instance thread. 2.) The database is assigned to DRDAConnThread object from the RDBNAM codepoint from terms ACCRDB, ACCSEC or SECCHK, which works correctly. 3.) The Section Number in PKGNAMCSN code point is sent always correctly. This causes no problem with processing terms like CNTQRY or CLSQRY. The corresponding DRDAStatement object is found by looking for the whole PKGNAMCSN content. Because the wrong PKGNAMCSN is sent all the time and processed by the same instance of DRDAConnThread - it works also fine. The corresponding statements are managed locally by DRDAConnThread instance and the right statement is identified by the section number which is sent correctly. 3.) In case of these terms PRPSQLSTT, EXCSQLIMM, OPNQRY, CNTQRY, CLSQRY, PRPSQLSTT, DSCSQLSTT, EXCSQLSTT, the codepoint PKGNAMCSN is optional in DRDA DDM but is mandatory for Derby's implementation. Instead of sending PKGNAMCSN the PKGSN code point is sufficient. This might increase a performance a bit. Derby has also some optimalizations parsing the pkgnamcsn assuming that PKGNAMCSN is the same most of the time (I cannot see any case when it should differ). Small note: Code point PKGNAMCSN is optional in EXCSQLSET (even not described by DRDA DDM, but sent only by jcc1.2 driver), but according the comments in parseEXCSQLSET it is also required (changing the comment is sufficient). > Client can send incorrect database name to server after having made multiple > connections to different databases. > > > Key: DERBY-1434 > URL: http://issues.apache.org/jira/browse/DERBY-1434 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.2.1.6, 10.1.3.1 >Reporter: A B > Assigned To: Julius Stroffek > Fix For: 10.2.2.0 > > Attachments: _driver_1, d1434.java, d1434_v2.java, Server2.trace > > > I have a simple program that connects to a database using the Derby Client, > executes a simple query, then connects to a different database using a > different Connection object and executes another simple query on that second > connection. The queries both execute without error, so it appears that the > connections are correct--i.e. each query will only work on one of the > databases, and both queries work, therefore each must be getting executed > against the correct database. > But in looking at the client and server traces, I noticed that for the query > on the second database, the client is actually sending the name of the > *first* database as RDBNAM, which (I think?) is wrong--it should be sending > the name of the second database, since the query is being executed on the > second Connection object. > This behavior does not appear to occur for JCC. -- 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: Who would like to be a derby list moderator?
Thanks, Bernt! I'll request that you be added. which email do you want to use? thanks! -jean > Jean T. Anderson wrote (2006-10-03 20:33:37): >> Andrew and I are moderators for the derby lists. >> >> I'm also moderating some other lists, so would like to transfer derby >> moderation to another derby committer. >> >> any takers? > > I volunteer. > > -- > Bernt Marius Johnsen, Database Technology Group, > Staff Engineer, Technical Lead Derby/Java DB > Sun Microsystems, Trondheim, Norway >
[jira] Commented: (DERBY-1610) Resolve difference of type compatibility between Embedded and NetworkServer/NetworkDriver
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12441436 ] Knut Anders Hatlen commented on DERBY-1610: --- So with your +0 and my +1, the average is +0.5. :) Committed revision 462784. > Resolve difference of type compatibility between Embedded and > NetworkServer/NetworkDriver > - > > Key: DERBY-1610 > URL: http://issues.apache.org/jira/browse/DERBY-1610 > Project: Derby > Issue Type: Bug > Components: Network Server, Network Client >Reporter: Tomohito Nakayama > Assigned To: Tomohito Nakayama > Attachments: derby-1610-jdk16.diff, DERBY-1610.diff, > DERBY-1610_2.diff, DERBY-1610_3.diff, DERBY-1610_4.diff, DERBY-1610_5.diff, > DERBY-1610_6.patch, DERBY-1610_7.patch, DERBY-1610_7_regressionfix.patch, > DERBY-1610_7_regressionfix_2.patch, DERBY-1610_7_regressionfix_2_2.patch, > DERBY-1610_7_regressionfix_2_3.patch, parameterMapping.diff, > parameterMapping.diff, > parameterMapping.diff.betweenEmbedded_and_NetworkServerNetworkClient, > parameterMapping.out.7.diff, parameterMapping.out.diff, > parameterMapping_3.diff, TestNullChar.java, TestTypeCompatibility.java, > XCL12.diff > > > There exists difference of type compatibility between Embedded and > NetworkServer/NetworkClient. > This issue tries to resolve it. -- 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] Commented: (DERBY-1942) There exists difference between behavior of setNull(Types.TIME) and setTiime(null).
[ http://issues.apache.org/jira/browse/DERBY-1942?page=comments#action_12441434 ] Tomohito Nakayama commented on DERBY-1942: -- This modification would affect DATETIMEDIFF scalar function. Now DATETIMEDIFF function accept java.sql.TIME as type compatible for parameters. However modification in this patch would take it as error. I think new behavior would proper behavior but a little strict In the JDBC spec, signature for TIMESTAMPDIFF function was described as next. TIMESTAMPDIFF(interval, An integer representing the number of interval timestamp1, timestamp2) I think this description is implicit definition that the parameter should be timestamp. Well ... I will take strict way, means to regard java.sql.TIME as incompatible type for parameters in DATETIMEDIFF function. > There exists difference between behavior of setNull(Types.TIME) and > setTiime(null). > > > Key: DERBY-1942 > URL: http://issues.apache.org/jira/browse/DERBY-1942 > Project: Derby > Issue Type: Bug > Components: JDBC >Reporter: Tomohito Nakayama > Assigned To: Tomohito Nakayama > > The result of setNull(java.sql.Types.TIME) for TIMESTAMP typed variable is > regarded as error. > However, the result of setTime(null) for TIMESTAMP typed variable is not > regarded as error . > see http://issues.apache.org/jira/browse/DERBY-1610#action_12436554 -- 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] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12441405 ]
Bernt M. Johnsen commented on DERBY-1953:
-
Sorry, that was a glitch. The syntax after Yip's patch has been applied will be:
::=
[ FOR EACH { ROW | STATEMENT } [MODE DB2SQL] ]
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | STATEMENT } ]
--
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] Commented: (DERBY-1610) Resolve difference of type compatibility between Embedded and NetworkServer/NetworkDriver
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12441400 ] Tomohito Nakayama commented on DERBY-1610: -- I see. It would be a descision. My stand point is +0. > Resolve difference of type compatibility between Embedded and > NetworkServer/NetworkDriver > - > > Key: DERBY-1610 > URL: http://issues.apache.org/jira/browse/DERBY-1610 > Project: Derby > Issue Type: Bug > Components: Network Server, Network Client >Reporter: Tomohito Nakayama > Assigned To: Tomohito Nakayama > Attachments: derby-1610-jdk16.diff, DERBY-1610.diff, > DERBY-1610_2.diff, DERBY-1610_3.diff, DERBY-1610_4.diff, DERBY-1610_5.diff, > DERBY-1610_6.patch, DERBY-1610_7.patch, DERBY-1610_7_regressionfix.patch, > DERBY-1610_7_regressionfix_2.patch, DERBY-1610_7_regressionfix_2_2.patch, > DERBY-1610_7_regressionfix_2_3.patch, parameterMapping.diff, > parameterMapping.diff, > parameterMapping.diff.betweenEmbedded_and_NetworkServerNetworkClient, > parameterMapping.out.7.diff, parameterMapping.out.diff, > parameterMapping_3.diff, TestNullChar.java, TestTypeCompatibility.java, > XCL12.diff > > > There exists difference of type compatibility between Embedded and > NetworkServer/NetworkClient. > This issue tries to resolve it. -- 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] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12441390 ]
Kristian Waagan commented on DERBY-1953:
Bernt,
Are you sure the WHEN clause is supported by Derby?
Some time ago I entered DERBY-534, which asks for support for the WHEN clause.
I looked up CREATE TRIGGER in the reference manual, but could not find anything
about WHEN there.
Do we need to support WHEN to be in compliance with the SQL standard(s)?
If we already support it, the reference manual should be updated and the Jira
issue updated.
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | STATEMENT } ]
--
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: Who would like to be a derby list moderator?
Jean T. Anderson wrote (2006-10-03 20:33:37): > Andrew and I are moderators for the derby lists. > > I'm also moderating some other lists, so would like to transfer derby > moderation to another derby committer. > > any takers? I volunteer. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway pgpJ1jNmIrFKN.pgp Description: PGP signature
Re: [VOTE] Army Brown as a committer
+1 Mayuresh Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. His JIRA id is: Username:army Full Name:A B Email:[EMAIL PROTECTED] Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. Since joining the project, Army has submitted many high quality, well documented patches. He has actively participated in design discussions on the list, and has reviewed many patches from other derby developers. I believe his expertise will be valuable going forward as a derby committer. He has submitted enhancements/fixes in the areas of XML, optimizer and network server: DERBY-1866 DERBY-1777 DERBY-1776 DERBY-1775 DERBY-1772 DERBY-1759 DERBY-1681 DERBY-1633 DERBY-1507 DERBY-1365 DERBY-1357 DERBY-1329 DERBY-1315 DERBY-1109 DERBY-1073 DERBY-1007 DERBY-805 DERBY-781 DERBY-688 DERBY-675 DERBY-567 DERBY-563 DERBY-558 DERBY-522 DERBY-388 DERBY-337 DERBY-334 DERBY-319 DERBY-194 DERBY-157 DERBY-121 DERBY-107 DERBY-90 DERBY-40 DERBY-35 DERBY-5
Re: [VOTE] Army Brown as a committer
+1 Mike Matrigali wrote: > . > Please vote +1 if you approve of Army as a committer. > Voting will close 5pm PST Thursday, October 19th. . > -- Ole
[jira] Commented: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[
http://issues.apache.org/jira/browse/DERBY-1953?page=comments#action_12441383 ]
Bernt M. Johnsen commented on DERBY-1953:
-
No, I don't mind ;-) The change for DERBY-1770 is trivial anyway. Two comments
though:
1) The standard syntax for :
::=
[ FOR EACH { ROW | STATEMENT } ]
[ WHEN]
is now in Derby:
::=
[ FOR EACH { ROW | STATEMENT } [MODE DB2SQL] ]
[ WHEN]
One could have considered
[ FOR EACH { ROW | STATEMENT } ] [MODE DB2SQL]
instead.
If MODE DB2SQL some time in the future ended up with some semantic meaning, it
would have been nice to have it independent of the FOR EACH part of the
statement. I'm not sure if it natters very much.
2) I was planning to change nearly all tests to go without MODE DB2SQL, and
just keep the keywords in db2Compatility.sql. After all, it's harder to get the
parser right without these keywords, so that should be the norm in the tests.
I'll continue that part of my DERBY-1770 work, since Yip's patch just does some
few test extensions.
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: SQL
>Affects Versions: 10.2.1.6
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Attachments: derby1953-trunk-diff01.txt, derby1953-trunk-diff02.txt,
> derby1953-trunk-stat01.txt, derby1953-trunk-stat02.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | STATEMENT } ]
--
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: [VOTE] Army Brown as a committer
Mike Matrigali wrote: This vote is for establishing Army Brown as a committer for Derby. Please vote +1 if you approve of Army as a committer. +1 -- John
Re: [VOTE] Army Brown as a committer
Mike Matrigali <[EMAIL PROTECTED]> writes: > Please vote +1 if you approve of Army as a committer. +1 -- Knut Anders
[jira] Commented: (DERBY-1811) Embedded ResultSet.getTimestamp on a TIME column returns a java.sql.Timestamp with a date portion that can be incorrect.
[ http://issues.apache.org/jira/browse/DERBY-1811?page=comments#action_12441379 ] Kristian Waagan commented on DERBY-1811: Has all work been finsihed on this issue? If so, please close it. I was looking at this because we now see failures in the All suite for TimeHandlingTest under DerbyNetClient. > Embedded ResultSet.getTimestamp on a TIME column returns a java.sql.Timestamp > with a date portion that can be incorrect. > > > Key: DERBY-1811 > URL: http://issues.apache.org/jira/browse/DERBY-1811 > Project: Derby > Issue Type: Bug > Components: JDBC >Affects Versions: 10.1.3.1, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0, > 10.0.2.2, 10.1.3.2, 10.1.4.0, 10.2.1.6, 10.3.0.0 >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner > Fix For: 10.3.0.0 > > Attachments: derby1811_diff.txt > > > The date portion of the java.sql.Timestamp from a TIME column is intended to > be the current date but instead can be any date value, based upon the last > getXXX call that required a Java Calendar object. -- 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] Commented: (DERBY-1610) Resolve difference of type compatibility between Embedded and NetworkServer/NetworkDriver
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12441374 ] Knut Anders Hatlen commented on DERBY-1610: --- Thanks Tomohito. If the methods are static, each setter method must call getColumnMetaDataX(), getColumnType() and checkForEscapedCallWithResult(). I think it is better to have these calls in checkTypeForXXX() because it makes the setters cleaner and reduces the footprint. Since it reduces the amount of duplicated code, I think it also makes the code more maintainable. > Resolve difference of type compatibility between Embedded and > NetworkServer/NetworkDriver > - > > Key: DERBY-1610 > URL: http://issues.apache.org/jira/browse/DERBY-1610 > Project: Derby > Issue Type: Bug > Components: Network Server, Network Client >Reporter: Tomohito Nakayama > Assigned To: Tomohito Nakayama > Attachments: derby-1610-jdk16.diff, DERBY-1610.diff, > DERBY-1610_2.diff, DERBY-1610_3.diff, DERBY-1610_4.diff, DERBY-1610_5.diff, > DERBY-1610_6.patch, DERBY-1610_7.patch, DERBY-1610_7_regressionfix.patch, > DERBY-1610_7_regressionfix_2.patch, DERBY-1610_7_regressionfix_2_2.patch, > DERBY-1610_7_regressionfix_2_3.patch, parameterMapping.diff, > parameterMapping.diff, > parameterMapping.diff.betweenEmbedded_and_NetworkServerNetworkClient, > parameterMapping.out.7.diff, parameterMapping.out.diff, > parameterMapping_3.diff, TestNullChar.java, TestTypeCompatibility.java, > XCL12.diff > > > There exists difference of type compatibility between Embedded and > NetworkServer/NetworkClient. > This issue tries to resolve it. -- 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: [VOTE] Army Brown as a committer
Mike Matrigali wrote: Please vote +1 if you approve of Army as a committer. Voting will close 5pm PST Thursday, October 19th. +1
