Re: DB2 mode vs. Cloudscape mode
Yes, you are right... The references to "DB2 mode" is from the past, leftover comments. There is no distinction between the two. Satheesh Bernt M. Johnsen wrote: Hi all! In the Derby source, I find several comments referring to "DB2 mode" and "Cloudscape mode". I can't, however, find any code related to a distinction between these two modes. Are these comments "leftovers" from the pre-Derby period of the code, or have I missed something? The reason I wonder is the error message ij> create table tab (i integer primary key); ERROR 42831: 'I' cannot be a column of a primary key or unique key because it can contain null values. and comments in the code like * Set all columns in that appear in a primary/unique key constraint in a create * table statement to NOT NULL in Cloudscape mode and raises an error in DB2 mode. and /* For primary/unique/unique keys, verify that the constraint's column * list contains valid columns and does not contain any duplicates * (Also, all columns in a primary key will be set to non-null, but only in Cloudscape mode. SQL and DB2 require explict NOT NULL.
Re: DB2 mode vs. Cloudscape mode
Yes, Cloudscape used to allow creating UNIQUE indexes on null columns, but in a non-standard way. Old cloudscape used to allow only one NULL value in the UNIQUE index, where as, I think the standard required multiple NULL values. I think making Derby handle multiple NULLs in UNIQUE index needs changes to store/indexing. Satheesh Jeremy Boynes wrote: > Satheesh Bandaram wrote: > >> Yes, you are right... The references to "DB2 mode" is from the past, >> leftover comments. There is no distinction between the two. >> > > Did Cloudscape support UNIQUE on possibly null columns? If so, is this > a restriction that we can easily remove or is there something deep in > the index code that would make this problematic? > > Also, can anyone think of an issue with making the NOT NULL implicit > in a PRIMARY KEY specification (per spec but unlike DB2)? > > -- > Jeremy > > >
Re: Case Sensitivity
I personally like the functional indexes. I think they are useful for all cases where querries have expressions in predicates. Satheesh Jeremy Boynes wrote: > This is a subject that keeps coming up on the mailing lists so is > probably worth addressing. > > One challenge we face is that many users are likely to be considering > Derby as an alternative to MySQL which by default uses a > case-insensitive collation. This is legal SQL, just different from > most other databases (Oracle, DB2, SQL Server (which actually allows > you to choose when you create the database)). > > The standard way of solving this would be to support user-specified > character sets and collations per the spec but > 1) that's likely to be a lot of work > 2) I don't know of another database that actually does this the way >the spec says, making us "different", and > 3) it is likely to be more confusing than helpful > > Other options include: > a) support collation specification at the schema level like SQL Server > b) support function-based indexes, so users can create indexes >on UPPER(col) to reduce the performance hit > c) just document and offer workarounds (like adding a second column) > d) change Derby to be like MySQL (gets a -1 from me but ...) > > Thoughts? > -- > Jeremy > > >
Re: [PATCH] Derby-107, Phase III
Submitted this patch. Let me know if anything is missing or incorrect. Satheesh Adding java\build\org\apache\derbyBuild\ODBCMetadataGenerator.java Sendingjava\build\org\apache\derbyBuild\build.xml Adding java\build\org\apache\derbyBuild\odbcgen_fragments.properties Sendingjava\drda\build.xml Sendingjava\engine\org\apache\derby\catalog\SystemProcedures.java Sending java\engine\org\apache\derby\impl\jdbc\EmbedDatabaseMetaData.java Sendingjava\engine\org\apache\derby\impl\jdbc\metadata.properties Adding java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\odbc_metadata.out Adding java\testing\org\apache\derbyTesting\functionTests\master\odbc_metadata.out Sending java\testing\org\apache\derbyTesting\functionTests\suites\derbylang.runall Sending java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall Sending java\testing\org\apache\derbyTesting\functionTests\suites\j9derbynetmats.runall Sending java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\metadata.java Adding java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\metadata_test.java Adding java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\odbc_metadata.java Sendingtools\ant\properties\dirs.properties Transmitting file data Committed revision 156209. Army wrote: For background on this patch and for the "Phase I" and "Phase II" patches that precede this one, please see the following emails: http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200502.mbox/[EMAIL PROTECTED] http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200502.mbox/[EMAIL PROTECTED] *** NOTE TO COMMITTERS: *** This patch is BASED ON THE PHASE I AND PHASE II PATCHES. Therefore, please do NOT commit this patch until after the Phase I and Phase II patches have been committed. I posted the Phase I patch to derby-dev on Feb 3rd and the (revised) Phase II patch on February 15th; they can be referenced at the links given above. I have run the derbyall test suite with these changes, using Windows with Sun JDK 1.4.2, and have included the relevant master updates as part of the patch. I have also reworked the "metadata.java" test and extended it with a new test, "odbc_metadata.java", for purposes of verifying the ODBC metadata behavior. Attached is a patch for Phase III (the final phase) of my proposal for fixing Derby-107: "Phase III) Submit a patch that will automatically generate ODBC metadata statements at Derby build time, and that will add support for such metadata statements in the Derby engine (so that ODBC clients using Derby Network Server can use a Derby database)." -- Pasted from my first email referenced above. Following is a detailed description of what all this patch does, for those interested. I) New Files This patch adds the following new files to the Derby codeline: 1. java/build/org/apache/derbyBuild/ODBCMetadataGenerator.java This is the primary class for generating ODBC-compliant metadata queries. It reads the existing, JDBC metadata queries from "java/org/apache/derby/impl/jdbc/metadata.properties" and writes all of those queries back out to a new file called "odbc_metadata.properties". Then, where appropriate, this class duplicates the JDBC queries and makes alterations to them in order to create ODBC-compliant versions. These ODBC-compliant queries are written to odbc_metadata.properties, as well, so that in the end, ALL metadata queries (JDBC and OBDC alike) have been written to that output file. At build time, an ant process executes this class and then clobbers the existing (JDBC only) version of metadata.properties (the copy in the CLASSES directory, not the copy in the source directory) with the contents of the new output file, "odbc_metadata.properties". The result is that metadata.properties as it exists in the _build_ directory will contain both JDBC and, where needed, ODBC metadata queries, and both sets of queries will be loaded as internal prepared statements for the Derby engine at database creation time. NOTE: This class is ONLY used at build time, and does NOT end up in the org.apache.derby.* package, so it will not be included in any Derby jar files. 2. java/build/org/apache/derbyBuild/odbcgen_fragments.properties This is a helper file for the ODBCMetadataGenerator class. This file contains SQL fragments that are specific to the ODBC metadata queries, and thus it does NOT (and probably shouldn't ever) contain any SQL that already exists in the source copy of "metadata.properties"--otherwise, we'd end up having to maintain two copies of the overlapping metadata SQL, which would defeat the whole purpose of automatic query generation. SQL fragments in this file are pulled into the ODBC queries as part of
Re: Single JDK14 compile model?
I am not sure if each platform module would be small... Unless we are talking about a really small number of files, this could cause maintenance issues. Even in closed development enviornments, products take extreme care to avoid code duplication.. It might be a bigger challenge in open source setup... Having three (ME, JDK1.3, JDK1.4) or even four (with JDK1.5) versions of the code doesn't seem right. It is a good goal to have developpers develop on one platform. Not sure what it the right way to get there ... Satheesh Jeremy Boynes wrote: > If we had three small modules for the JDBC API impls then they could > be compiled once under the appropriate JDK and then just referenced by > others as needed (e.g. during packaging). The amount of code in each > would be small and stagnant so there would be no need to build from > source all the time. > > Under this model, I could do all my development and testing using 1.4 > and the JDCB3.0 modules and you would do all your development and > testing using J2ME and the JSR169 modules. We take care in shared code > not to use features that are not available in the other platform. We > both make progress, and rapidly because we can concentrate on the > feature we're working on rather than the cross-platform build. > > Every so often, say nightly, an automated process builds all versions > on all platforms so as a whole we catch any issues with inappropriate > dependencies or non-portable code. That process may be Gump, it may be > something else. > > For this to work, we would need to break things down so that a > developer could work with just one platform at a time. I think that > means moving away from the one-jar-fits-all model to a > package-by-platform model. > > -- > Jeremy > > >
Re: [VOTE] Documentation source location in subversion
+1 for option 2. Satheesh Andrew McIntyre wrote: > Recently, a vote was approved that the source for the Derby > documentation should be XML DITA format. Details can be found in > these threads: > > http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200502.mbox/ > [EMAIL PROTECTED] > http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200503.mbox/ > [EMAIL PROTECTED] > > These source files should now be stored in the Subversion repository. > Please vote on one of the following locations to store the source: > > 1 - in derby/code, with each branch getting its own copy of the > source as applicable, in docs/src > > 2 - in derby/docs, a new module with a similar trunk/branches/tags > layout underneath to easily match the version of the documentation to > the corresponding code. > > 3 - a hybrid approach, with the source checked in to derby/code, and > the remaining files necessary to build the docs in derby/docs as > suggested here: > > http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200503.mbox/ > [EMAIL PROTECTED] > > After reviewing the source, which comprises almost 1100 files (nearly > as many as the engine!), and will have its own building requirements, > I am now thinking that everyone will be happier if the docs are > managed separately from either the code or the website. > > My +1 vote goes to option 2. > > andrew > > >
Re: [jira] Resolved: (DERBY-158) PRIMARY KEY does not imply NOT NULL
This modifies the behaviour of Derby and hence needs documentation. How are the documentation changes tracked? Are committers expected to file another Jira documentation item? Just wondering... Documentation like these need to be changed: http://incubator.apache.org/derby/manuals/reference/sqlj32.html#HDRSII-SQLJ-13590 Satheesh Jeremy Boynes (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-158?page=history ] Jeremy Boynes resolved DERBY-158: - Resolution: Fixed Fix Version: 10.1.0.0 URL: http://svn.apache.org/viewcvs?view=rev&rev=156570 Log: Fix for DERBY-158 PRIMARY KEY does not imply NOT NULL Columns specified in a PRIMARY KEY constraint in CREATE TABLE are implicitly set to NOT NULL per the SQL spec. If a PRIMARY KEY constraint is added using ALTER TABLE then all columns must also be NOT NULL. Similarly, columns specified in a UNIQUE constraint must still be explictly NOT NULL. Modified: incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/compile/TableElementList.java incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/db2Compatibility.out incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/nulls.out incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/primarykey.out incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/db2Compatibility.sql incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/nulls.sql incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/lang/primarykey.sql PRIMARY KEY does not imply NOT NULL --- Key: DERBY-158 URL: http://issues.apache.org/jira/browse/DERBY-158 Project: Derby Type: Bug Components: SQL Reporter: Bernt M. Johnsen Assignee: Jeremy Boynes Priority: Minor Fix For: 10.1.0.0 Attachments: derby-158-1.patch, derby-158-2.patch PRIMARY KEY does not imply NOT NULL. Derby issues error message: ij> create table tab (i integer primary key); ERROR 42831: 'I' cannot be a column of a primary key or unique key because it can contain null values. This is neither compliant with SQL-92 nor with SQL-99 (Feature E141-08, I think).
Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs
I will work to get this committed real soon... Sorry for the delay. This is a bigger patch, requires more time from me.. :-) If you have the code and build setup, it is possible to apply this patch to your codebase and use it or test it. You might find issues or bugs that way too! Satheesh Edward Rayl wrote: Dan, I was afraid I might get that answer, and maybe I deserve it. I know I need this feature for a project yesterday, but I have no experience in Derby database implementation details. My comment is this feature is supported in most commercial and open source databases, for instance Oracle (commercial) and MySQL(open source). It would allow for easier database and application migration. As for review... you don't really want me doing that ;-) Ed Edward Rayl wrote: I'm starting to wonder if this is on any of the reviewers' radar screen. It's been two weeks with no comments. Just a reminder that anyone can review and comment on patches or code changes. Dan.
Re: [PATCH] (DERBY-169) DatabaseMetaData calls related to changes made by others return incorrect values in Network Server mode.
This patch is committed. Sending java\engine\org\apache\derby\impl\sql\catalog\metadata_net.properties Sending java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\metadataJdbc20.out Sending java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\metadataJdbc20.out Sending java\testing\org\apache\derbyTesting\functionTests\master\metadataJdbc20.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\metadataJdbc20.java Transmitting file data . Committed revision 157015. Satheesh Mamta Satoor wrote: On Wed, 9 Mar 2005 08:41:52 +0100 (CET), Mamta A. Satoor (JIRA) wrote: DatabaseMetaData calls related to changes made by others return incorrect values in Network Server mode. Key: DERBY-169 URL: http://issues.apache.org/jira/browse/DERBY-169 Project: Derby Type: Bug Components: Network Server Versions: 10.0.2.1 Reporter: Mamta A. Satoor Assigned to: Mamta A. Satoor I am working on getting updatable resultsets to work under Network Server mode. While running the test lang/updatableResultSet.java in Network Server mode, I came across following issue. DatabaseMetaData among other methods has 3 methods, othersUpdatesAreVisible, othersDeletesAreVisible and othersInsertsAreVisible. These 3 methods currently return true for TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE when running in Network Server mode. They should be returning false for TYPE_SCROLL_INSENSITIVE and TYPE_SCROLL_SENSITIVE. The reason for that is Derby does not yet implement scroll sensitive ResultSets and hence the 3 metadata calls mentioned above should return false. Also, scroll insensitive ResultSets by their definition do not see changes made by others and hence the 3 metadata calls should return false. The fix for this is very easy and requires changes in apache\derby\impl\sql\catalog\metadata_net.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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira Here is a very simple fix for the bug with the tests, I have run the test suites and the fix hasn't caused any failures. svn stat output M java\engine\org\apache\derby\impl\sql\catalog\metadata_net.properties M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\metadataJdbc20.java M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\metadataJdbc20.out M java\testing\org\apache\derbyTesting\functionTests\master\metadataJdbc20.out M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\metadataJdbc20.out Thanks, Mamta Index: java/engine/org/apache/derby/impl/sql/catalog/metadata_net.properties === --- java/engine/org/apache/derby/impl/sql/catalog/metadata_net.properties (revision 156618) +++ java/engine/org/apache/derby/impl/sql/catalog/metadata_net.properties (working copy) @@ -298,9 +298,9 @@ '',\ '',\ '',\ - '1003,1004,1005',\ - '1003,1004,1005',\ - '1003,1004,1005',\ + '1003',\ + '1003',\ + '1003',\ '',\ '',\ '',\ Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/metadataJdbc20.java === --- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/metadataJdbc20.java (revision 156618) +++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/metadataJdbc20.java (working copy) @@ -88,6 +88,21 @@ userNamedTypes[1] = java.sql.Types.STRUCT; dumpRS(met.getUDTs("a", null, null, userNamedTypes)); + System.out.println("Test the metadata calls related to visibility of changes made by others for different resultset types"); + System.out.println("Since Derby materializes a forward only ResultSet incrementally, it is possible to see changes"); + System.out.println("made by others and hence following 3 metadata calls will return true for forward only ResultSets."); + System.out.println("othersUpdatesAreVisible(ResultSet.TYPE_FORWARD_ONLY)? " + met.othersUpdatesAreVisible(ResultSet.TYPE_FORWARD_ONLY)); + System.out.println("othersDeletesAreVisible(ResultSet.TYPE_FORWARD_ONLY)? " + met.othersDeletesAreVisible(ResultSet.TYPE_FORWARD_ONLY)); + System.out.println("othersInsertsAreVisible(ResultSet.TYPE_FORWARD_ONLY)? " + met.othersInsertsAreVisible(ResultSet.TYPE_FORWARD_ONLY)); + System.out.println("Scroll insensitive ResultSet by their definition do not see changes made by others and hence following metadata calls return false"); + System.out.println("othersUpdatesAreVisible(ResultSet.TYPE_SCROLL_INSENSITIVE)? "
Re: [jira] Commented: (DERBY-172) Trigger activation
I personally think able to change values in BEFORE triggers would be great to have. A SET new.column = xxx would be nice, but that falls under SQL Stored Procedure language that Derby doesn't have. Commercial databases like DB2 has DB2 SQL Procedure language, Oracle has PL/SQL and Informix has support for SPL. It would be nice to add that capability to Derby. You can code your trigger logic in Derby Java functions, but Derby only supports read-only operations in BEFORE triggers. Satheesh George Baklarz wrote: >Thanks for the update. I was curious why it was supporting the syntax >(well, close to it). The SYSTRIGGERS catalog table obviously had a slot for >this type of trigger. I would have preferred the ability to change column >values before having the statement execute though. Is there anything I can >do from a logic perspective in a BEFORE trigger like a WHEN clause? Or does >it always execute the statement: > >CREATE TRIGGER XXX NO CASCADE BEFORE INSERT ON A > REFERENCING OLD AS OLD NEW AS NEW FOR EACH ROW > ... SELECT or VALUES... > >A SET NEW.column = xxx would have been nice. > >George >___ > >George Baklarz | Senior Manager, Worldwide DB2 Sales Support | (+1) >905-413-2798 | T/L 969-2798 | [EMAIL PROTECTED] > > > > "Daniel John > Debrunner (JIRA)" > <[EMAIL PROTECTED] To > che.org> George Baklarz/Toronto/[EMAIL > PROTECTED] >cc > 03/10/2005 09:11 > PMSubject > [jira] Commented: (DERBY-172) > Trigger activation > > > > > > > > > > > [ >http://issues.apache.org/jira/browse/DERBY-172?page=comments#action_60634 ] > >Daniel John Debrunner commented on DERBY-172: >- > >BEFORE triggers do work but they have the restriction that the trigger >action must be read-only, that is a SELECT statement or a VALUES claues. >The action statement can call a user defined Java function that could send >e-mail or perform validation. > >Enabling the before triggers was last minute item before the code was >contributed. > > > >>Trigger activation >>-- >> >> Key: DERBY-172 >> URL: http://issues.apache.org/jira/browse/DERBY-172 >> Project: Derby >>Type: Bug >> Components: Documentation >>Versions: 10.0.2.0 >> Environment: Windows XP SP1 Windows >>Reporter: George Baklarz >>Priority: Minor >> >> > > > >>I image that this is a documentation problem. The "words" around triggers >> >> >seem to imply the ability to do actions "BEFORE" the INSERT/UPDATE/DELETE. >For instance: > > >>"Along with constraints, triggers can help enforce data integrity rules >> >> >with actions such as cascading deletes or updates. Triggers can also >perform a variety of functions such as issuing alerts, updating other >tables, sending e-mail, and other useful actions." > > >>Well, the CREATE TRIGGER command only allows AFTER as an option (even >> >> >though the SYSTRIGGERS catalog uses "B" for before and "A" for after) and >it won't allow a CALL statement to be processed. Seems to me that there >aren't any ways to send an e-mail, issue alerts (no SIGNAL function >either), or enforce integrity rules. How can you enforce integrity rules if >invalid data comes in? I can't force a SIGNAL or error with the trigger, so >this is useless for validating changes to the data. > > >>In addition, there appears to be some logic regarding BEFORE triggers in >> >> >Derby, but its not currently working. > > >>CREATE TRIGGER CB NO CASCADE BEFORE >> INSERT ON BONUSES >> REFERENCING NEW AS n >> FOR EACH ROW MODE DB2SQL >> UPDATE BONUSES >> SET BONUS = >> CASE >>WHEN (n.BONUS = 0) THEN 100 >>ELSE n.BONUS >> END; >>ERROR 42Z9D: 'UPDATE' statements are not allowed in 'BEFORE' triggers. >> >> > >-- >This message is automatically generated by JIR
Re: About improvement of DERBY-134
Hi Tomohito Nakayama, (B (BJust wanted to check how you are progressing on the patch update, (Bfollowing comments by myself and Jack. I do think you are working on an (Bimportant enhancement that not only yourself but other developpers have (Bexpressed interest in. I strongly encourage you to continue working on (Bthis and post any questions or comments you might have. You are pretty (Bclose to addressing all issues. (B (BI am willing to help, if you need any, to continue taking this further. (B (BSatheesh (B (BTomohitoNakayama wrote: (B (B> Hello. (B> Thanks for your reviewing. (B> (B> About 1: (B> Handling any sortKey as expression is better structure. (B> A little challenging but worth for it. (B> I will try. (B> (B> About 2: (B> Uh oh. (B> Bug about starting value of element indexing in ResultColumnList (B> Test of comma separated lists of ORDER BY expressions in orderby.sql (B> was needed. (B> (B> About 3: (B> I see. (B> It seems that it is certainly needed to add test case . (B> (B> I will continue this issue. (B> Best regards. (B> (B> /* (B> (B> Tomohito Nakayama (B> [EMAIL PROTECTED] (B> [EMAIL PROTECTED] (B> (B> Naka (B> http://www5.ocn.ne.jp/~tomohito/TopPage.html (B> (B> */ (B> - Original Message - From: "Jack Klebanoff" (B> <[EMAIL PROTECTED]> (B> To: "Derby Development" (B> Sent: Sunday, February 20, 2005 8:37 AM (B> Subject: Re: About improvement of DERBY-134 (B> (B> (B>> TomohitoNakayama wrote: (B>> (B>>> Hello. (B>>> (B>>> I have put some LOOKAHEAD to sqlgrammer.jj and (B>>> add some test pattern to orderby.sql. (B>>> (B>>> Would someone review patch please ? (B>>> (B>>> Best regards. (B>>> (B>>> /* (B>>> (B>>> Tomohito Nakayama (B>>> [EMAIL PROTECTED] (B>>> [EMAIL PROTECTED] (B>>> (B>>> Naka (B>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html (B>>> (B>>> */ (B>>> - Original Message - From: "TomohitoNakayama" (B>>> <[EMAIL PROTECTED]> (B>>> To: "Derby Development" (B>>> Sent: Sunday, February 13, 2005 4:09 PM (B>>> Subject: Re: About improvement of DERBY-134 (B>>> (B>>> (B>>>> Sorry. (B>>>> Mistaken. (B>>>> (B>>>> LOOKAHEAD() (B>>>> (B>>>> /* (B>>>> (B>>>> Tomohito Nakayama (B>>>> [EMAIL PROTECTED] (B>>>> [EMAIL PROTECTED] (B>>>> (B>>>> Naka (B>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html (B>>>> (B>>>> */ (B>>>> - Original Message - From: "TomohitoNakayama" (B>>>> <[EMAIL PROTECTED]> (B>>>> To: "Derby Development" (B>>>> Sent: Sunday, February 13, 2005 3:42 PM (B>>>> Subject: Re: About improvement of DERBY-134 (B>>>> (B>>>> (B>>>>> Hello. (B>>>>> (B>>>>> Thank's for your reviewing. (B>>>>> Grammer ambiguity is very critical problem (B>>>>> (B>>>>> I will try to put LOOKUP() and consider about testing.. (B>>>>> (B>>>>> #World is not simple as I wish to be. (B>>>>> (B>>>>> Best regards. (B>>>>> (B>>>>> /* (B>>>>> (B>>>>> Tomohito Nakayama (B>>>>> [EMAIL PROTECTED] (B>>>>> [EMAIL PROTECTED] (B>>>>> (B>>>>> Naka (B>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html (B>>>>> (B>>>>> */ (B>>>>> - Original Message - From: Satheesh Bandaram (B>>>>> To: Derby Development (B>>>>> Sent: Saturday, February 12, 2005 4:10 AM (B>>>>> Subject: Re: About improvement of DERBY-134 (B>>>>> (B>>>>> (B>>>>> I think the patch is a good start. But more work needs to be done. (B>>>>> Based on a quick review, some of the items to be completed are: (B>>>>> (there may be more) (B>>>>> (B>>>>> Grammar ambiguity. SortKey() has grammar ambiguity the way the patch (B>>>>> is written. Since orderby expression and orderby column can both (B>>>>> start with an identifier, this causes ambiguity. Need to rewrite or (B>>>>&g
Re: [jira] Commented: (DERBY-147) ERROR 42X79 not consistant ? - same column name specified twice
Hi Bernd, Just following up to check how your patch making is comming along. You already have the code change and you wanted to attempt to make a patch. Let me know if you are stuck or need more assistance. If changing test suites to add test cases seem daunting, let me know. For this case, I am willing to work with you to add required testing support. Satheesh Bernd Ruehlicke (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-147?page=comments#action_59875 ] Bernd Ruehlicke commented on DERBY-147: --- Ok I made the changes and build Derby - and tested it - seams to work. We may consider to make this change permanent. Any reason for this error log was added ? Here the code snipled (need to chnage getOrderBy(String, String) and getOrderBy(String, String, int) ... if (columnName.equals( resultColumn.getName()) ) { if (retVal == null) { retVal = resultColumn; } // DERBY-147else if (index < size - orderBySelect) // DERBY-147{ // DERBY-147 throw StandardException.newException(SQLState.LANG_DUPLICATE_COLUMN_FOR_ORDER_BY, columnName); // DERBY-147} else {// remove the column due to pullup of orderby item removeElement(resultColumn); decOrderBySelect(); break; } } ... By the way - if already at the code - and since the code is more or less the same would be handy to refactor the getOrderBy(String, String) to getOrderBy(String, String) { return getOrderBy(String, String, null); } and handle "null" in the String, String, int method. B-) ERROR 42X79 not consistant ? - same column name specified twice --- Key: DERBY-147 URL: http://issues.apache.org/jira/browse/DERBY-147 Project: Derby Type: Bug Reporter: Bernd Ruehlicke This happens from JDBC or ij. Here the output form ij> ij version 10.0 CONNECTION0* - jdbc:derby:phsDB * = current connection ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1 ORDER BY a1.XXX_foreign; ERROR 42X79: Column name 'XXX_FOREIGN' appears more than once in the result of the query _expression_. But when removing the ORDER BY and keeping the 2 same column names it works ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1; XXX_FOREIGN |NATIVE |KIND|XXX_FOREIGN --- 0 rows selected ij> So - it seams to be OK to specify the same column twice - as long as you do not add the ORDER BY clause. I woul dof course like that the system allows this - but at leats it should be consistant and either allow both or none of the two queries above.
Re: About improvement of DERBY-134
I agree with Jeremy Boynes view that order by number should only (Brecognise simple numbers. I personnally think he has already provided a (Bgood argument for that. If no one objects, I think the patch can proceed (Bassuming a simple number for order by. (B (BSatheesh (B (BTomohitoNakayama wrote: (B (B> Hello. (B> (B> Sorry for my silence. (B> I was in a little private trouble in these weeks. (B> (B> About for DERBY-134, I was at a loss how to treat column referenced by (B> number. (B> (B> In point of view for implementation, (B> it seem to be difficult to treat expression except for simple number (B> as reference by number. (B> I couldn't get value by getConstantValueAsObject() of BinaryOperatorNode. (B> (B> In point of view for specification, there exists topic which was (B> written in mail of Jeremy Boynes . (B> In addition to that, reference by number in order clause seems to be (B> not recommended spec of SQL . (B> (B> I wonder allowing only simple number as reference to column may be (B> reasonable spec. (B> (B> Best regards. (B> (B> /* (B> (B> Tomohito Nakayama (B> [EMAIL PROTECTED] (B> [EMAIL PROTECTED] (B> (B> Naka (B> http://www5.ocn.ne.jp/~tomohito/TopPage.html (B> (B> */ (B> - Original Message - From: "Satheesh Bandaram" (B> <[EMAIL PROTECTED]> (B> To: "Derby Development" (B> Sent: Saturday, March 12, 2005 6:59 AM (B> Subject: Re: About improvement of DERBY-134 (B> (B> (B>> Hi Tomohito Nakayama, (B>> (B>> Just wanted to check how you are progressing on the patch update, (B>> following comments by myself and Jack. I do think you are working on an (B>> important enhancement that not only yourself but other developpers have (B>> expressed interest in. I strongly encourage you to continue working on (B>> this and post any questions or comments you might have. You are pretty (B>> close to addressing all issues. (B>> (B>> I am willing to help, if you need any, to continue taking this further. (B>> (B>> Satheesh (B>> (B>> TomohitoNakayama wrote: (B>> (B>>> Hello. (B>>> Thanks for your reviewing. (B>>> (B>>> About 1: (B>>> Handling any sortKey as expression is better structure. (B>>> A little challenging but worth for it. (B>>> I will try. (B>>> (B>>> About 2: (B>>> Uh oh. (B>>> Bug about starting value of element indexing in ResultColumnList (B>>> Test of comma separated lists of ORDER BY expressions in orderby.sql (B>>> was needed. (B>>> (B>>> About 3: (B>>> I see. (B>>> It seems that it is certainly needed to add test case . (B>>> (B>>> I will continue this issue. (B>>> Best regards. (B>>> (B>>> /* (B>>> (B>>> Tomohito Nakayama (B>>> [EMAIL PROTECTED] (B>>> [EMAIL PROTECTED] (B>>> (B>>> Naka (B>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html (B>>> (B>>> */ (B>>> - Original Message - From: "Jack Klebanoff" (B>>> <[EMAIL PROTECTED]> (B>>> To: "Derby Development" (B>>> Sent: Sunday, February 20, 2005 8:37 AM (B>>> Subject: Re: About improvement of DERBY-134 (B>>> (B>>> (B>>>> TomohitoNakayama wrote: (B>>>> (B>>>>> Hello. (B>>>>> (B>>>>> I have put some LOOKAHEAD to sqlgrammer.jj and (B>>>>> add some test pattern to orderby.sql. (B>>>>> (B>>>>> Would someone review patch please ? (B>>>>> (B>>>>> Best regards. (B>>>>> (B>>>>> /* (B>>>>> (B>>>>> Tomohito Nakayama (B>>>>> [EMAIL PROTECTED] (B>>>>> [EMAIL PROTECTED] (B>>>>> (B>>>>> Naka (B>>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html (B>>>>> (B>>>>> */ (B>>>>> - Original Message - From: "TomohitoNakayama" (B>>>>> <[EMAIL PROTECTED]> (B>>>>> To: "Derby Development" (B>>>>> Sent: Sunday, February 13, 2005 4:09 PM (B>>>>> Subject: Re: About improvement of DERBY-134 (B>>>>> (B>>>>> (B>>>>>> Sorry. (B>>>>>> Mistaken. (B>>>>>> (B>>>>>> LOOKAHEAD() (B>>>>>> (B>>&g
Re: About improvement of DERBY-134
Also, if we disallow C1/C1, how about (C1+C2)/(C2+C1)? Same question for (C1+C1)/2*C1. How intelligent do we need to make this thing? I still vote for the simplest approach, proposed by Jeremy. I also tried this on DB2 that I have access to. This what is proposed by Tomohito and Jeremy matches that behaviour. Satheesh db2 => select * from t I J --- --- 1 1 2 2 0 4 5 0 db2 => select * from t order by 1+1 I J --- --- 1 1 2 2 0 4 5 0 db2 => select * from t order by 2 I J --- --- 5 0 1 1 2 2 0 4 Jeremy Boynes wrote: > Daniel John Debrunner wrote: > >> > > If it made it clearer I would prefer that a compilation error is > raised > >> for order by expressions that do resolve to constants, since supporting >> them adds no value. How this error would be raised I'm not sure about. >> >> ORDER BY 1 - ok (column position 1) >> ORDER BY C1 - ok >> ORDER BY FN(C1) - ok >> ORDER BY 1 + 1 - disallow >> ORDER BY C1/C1 - disallow >> > > The spec says that the sort keys are value expressions which would > make both "ORDER BY 1+1" and "ORDER BY C1/C1" valid SQL so we can't > raise an error. > > In both cases the result is implementation dependent as the key will > be the same for all rows. I think /choosing/ to define the result when > the value expression is a simple integer literal is useful so we can > support the "ORDER BY 1,2" syntax common on other platforms; I believe > anything more complex than that is going to be confusing. > > This may make the parser more complex, but that's a development issue > not a user one :-) > > -- > Jeremy > >
Re: About improvement of DERBY-134
I think new behavior is a bug... and should be addressed in the patch. Since there is no column name called 'SQLCol1' in the user querry, accepting an order by with that name is incorrect. Column names like these are generated names when there is no exposed name or alias provided for the result columns. Derby generates these names and should be hidden to the end user. It should be easy to address this. You probably need to mark any new expressions you are adding as generated columns using setNameGenerated(true) call. Satheesh TomohitoNakayama wrote: Hello. I tried to change handling single column name in order by clause , and just finished coding. Now single column name is treated as additiveExpression in afterPatch. And I have found next difference in orderby.out between beforePatch and afterPatch as follows. I 'm confusing whether I should judge this is bug or not. beforePatch ij> -- . order by doesn't see generated names values (1,0,1),(1,0,0),(0,0,1),(0,1,0); 1 |2 |3 --- 1 |0 |1 1 |0 |0 0 |0 |1 0 |1 |0 ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"; ERROR 42X78: Column 'SQLCol1' is not in the result of the query _expression_. ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2"; ERROR 42X78: Column 'SQLCol2' is not in the result of the query _expression_. ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3; 1 |2 |3 --- 0 |0 |1 0 |1 |0 1 |0 |0 1 |0 |1 afterPatch ij> -- . order by doesn't see generated names ? values (1,0,1),(1,0,0),(0,0,1),(0,1,0); 1 |2 |3 --- 1 |0 |1 1 |0 |0 0 |0 |1 0 |1 |0 -- now next was accepted. ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol1"; 1 |2 |3 --- 0 |1 |0 0 |0 |1 1 |0 |0 1 |0 |1 -- now next was accepted too. ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by "SQLCol2"; 1 |2 |3 --- 0 |0 |1 1 |0 |0 1 |0 |1 0 |1 |0 ij> values (1,0,1),(1,0,0),(0,0,1),(0,1,0) order by 1,1,2,3; 1 |2 |3 --- 0 |0 |1 0 |1 |0 1 |0 |0 1 |0 |1 I have some question now. Q1: What is "generated names" ? <"> "SQLCol NUMBER" <"> seems to be called "generated names". Q2: Why was it error to use "generated name" in order by caluse as seen in beforePatch? Q3: Is it bug to accept "generated names" in order clause like as in afterPatcch ? Please give me some adivise... Best regards. /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
Re: About improvement of DERBY-134
Derby actually generates two different names... 1) Unique name for unnamed references 2) Final exposed names for top level unnamed result columns. The unique names are of the form 'SQLCol' and final exposed names, that IJ shows, are of the form ''. The number part of the names could be different. (Eg: 'SQLCol5' may map to '1' as exposed name) The SQLCol unique names can't be guessed correctly by end users. It may change depending on how the query is compiled and can change totally unexpectedly.(Like adding an extra union at the end of the query could change top level result column names) So these are definitely not suitable to be used by end users. It may be possible to use final exposed names (like '1', '2') in order by clause, but Derby currently doesn't allow it. It is not consistant to allow this only under some new code path, as a side effect. We have to consistantly change it all over. I don't know what the SQL standard says about this... I don't want to look at that huge spec on a Sunday. :-) I am not sure we should, even if we could... Like you said, these numbers are implementation dependent, change from one vendor to another and may even change from one release to another. Shouldn't querries instead use explicit aliasing to avoid all confusion, which is standards based and portable? Satheesh Jeremy Boynes wrote > I'm not so sure - I thought expressions were given implementation > dependent names that could be referenced in a sort key. In our case > the name is "SQLCol1" so referencing that would be valid but > non-portable. > > I'm curious why ij is not labeling the columns that way and whether it > should. > > -- > Jeremy
Re: About improvement of DERBY-134
Not sure what you mean by the case where you are using VALUES to construct a table, Derby does allow naming those columns. ij> values (1,1,1), (2,2,2); 1 |2 |3 --- 1 |1 |1 2 |2 |2 ij> select * from (values (1,1,1), (2,2,2)) as t(i,j,k) order by i desc; I |J |K --- 2 |2 |2 1 |1 |1 Aren't these symantically the same? Satheesh Jeremy Boynes wrote: Yes they should. Unfortunately that is not always possible and I think the case where you are using VALUES to construct a table is one of those. In other words, Tomohito's test is reliant on implementation dependent behaviour. The spec does say that alias names are generated and so it should be possible to reference them even if doing so is non-portable. Personally I would prefer the form because it is at least a legal identifier; using <1> would mean having to quote the reference which seems inconvenient and confusing e.g. ORDER BY "1" Whatever the outcome I do think we need to document how the names are generated so a user can figure it out. -- Jeremy
Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs
Oops... sorry. I didn't realize you were addressing those as a different patch... I will get to it in a day or two. Army tried to apply the patch, but it failed... Not sure why.. Should we try to merge your changes with latest and generate a new patch? You have to merge in anycase...right? Satheesh Mamta Satoor wrote: >Hi Satheesh, > >I wondered if you got a chance to submit the patch I submitted couple >weeks back. As per Dan's earlier post, the couple issues that are left >on this feature can be sent as a separate patch. So, I will appreciate >if you can submit the current patch for me. > >thanks, >Mamta >
Re: About improvement of DERBY-134
(B (B (B (BSince you are working on an enhancement to Derby, you need to sign a (BCLA with Apache. (B (BJean, is this the right CLA? (Bhttp://www.apache.org/~tetsuya/db/agreement.html (B (BSatheesh (B (BTomohitoNakayama wrote: (BHello. (B (B (BI have finished coding and testing in orderby.sql. (B (BI'm not sure test is enough. (B (B (BWould you please review it ? (B (B (BBest regards. (B (B (B/* (B (B (B Tomohito Nakayama (B (B [EMAIL PROTECTED] (B (B [EMAIL PROTECTED] (B (B (B Naka (B (B http://www5.ocn.ne.jp/~tomohito/TopPage.html (B (B (B*/ (B (B- Original Message - From: "Satheesh Bandaram" (B<[EMAIL PROTECTED]> (B (BTo: "Derby Development" (B (BSent: Saturday, March 12, 2005 6:59 AM (B (BSubject: Re: About improvement of DERBY-134 (B (B (B (B Hi Tomohito Nakayama, (B (B (BJust wanted to check how you are progressing on the patch update, (B (Bfollowing comments by myself and Jack. I do think you are working on an (B (Bimportant enhancement that not only yourself but other developpers have (B (Bexpressed interest in. I strongly encourage you to continue working on (B (Bthis and post any questions or comments you might have. You are pretty (B (Bclose to addressing all issues. (B (B (BI am willing to help, if you need any, to continue taking this further. (B (B (BSatheesh (B (B (BTomohitoNakayama wrote: (B (B (BHello. (B (BThanks for your reviewing. (B (B (BAbout 1: (B (BHandling any sortKey as _expression_ is better structure. (B (BA little challenging but worth for it. (B (BI will try. (B (B (BAbout 2: (B (BUh oh. (B (BBug about starting value of element indexing in ResultColumnList (B (BTest of comma separated lists of ORDER BY expressions in orderby.sql (B (Bwas needed. (B (B (BAbout 3: (B (BI see. (B (BIt seems that it is certainly needed to add test case . (B (B (BI will continue this issue. (B (BBest regards. (B (B (B/* (B (B (BTomohito Nakayama (B (B[EMAIL PROTECTED] (B (B[EMAIL PROTECTED] (B (B (BNaka (B (Bhttp://www5.ocn.ne.jp/~tomohito/TopPage.html (B (B (B*/ (B (B- Original Message - From: "Jack Klebanoff" (B (B<[EMAIL PROTECTED]> (B (BTo: "Derby Development" (B (BSent: Sunday, February 20, 2005 8:37 AM (B (BSubject: Re: About improvement of DERBY-134 (B (B (B (B TomohitoNakayama wrote: (B (B (BHello. (B (B (BI have put some LOOKAHEAD to sqlgrammer.jj and (B (Badd some test pattern to orderby.sql. (B (B (BWould someone review patch please ? (B (B (BBest regards. (B (B (B/* (B (B (BTomohito Nakayama (B (B[EMAIL PROTECTED] (B (B[EMAIL PROTECTED] (B (B (BNaka (B (Bhttp://www5.ocn.ne.jp/~tomohito/TopPage.html (B (B (B*/ (B (B- Original Message - From: "TomohitoNakayama" (B (B<[EMAIL PROTECTED]> (B (BTo: "Derby Development" (B (BSent: Sunday, February 13, 2005 4:09 PM (B (BSubject: Re: About improvement of DERBY-134 (B (B (B (B Sorry. (B (BMistaken. (B (B (BLOOKAHEAD() (B (B (B/* (B (B (BTomohito Nakayama (B (B[EMAIL PROTECTED] (B (B[EMAIL PROTECTED] (B (B (BNaka (B (Bhttp://www5.ocn.ne.jp/~tomohito/TopPage.html (B (B (B*/ (B (B- Original Message - From: "TomohitoNakayama" (B (B<[EMAIL PROTECTED]> (B (BTo: "Derby Development" (B (BSent: Sunday, February 13, 2005 3:42 PM (B (BSubject: Re: About improvement of DERBY-134 (B (B (B (BHello. (B (B (BThank's for your reviewing. (B (BGrammer ambiguity is very critical problem (B (B (BI will try to put LOOKUP() and consider about testing.. (B (B (B#World is not simple as I wish to be. (B (B (BBest regards. (B (B (B/* (B (B (BTom
Re: About improvement of DERBY-134
I am still new to Apache processes. According to the following DB project guidelines, "All contributors should have a Contributor License Agreement on file." I know bug patches are exempt from this requirement. http://db.apache.org/source.html Satheesh Jeremy Boynes wrote: Satheesh Bandaram wrote: Since you are working on an enhancement to Derby, you need to sign a CLA with Apache. A CLA is usually only required when someone becomes a committer. There is a flag in Jira which indicates whether code attached to issues is licensed to the ASF; patches submitted to the list are public contributions. -- Jeremy
Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs
+1. I think Dan has already voted on this. We need another +1 vote before I can commit. Mamta Satoor wrote: On Mon, 14 Mar 2005 13:03:46 -0800, Mamta Satoor <[EMAIL PROTECTED]> wrote: On Mon, 14 Mar 2005 12:35:02 -0800, Satheesh Bandaram <[EMAIL PROTECTED]> wrote: Oops... sorry. I didn't realize you were addressing those as a different patch... I will get to it in a day or two. Army tried to apply the patch, but it failed... Not sure why.. Should we try to merge your changes with latest and generate a new patch? You have to merge in anycase...right? Satheesh Mamta Satoor wrote: Hi Satheesh, I wondered if you got a chance to submit the patch I submitted couple weeks back. As per Dan's earlier post, the couple issues that are left on this feature can be sent as a separate patch. So, I will appreciate if you can submit the current patch for me. thanks, Mamta OK, I will work on merging and generating a new patch. Mamta
Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs
Submitted this patch. I think Mamta already voted +1, so we are good! Satheesh Sending java\engine\org\apache\derby\iapi\reference\SQLState.java Sending java\engine\org\apache\derby\iapi\types\SQLClob.java Sending java\engine\org\apache\derby\impl\jdbc\EmbedDatabaseMetaData.java Sending java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java Sending java\engine\org\apache\derby\impl\jdbc\EmbedResultSet20.java Sending java\engine\org\apache\derby\loc\messages_en.properties Adding java\testing\org\apache\derbyTesting\functionTests\master\jdk14 Adding java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out Sending java\testing\org\apache\derbyTesting\functionTests\master\parameterMapping.out Sending java\testing\org\apache\derbyTesting\functionTests\master\resultsetJdbc30.out Sending java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultsetJdbc30.java Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\build.xml Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java Transmitting file data . Committed revision 157592. Satheesh Bandaram wrote: +1. I think Dan has already voted on this. We need another +1 vote before I can commit. Mamta Satoor wrote: On Mon, 14 Mar 2005 13:03:46 -0800, Mamta Satoor <[EMAIL PROTECTED]> wrote: On Mon, 14 Mar 2005 12:35:02 -0800, Satheesh Bandaram <[EMAIL PROTECTED]> wrote: Oops... sorry. I didn't realize you were addressing those as a different patch... I will get to it in a day or two. Army tried to apply the patch, but it failed... Not sure why.. Should we try to merge your changes with latest and generate a new patch? You have to merge in anycase...right? Satheesh Mamta Satoor wrote: Hi Satheesh, I wondered if you got a chance to submit the patch I submitted couple weeks back. As per Dan's earlier post, the couple issues that are left on this feature can be sent as a separate patch. So, I will appreciate if you can submit the current patch for me. thanks, Mamta OK, I will work on merging and generating a new patch. Mamta
Re: LIMIT with Select Statement
Derby allows limiting the number of rows returned by a query using JDBC. You can use java.sql.Statement.setMaxRows() method. Satheesh Devang wrote: Hi Is it possible to use “LIMIT” keyword with select statement? Or is there any other alternative for the same? Thanx Devang
Re: [PATCH] Derby-174
I will submit your patches after your changes. Satheesh Shreyas Kaushik wrote: > I guess this is an IDE trick , I'll change this. > > ~ Shreyas > > Army wrote: > >> <[EMAIL PROTECTED]> wrote >> >>> >>> -import java.sql.Date; >>> -import java.sql.Time; >>> -import java.sql.Timestamp; >>> -import java.sql.Types; >>> -import java.sql.ResultSet; >>> -import java.sql.SQLException; >>> +import java.sql.*; >> >> >> >> I apologize if this is overly picky, but isn't inclusion of a package >> via the "*" wildcard generally considered an unfavorable programming >> practice? I think it's fine to do so when writing tests, but as far >> as I know, the Derby codeline generally avoids using wildcard >> imports. And even if there are existing places where such imports >> are used, it seems to me that _replacing_ existing imports with the >> wildcard import is probably not a habit to encourage. >> >> Even if functionally speaking there's no difference, to do this is to >> introduce a style of imports that's doesn't agree with the rest of >> the codeline--is that something to avoid? >> >> 'Course, maybe that's just unfounded paranoia on my part... >> >> *shrug* >> Army >> > > >
Re: [PATCH]Enabling negative test for scroll sensitive updatable resultset in Network Server mode
Submitted this patch. Satheesh Sending java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updatableResultSet.out Sending java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\updatableResultSet.out Sending java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out Sending java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java Transmitting file data . Committed revision 158821. Mamta Satoor wrote: Hi, Derby does not support scroll sensitive updatable resultsets. There is already a test for this in embedded mode. Enabling the same test for Network Server. The new Derby Net Client driver will correctly downgrade the resultset type to scroll insensitive read only resultset. JCC driver does not do that and there is already a JIRA entry 154 for it. svn stat M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableRe sultSet.java M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\updata bleResultSet.out M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\ updatableResultSet.out M java\testing\org\apache\derbyTesting\functionTests\master\updatableResult Set.out M java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatable ResultSet.out thanks, Mamta Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java (revision 158774) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/updatableResultSet.java (working copy) @@ -247,7 +247,6 @@ //have to close the resultset because by default, resultsets are held open over commit rs.close(); - if (TestUtil.isEmbeddedFramework()) { System.out.println("Negative Test2 - request for scroll sensitive updatable resultset will give a read only scroll insensitive resultset"); stmt = conn.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE); while (warnings != null) @@ -257,6 +256,7 @@ } conn.clearWarnings(); System.out.println("requested TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE but that is not supported"); + System.out.println("Jira issue Derby-154 : When client connects to Network Server using JCC, it incorrectly shows support for scroll sensitive updatable resultsets"); System.out.println("Make sure that we got TYPE_SCROLL_INSENSITIVE? " + (stmt.getResultSetType() == ResultSet.TYPE_SCROLL_INSENSITIVE)); System.out.println("Make sure that we got CONCUR_READ_ONLY? " + (stmt.getResultSetConcurrency() == ResultSet.CONCUR_READ_ONLY)); System.out.println("JDBC 2.0 updatable resultset api will fail on this resultset because this is not an updatable resultset"); @@ -281,7 +281,6 @@ rs.next(); //have to close the resultset because by default, resultsets are held open over commit rs.close(); - } System.out.println("Negative Test3 - request a read only resultset and attempt deleteRow and updateRow on it"); stmt = conn.createStatement();//the default is a read only forward only resultset Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out === --- java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out (revision 158774) +++ java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/updatableResultSet.out (working copy) @@ -12,6 +12,16 @@ Got expected exception This method cannot be invoked while the cursor is on the insert row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY. SQL State : null Got expected exception This method cannot be invoked while the cursor is on the insert row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY. +Negative Test2 - request for scroll sensitive updatable resultset will give a read only scroll insensitive resultset +requested TYPE_SCROLL_SENSITIVE, CONCUR_UPDATABLE but that is not supported +Jira issue Derby-154 : When client connects to Network Server using JCC, it incorrectly shows support for scroll sensitive updatable resultsets +Make sure that we got TYPE_SCROLL_INSENSITIVE? false +Make sure that we got CONCUR_READ_ONLY? false +JDBC 2.0 updatable resultset api will fail on this resultset because this is not an updatable resultset +SQL State : null +Got expected exception This method cannot be invoked while the cursor is on the insert row or if the concurrency of this ResultSet object is CONCUR_READ_ONLY. +SQL State : null +Got expected exception This method cannot be invoked while the cursor is on the insert row or if the concurre
Re: [jira] Commented: (DERBY-147) ERROR 42X79 not consistant ? - same column name specified twice
I think we should to enumerate all cases that cause ambiguity. Some are possibly OK(multiple references to same column), some should raise error(cases where there is an explicit alias). There is a need to also check what SQL standard says here. Here are some of the queries and what DB2 does with those, though we should follow SQL guidance for Derby. db2> select i, i from t order by i I I --- --- 0 0 1 1 2 2 db2> select i, j as i from t order by i I I --- --- 0 4 1 1 2 2 db2> select i as A, j as A from t order by A <== Explicit alias. Error. Error. Satheesh Jack Klebanoff wrote: It is not so simple. The order by specification may be ambiguous. Derby allows the following: select t.c1 as a, t.c2 as a from t What should we do if you add "order by a" to the above select? "a" is truly ambiguous. I can think of several alternatives: 1. Prohibit duplicate select list column names, whether or not there is an order by clause. 2. Change ORDER BY processing. When it finds an ambiguous column name check whether all the columns with that name are really the same. Allow the ORDER BY if so. Remember that Tomohito Nakayama is working on allowing general expressions in the ORDER BY clause, so this is not so easy. 3. Change ORDER BY processing. When it finds an ambiguous column name check whether the sort key names a column in an underlying table (not a correlation name). Allow the ORDER BY if so. Throw an SQLException if not, even if all the possible columns have the same value. This fixes the case in the bug report. 4. Keep the error checking as is but improve the error message. Something like "ORDER BY column 'xx' is ambiguous". 5. Do nothing. Jack Klebanoff Diljeet Dhillon (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-147?page=comments#action_61483 ] Diljeet Dhillon commented on DERBY-147: --- Hi, Have we established whether a possible patch/fix will be provided for this issue. and what the possible timescales may be? ERROR 42X79 not consistant ? - same column name specified twice --- Key: DERBY-147 URL: http://issues.apache.org/jira/browse/DERBY-147 Project: Derby Type: Bug Reporter: Bernd Ruehlicke This happens from JDBC or ij. Here the output form ij> ij version 10.0 CONNECTION0* - jdbc:derby:phsDB * = current connection ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1 ORDER BY a1.XXX_foreign; ERROR 42X79: Column name 'XXX_FOREIGN' appears more than once in the result of the query _expression_. But when removing the ORDER BY and keeping the 2 same column names it works ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1; XXX_FOREIGN |NATIVE |KIND |XXX_FOREIGN --- 0 rows selected ij> So - it seams to be OK to specify the same column twice - as long as you do not add the ORDER BY clause. I woul dof course like that the system allows this - but at leats it should be consistant and either allow both or none of the two queries above.
Re: Adding framework scripts to bundle
I also think they are useful. Some of these scripts are present in the derby source download, though they could be improved. It would be nice to be able to start Derby Network server as a service in Windows, for example. Any volunteers? :-) Satheesh Amit Handa wrote: > Hi, > > Can we add framework scripts like startNetworkto bundle available for > download ? > > The bundles only packages the derby jars, adding these scripts can be > a useful thing for developers. > > Is there a plan to do so ? > > thanks, > Amit > > >
Re: [Fwd: [PATCH] Derby-157 Patch, plus 2 other minor server fixes.]
Thanks for the reminder. I have submitted this patch. I am wondering if previously failing test cases should be added to Network server tests. Satheesh Sending java\drda\org\apache\derby\impl\drda\DRDAConnThread.java Transmitting file data . Committed revision 158935. Army wrote: Committers, I submitted this rather simple patch three weeks ago, but it looks like it fell through the cracks. I'm re-attaching a newly created version of the patch (against the most recent codeline). This is a fix for DERBY-157. I ran the derbynetmats suite with these changes and there were no failures. As all changes in this patch are specific to the Network Server, I don't think any other tests need to be run. Could someone please commit? Thanks, Army Original Message Subject: [PATCH] Derby-157 Patch, plus 2 other minor server fixes. Date: Thu, 03 Mar 2005 16:05:09 -0800 From: Army <[EMAIL PROTECTED]> Reply-To: Derby Development To: Derby Development Attached is a patch that does the following three (pretty minor) things: 1) First and foremost, it resolves DERBY-157. If a datetime string that is not recognized by the server is received from the client, the server will now catch the resultant Java exception and throw a valid SQLException with SQLSTATE 22007 ("The syntax of the string representation of a datetime value is incorrect"). The old behavior was to throw a DRDA protocol exception and deallocate the connection. 2) It corrects a small problem in the way the server treats timestamp strings. This problem, like DERBY-157, only happens with non-JCC clients: users who insert a timestamp value into a Derby table by binding a _string_ value (ex. "1948-04-08 02:24:48") to a _timestamp_ parameter will actually get a different value back when they do a SELECT because the value is 'warped' by the server before insertion. In particular, extra 0's are added to the end of the string--ex. "1948-04-08 02:24:48000"--which are then treated as seconds when the server calls java.sql.Timestamp.valueOf(), and thus the wrong value is inserted. This doesn't happen with JDBC drivers because the code in question is only executed when a _string_ value is being bound to a _Timestamp_ parameter--basically, the user would have to do something like ps.setTimestamp(1, "1948-04-08 02:24:48") --but JDBC doesn't allow that, because the second argument has to be a Timestamp object. With an ODBC client, though, this kind of thing is possible, and so this problem should be fixed. 3) It removes an extraneous call to "finalizeChain()" that was introduced as part of the "Multiple EXCSAT fix" patch (see http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200501.mbox/[EMAIL PROTECTED]). This extra call doesn't lead to any bad behavior, but since it is unnecessary and technically incorrect, it's good to remove it. It's a simple one-line removal, so if no one minds, I figure it can be made with this patch, since all of the changes in this patch are to the same file and they are all pretty minor. In terms of tests, I haven't modified or added any test cases because these are problems that can only be seen with a non-Java driver--and as far as I know, the current Derby test harness has no means of introducing such a driver. I have run the derbynetmats suite (on Windows using jdk142) with these very minor changes and all tests passed. Committers, please commit when you can... Thanks, Army Index: java/drda/org/apache/derby/impl/drda/DRDAConnThread.java === --- java/drda/org/apache/derby/impl/drda/DRDAConnThread.java (revision 158925) +++ java/drda/org/apache/derby/impl/drda/DRDAConnThread.java (working copy) @@ -806,7 +806,6 @@ case CodePoint.EXCSAT: parseEXCSAT(); writeEXCSATRD(); - finalizeChain(); break; case CodePoint.ACCSEC: int securityCheckCode = parseACCSEC(); @@ -4039,7 +4038,17 @@ String paramVal = reader.readStringData(10).trim(); //parameter may be char value if (SanityManager.DEBUG) trace("ndate parameter value is: \""+paramVal+"\""); -ps.setDate(i+1, java.sql.Date.valueOf(paramVal)); +try { + ps.setDate(i+1, java.sql.Date.valueOf(paramVal)); +} catch (java.lang.IllegalArgumentException e) { + // Just use SQLSTATE as message since, if user wants to + // retrieve it, the message will be looked up by the + // sqlcamessage() proc, which will get the localized + // message based on SQLSTATE, and will ignore the + // the message we use here... + throw new SQLException(SQLState.LANG_DATE_SYNTAX_EXCEPTION, + SQLState.LANG_DATE_SYNTAX_EXCEPTION.substring(0,5)); +} break; } case FdocaConstants.DRDA_TYPE_NTIME: @@ -4047,20 +4056,37 @@ String paramVal = re
Re: [VOTE] Reject tally of logo votes
+1. Reject the tally. Satheesh Kathey Marsden wrote: Vote +1 Reject the tally. New method of choosing a logo is determined by the community. -1 Not to reject the tally. Keep the vote tally as is with 32 as the winner. Oops forgot to vote +1 Reject the tally. New method of choosing a logo is determined by the community.
Re: [jira] Commented: (DERBY-127) Aliased Columns not recognized after "group by... order by" combination
I am just describing the current behavior. Definitely not saying it can't be changed. If the statement is SQL standard based, then anyone can address the issue and submit a patch. Satheesh Fawzi Karachi wrote: That's strange. The statement is SQL-92 compliant and supported by all the databases I have tried including MS SQL, Oracle, DB2 and Mckoi. Is derby not SQL-92 compliant? Are you planning not to fix it in the next release of derby? Please let me know as I have a system currenlty running against McKoi and was planning to migrate it to Derby. But if this bug won't be fixed, we will probably stay with McKoi or try Oracle Lite. Thank you. Fawzi. On Thu, 24 Mar 2005 21:10:21 +0100 (CET), Satheesh Bandaram (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-127?page=comments#action_61513 ] Satheesh Bandaram commented on DERBY-127: - Derby, in general, doesn't allow order by sort keys to be exposed names, if they also have a correlation name. (alias name) When a correlation name is specified, ORDER BY, specially requires using the correlation name or a simple-integer number. (like order by 1) Going by this, the third query that works also should not. (Query without group by) Aliased Columns not recognized after "group by... order by" combination --- Key: DERBY-127 URL: http://issues.apache.org/jira/browse/DERBY-127 Project: Derby Type: Bug Components: SQL Versions: 10.0.2.1 Environment: Windows XP Professional JDK 1.4 (first found in relation to Mondrian 1.0.1) Reporter: Thomas Browne I've been doing work to try and integrate Derby with the Mondrian ROLAP engine, which has uncovered a bug in Derby when a query involves column aliasing, a group by clause, and an order by clause. For example: Mondrian will generate the following query: select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME which should be valid SQL. I have tested this query outside of the Mondrian environment and still receive the same error which is: "Column 'STORE.STORE_COUNTRY' is not in any table in the FROM list or it appears within a join specification and is outside the scope of the join specification or it appears in a HAVING clause and is not in the GROUP BY list. SQL State: 42x04 Error Code: 3 However, if I remove any one of the three elements (aliasing, group by, order by) or if the order by uses the aliased names, the query works. It is only the combination of all 3 elements that is causing a problem. [ie. all of the following queries work correctly] select STORE.STORE_COUNTRY , STORE.STORE_STATE , STORE.STORE_CITY , STORE.STORE_NAME , STORE.STORE_TYPE , STORE.STORE_MANAGER , STORE.STORE_SQFT , STORE.GROCERY_SQFT , STORE.FROZEN_SQFT , STORE.MEAT_SQFT , STORE.COFFEE_BAR , STORE.STORE_STREET_ADDRESS from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE group by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME, STORE.STORE_TYPE, STORE.STORE_MANAGER, STORE.STORE_SQFT, STORE.GROCERY_SQFT, STORE.FROZEN_SQFT, STORE.MEAT_SQFT, STORE.COFFEE_BAR, STORE.STORE_STREET_ADDRESS select STORE.STORE_COUNTRY as c0, STORE.STORE_STATE as c1, STORE.STORE_CITY as c2, STORE.STORE_NAME as c3, STORE.STORE_TYPE as c4, STORE.STORE_MANAGER as c5, STORE.STORE_SQFT as c6, STORE.GROCERY_SQFT as c7, STORE.FROZEN_SQFT as c8, STORE.MEAT_SQFT as c9, STORE.COFFEE_BAR as c10, STORE.STORE_STREET_ADDRESS as c11 from STORE as STORE order by STORE.STORE_COUNTRY, STORE.STORE_STATE, STORE.STORE_CITY, STORE.STORE_NAME select STORE.STORE_COUNTRY as c
Re: [jira] Commented: (DERBY-147) ERROR 42X79 not consistant ? - same column name specified twice
I will work to get this into 10.1 release. Patch may have to be changed to address some issues raised by Jack. Satheesh Bernd Ruehlicke (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-147?page=comments#action_61646 ] Bernd Ruehlicke commented on DERBY-147: --- So - how do I make sure this stuff makes it into the 10.1 release ? ERROR 42X79 not consistant ? - same column name specified twice --- Key: DERBY-147 URL: http://issues.apache.org/jira/browse/DERBY-147 Project: Derby Type: Bug Reporter: Bernd Ruehlicke Attachments: derby-147-10.0.2.1.diff, derby-147.diff This happens from JDBC or ij. Here the output form ij> ij version 10.0 CONNECTION0* - jdbc:derby:phsDB * = current connection ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1 ORDER BY a1.XXX_foreign; ERROR 42X79: Column name 'XXX_FOREIGN' appears more than once in the result of the query _expression_. But when removing the ORDER BY and keeping the 2 same column names it works ij> select a1.XXX_foreign, a1.native, a1.kind, a1.XXX_foreign FROM slg_name_lookup a1; XXX_FOREIGN |NATIVE |KIND|XXX_FOREIGN --- 0 rows selected ij> So - it seams to be OK to specify the same column twice - as long as you do not add the ORDER BY clause. I woul dof course like that the system allows this - but at leats it should be consistant and either allow both or none of the two queries above.
Re: [Patch] Re: About improvement of DERBY-134
I will work on committing this patch. Since you are working on an improvement, would you mind submitting this patch through Jira? Use AttachFile option and you also need to select "Grant ASF license to include in ASF works" option. (URL: http://issues.apache.org/jira/secure/AttachFile!default.jspa?id=29790) This would help committers in accepting the patch. Also, you might want to consider signing ICLA with Apache. (http://www.apache.org/licenses/icla.txt) This will help process your contributions faster. This is also a requirement to becoming a committer at a future time. Satheesh TomohitoNakayama wrote: > Waiting 1 day and no error was found. > Can I ask committers to commit this patch ? > > Or I should commit it by myself ? > > Best regards. > > /* > > Tomohito Nakayama > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > Naka > http://www5.ocn.ne.jp/~tomohito/TopPage.html > > */ > - Original Message - From: "Jack Klebanoff" > <[EMAIL PROTECTED]> > To: "Derby Development" > Sent: Tuesday, March 29, 2005 4:31 AM > Subject: Re: [Patch] Re: About improvement of DERBY-134 > > >> TomohitoNakayama wrote: >> >>> Hello. >>> >>> I have added some test to orderby.sql (and correspond result to >>> orderby.out) , >>> which was suggested by Jack Klebanoff. >>> >>> And I have executed derbylang test and coulud not found error exept >>> for lang/floattypes.sql. >>> I think this error is not caused by my patch. >>> >>> derbylang_report.txt is attached to this mail. >>> >>> Please check this patch from a point of other person's view. >>> >>> best regards. >>> >>> /* >>> >>> Tomohito Nakayama >>> [EMAIL PROTECTED] >>> [EMAIL PROTECTED] >>> >>> Naka >>> http://www5.ocn.ne.jp/~tomohito/TopPage.html >>> >>> */ >> >> >> The latest patch looks good to me. I looked at the changes, applied >> the patch to recently updated Derby source, and successfully ran the >> derbylang test suite. (I did not even see the failure in >> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby >> updates I picked up today). >> >> Jack Klebanoff >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Anti-Virus. >> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27 >> >> > >
Re: [PATCH] Derby-174
I have submitted this patch. Thanks for adding new test case to test both. But the new test is not part of any test suite, so it may not get run even though it is there. Can you add the test case into 'jdbcapi' or 'derbylang' test suites? Sendingjava\engine\org\apache\derby\iapi\types\SQLBlob.java Sendingjava\engine\org\apache\derby\iapi\types\SQLTimestamp.java Adding java\testing\org\apache\derbyTesting\functionTests\master\prepStmtNull.out Adding java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\prepStmtNull.java Transmitting file data Committed revision 159445. Shreyas Kaushik wrote: > Sateesh, > > Did you have a chance to look into this? > > ~ Shreyas > > Shreyas Kaushik wrote: > >> Attached is the latest patch with the changes. >> >> thanks >> Shreyas >> >> Satheesh Bandaram wrote: >> >>> I will submit your patches after your changes. >>> >>> Satheesh >>> >>> Shreyas Kaushik wrote: >>> >>> >>> >>>> I guess this is an IDE trick , I'll change this. >>>> >>>> ~ Shreyas >>>> >>>> Army wrote: >>>> >>>> >>>> >>>>> <[EMAIL PROTECTED]> wrote >>>>> >>>>> >>>>> >>>>>> -import java.sql.Date; >>>>>> -import java.sql.Time; >>>>>> -import java.sql.Timestamp; >>>>>> -import java.sql.Types; >>>>>> -import java.sql.ResultSet; >>>>>> -import java.sql.SQLException; >>>>>> +import java.sql.*; >>>>>> >>>>> >>>>> >>>>> >>>>> I apologize if this is overly picky, but isn't inclusion of a package >>>>> via the "*" wildcard generally considered an unfavorable programming >>>>> practice? I think it's fine to do so when writing tests, but as far >>>>> as I know, the Derby codeline generally avoids using wildcard >>>>> imports. And even if there are existing places where such imports >>>>> are used, it seems to me that _replacing_ existing imports with the >>>>> wildcard import is probably not a habit to encourage. >>>>> >>>>> Even if functionally speaking there's no difference, to do this is to >>>>> introduce a style of imports that's doesn't agree with the rest of >>>>> the codeline--is that something to avoid? >>>>> >>>>> 'Course, maybe that's just unfounded paranoia on my part... >>>>> >>>>> *shrug* >>>>> Army >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> >> Index: java/engine/org/apache/derby/iapi/types/SQLTimestamp.java >> === >> --- java/engine/org/apache/derby/iapi/types/SQLTimestamp.java >> (revision 158017) >> +++ java/engine/org/apache/derby/iapi/types/SQLTimestamp.java >> (working copy) >> @@ -45,12 +45,15 @@ >> import org.apache.derby.iapi.types.SQLDouble; >> import org.apache.derby.iapi.types.SQLTime; >> >> + >> + >> import java.sql.Date; >> import java.sql.Time; >> import java.sql.Timestamp; >> import java.sql.Types; >> import java.sql.ResultSet; >> import java.sql.SQLException; >> +import java.sql.PreparedStatement; >> >> import java.util.Calendar; >> import java.util.GregorianCalendar; >> @@ -65,7 +68,7 @@ >> /** >> * This contains an instance of a SQL Timestamp object. >> * >> - * SQLTimestamp is stored in 3 ints - an encoded date, an encoded >> time and + * SQLTimestamp is stored in 3 ints - an encoded date, an >> encoded time and >> *nanoseconds >> * encodedDate = 0 indicates a null WSCTimestamp >> * >> @@ -989,5 +992,12 @@ >> currentCal.setTime(value); >> return SQLTime.computeEncodedTime(currentCal); >> } >> + >> ++public void setInto(PreparedStatement ps, int position) >> throws SQLException, StandardException { >> + >> + ps.setTimestamp(position, getTimestamp((Calendar) >> null)); >> + } >> } >> >> + >> >> > > >
Re: [PATCH] Derby-174
Submitted this patch. Satheesh Sending java\testing\org\apache\derbyTesting\functionTests\suites\jdbcapi.runall Transmitting file data . Committed revision 159474. Shreyas Kaushik wrote: Thanks Satheesh. Please find the patch attached, after adding this test to the jdbcapi.runall file. ~ Shreyas Satheesh Bandaram wrote: I have submitted this patch. Thanks for adding new test case to test both. But the new test is not part of any test suite, so it may not get run even though it is there. Can you add the test case into 'jdbcapi' or 'derbylang' test suites? Sending java\engine\org\apache\derby\iapi\types\SQLBlob.java Sending java\engine\org\apache\derby\iapi\types\SQLTimestamp.java Adding java\testing\org\apache\derbyTesting\functionTests\master\prepStmtNull.out Adding java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\prepStmtNull.java Transmitting file data Committed revision 159445. Shreyas Kaushik wrote: Sateesh, Did you have a chance to look into this? ~ Shreyas Shreyas Kaushik wrote: Attached is the latest patch with the changes. thanks Shreyas Satheesh Bandaram wrote: I will submit your patches after your changes. Satheesh Shreyas Kaushik wrote: I guess this is an IDE trick , I'll change this. ~ Shreyas Army wrote: <[EMAIL PROTECTED]> wrote -import java.sql.Date; -import java.sql.Time; -import java.sql.Timestamp; -import java.sql.Types; -import java.sql.ResultSet; -import java.sql.SQLException; +import java.sql.*; I apologize if this is overly picky, but isn't inclusion of a package via the "*" wildcard generally considered an unfavorable programming practice? I think it's fine to do so when writing tests, but as far as I know, the Derby codeline generally avoids using wildcard imports. And even if there are existing places where such imports are used, it seems to me that _replacing_ existing imports with the wildcard import is probably not a habit to encourage. Even if functionally speaking there's no difference, to do this is to introduce a style of imports that's doesn't agree with the rest of the codeline--is that something to avoid? 'Course, maybe that's just unfounded paranoia on my part... *shrug* Army Index: java/engine/org/apache/derby/iapi/types/SQLTimestamp.java === --- java/engine/org/apache/derby/iapi/types/SQLTimestamp.java (revision 158017) +++ java/engine/org/apache/derby/iapi/types/SQLTimestamp.java (working copy) @@ -45,12 +45,15 @@ import org.apache.derby.iapi.types.SQLDouble; import org.apache.derby.iapi.types.SQLTime; + + import java.sql.Date; import java.sql.Time; import java.sql.Timestamp; import java.sql.Types; import java.sql.ResultSet; import java.sql.SQLException; +import java.sql.PreparedStatement; import java.util.Calendar; import java.util.GregorianCalendar; @@ -65,7 +68,7 @@ /** * This contains an instance of a SQL Timestamp object. * - * SQLTimestamp is stored in 3 ints - an encoded date, an encoded time and + * SQLTimestamp is stored in 3 ints - an encoded date, an encoded time and * nanoseconds * encodedDate = 0 indicates a null WSCTimestamp * @@ -989,5 +992,12 @@ currentCal.setTime(value); return SQLTime.computeEncodedTime(currentCal); } + + + public void setInto(PreparedStatement ps, int position) throws SQLException, StandardException { +
Re: [jira] Commented: (DERBY-190) Derby build should be incremental
Is 5-10 minutes for a full build too long? On my laptop, (with only 512 MB memory) full build takes about 6 minutes. Running tests is another matter... Takes hours to run full test suite, though Derby has sub-suites that run only parts of the suites. Satheesh David Van Couvering (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-190?page=comments#action_61851 ] David Van Couvering commented on DERBY-190: --- Forgot to add this. Section 4.1 of BUILDING.txt says clobber: remove all built objects except jars. You should run this target if you have source code upgrade or you changed the source code and you are getting some errors. Every time I do a svn update it's a source code upgrade and I should do a clobber. One concern I have is that because of this many developers will not want to deal with a source code upgrade and their local svn tree will get stale. Derby build should be incremental - Key: DERBY-190 URL: http://issues.apache.org/jira/browse/DERBY-190 Project: Derby Type: Improvement Components: Build tools Versions: 10.0.2.2 Reporter: David Van Couvering You should not have to clobber and rebuild from scratch each time you update or modify your source. This is time-consuming and affects overall productivity.
Re: more background threads
Very interesting plans. What kind of application are you thinking of running on these 4-way or 8 way machines? Will you be using embedded driver or client-server network driver? I am also wondering how is the scalability of Java VMs these days? I know earlier VMs (a few years back) weren't scaling well beyond 3 or 4 CPUs. Is that any better with Sun or IBM VMs? Satheesh David Van Couvering wrote: > Hi, Mike, thanks for the response and very helpful overview. At first > blush it seems like the single daemon could easily be converted to a > thread pool approach where work is posted to a "dispatcher" who grabs > a thread and dispatches the work to it. I say this without having yet > looked at the code, but in the meantime any reasons why this obviously > won't work would be much appreciated. > > I can work on building up a test case that fills up the background > thread so we can "prove" that whatever solution we come up with helps > the system scale better. I can post a test plan prior to actually > creating the test to see if you all agree the test looks to be what we > want it to be. > > I can also look into testing Derby scalability on a 4-way or 8-way > machine, I think some of these are available in our lab. I would also > like to do some testing on some of Sun's new multi-core chips, where > you have 8 threads per core and 4-8 cores per CPU. Derby seems to be > well-suited to this architecture but it would be good to see if there > are any gotchas. Again, I would proposed these as plans first and get > your feedback. > > What protocol do I use to sort of "identify" this is a sub-project and > track its progress? Do I create a JIRA item labelled as an > "improvement" and assign it to myself? > > Thanks, > > David > > Mike Matrigali wrote: > >> I have changed the subject, as I completely missed the original post >> which had something to do with adding Junit tests. >> >> I am not sure what is the right solution here, but getting a discussion >> going would be good. >> >> Currently a number of store actions are queued in "post commit" mode, >> which means they should be executed until after the transaction which >> queued them commits. Currently there is one background thread which >> processes these, if it gets too full then the work is done by the actual >> thread which queued the work. Most of the post commit work involves >> claiming space from deleted rows after their transaction commits. >> >> Going forward there is going to be a need for more background work. I >> soon will be posting the first phase of work to allow for returning >> space back to the operating system, eventually it would be best if this >> work was also done in background, somehow automatically queued by the >> system. >> >> I would also recommend coming up with a usage scenario which shows a >> problem before coding up a solution. I believe a test with lots of >> users doing insert and delete should eventually show the background task >> being bogged down -- but I am not sure if moving work to additional >> threads is much better than just spreading the work out across the >> existing user threads. >> >> The code for the current background thread can be found in: >> opensource/java/engine/org/apache/derby/impl/services/daemon >> >> An example of one of the unit of work put on the queue is in: >> opensource/java/engine/org/apache/derby/impl/store/access/heap/heappostcommit.java >> >> >> Dan is probably the person who most recently worked on this code, and >> should have some comments in this area. He should be back active on the >> list early next week. >> >> Note another interesting area of research/coding would be to see how >> derby scales on larger number of processor machines. Not much work has >> been done at all on machines with more than 2 processors. The system >> has been designed from bottom up to be multi-threaded, but not much >> testing/monitoring has been done on 4 or more processor machines. The >> following single threading points exist in derby: >>o each user query is executed by a single thread. >>o the locking system in protected by a single java synchonization >> point. >>o copying log records into the log is a single sync point >>o finding a buffer in the buffer cache is a single sync point >> >> All of these seemed to be reasonable designs for 1, 2 and 4 way >> machines. >> >> /mikem >> >> >> David Van Couvering wrote: >> >> >> >>> I noticed on the todo list there is a need to have more than one >>> background thread to enable better scalability with lots of client >>> connections. I'm trying to find a way to gently work my way into doing >>> some work on Derby, and this seemed like a project of small enough >>> scope >>> to get my feet wet. Is there any background on this, or should I just >>> jump right in? I didn't see any discussion of this on the list... >>> >>> Thanks, >>> >>> David >>> >>> >> > > >
Re: [jira] Commented: (DERBY-186) isFirst() returns true when relative(x) goes beyond result set
I will do it today... Got side tracked for few days.. Satheesh Shreyas Kaushik wrote: > Did anyone get a chance to look at this and commit it? > > ~ Shreyas > > Shreyas Kaushik wrote: > >> Attached the latest patch. This addition to this patch from the old >> one is that I have added the test >> in the jdbcapi.runall file for it to run in both Embedded and Network >> Server mode. >> >> ~ Shreyas >> >> Shreyas Kaushik wrote: >> >>> Hi Mamta, >>> >>> Thanks for all the info. This definitely gave more insight into this >>> test framework. >>> I recently submitted a patch for Derby-174 and Derby-175 for which I >>> have just submitted a >>> patch for for jdbcapi.runall file. After that gets in I will >>> definitely add this one as well >>> and submit all of it in a fresh patch. I am waiting for that to go >>> in as there could be conflicts >>> in the jdbcapi.runall file. >>> >>> ~ Shreyas >>> >>> Mamta Satoor wrote: >>> On Tue, 29 Mar 2005 22:45:24 +0530, Shreyas Kaushik <[EMAIL PROTECTED]> wrote: > Hi Mamta, > > Thanks for all the info. > From this I see that adding it in jdbcapi will run in both > embedded and > netwrok server mode. > Should I add some properties file specifically for my test? > I'm sorry I ask this again, I'm not clear what changes I have to > do to > my patch ? > > ~ Shreyas > > Hi Shreyas, You will see that each of the directories under functionTests/tests have their own default properties file. If a newly added test does not have a test specific properties file, then the default properties file gets picked up. For eg, test declareGlobalTempTableJavaJDBC30.java has its own properties file because we do not want the test to be run with some jdks and we speify that declareGlobalTempTableJavaJDBC30_app.properties. Since the test you are adding has no special requirements, you donot need a properties file for it and harness will automatically use the default properties file for your test. Feel free to ask more questions if you have any. Since I have been working on this test harness for so long, I might not be visualizing some questions that a new developer might have. thanks, Mamta >> >> >> Index: >> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java >> >> === >> --- >> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java >> >> (revision 159474) >> +++ >> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java >> >> (working copy) >> @@ -750,6 +750,7 @@ >> else >> { >> afterLast = true; >> +currentPosition = positionInSource + 1; >> } >> } >> >> Index: >> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java >> >> === >> --- >> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java >> >> (revision 0) >> +++ >> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java >> >> (revision 0) >> @@ -0,0 +1,98 @@ >> +package org.apache.derbyTesting.functionTests.tests.jdbcapi; >> + >> + >> +import java.sql.*; >> + >> +import org.apache.derby.tools.ij; >> +import org.apache.derby.tools.JDBCDisplayUtil; >> + >> +public class testRelative { >> + public static void main(String[] args) { >> +test1(args);+} >> ++public static void test1(String []args) { >> +Connection con; >> +ResultSet rs; >> +PreparedStatement stmt = null; >> +PreparedStatement pStmt = null; >> +Statement stmt1 = null; >> +String returnValue = null; >> + >> +System.out.println("Test testRelative starting"); >> + >> +try >> +{ >> +// use the ij utility to read the property >> file and >> +// make the initial connection. >> +ij.getPropertyArg(args); >> +con = ij.startJBMS(); >> + >> + >> con.setAutoCommit(false); >> ++stmt = >> con.prepareStatement("create table testRelative(name varchar(10), i >> int)"); >> + stmt.executeUpdate(); >> + con.commit(); >> + >> + pStmt = con.prepareStatement("insert into >> testRelative values (?,?)"); >> + >> + pStmt.setString(1,"work1"); >> +pStmt.setNull(2,
Re: [Patch] Re: About improvement of DERBY-134
Submitted this patch. Thanks for patiently addressing all concerns. Final patch looks really good. Hope you will continue working on enhancing Derby. If you would like some ideas on what to tackle next, I can help... :-) I think this improvement has been asked by several others in the community. Satheesh Sending java\engine\org\apache\derby\impl\sql\compile\IntersectOrExceptNode.java Sending java\engine\org\apache\derby\impl\sql\compile\OrderByColumn.java Sendingjava\engine\org\apache\derby\impl\sql\compile\TableName.java Sendingjava\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj Sending java\testing\org\apache\derbyTesting\functionTests\master\orderby.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\orderby.sql Transmitting file data .. Committed revision 159746. TomohitoNakayama wrote: > Hello. > > Thanks. > I see. I re-sended patch via JIRA. > > I will send ICLA in days. > Because it is a bit substantial , I need time ... > > Best regards. > > /* > > Tomohito Nakayama > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > Naka > http://www5.ocn.ne.jp/~tomohito/TopPage.html > > */ > - Original Message - From: "Satheesh Bandaram" > <[EMAIL PROTECTED]> > To: "Derby Development" > Sent: Wednesday, March 30, 2005 3:43 AM > Subject: Re: [Patch] Re: About improvement of DERBY-134 > > >> I will work on committing this patch. Since you are working on an >> improvement, would you mind submitting this patch through Jira? Use >> AttachFile option and you also need to select "Grant ASF license to >> include in ASF works" option. (URL: >> http://issues.apache.org/jira/secure/AttachFile!default.jspa?id=29790) >> This would help committers in accepting the patch. >> >> Also, you might want to consider signing ICLA with Apache. >> (http://www.apache.org/licenses/icla.txt) This will help process your >> contributions faster. This is also a requirement to becoming a committer >> at a future time. >> >> Satheesh >> >> TomohitoNakayama wrote: >> >>> Waiting 1 day and no error was found. >>> Can I ask committers to commit this patch ? >>> >>> Or I should commit it by myself ? >>> >>> Best regards. >>> >>> /* >>> >>> Tomohito Nakayama >>> [EMAIL PROTECTED] >>> [EMAIL PROTECTED] >>> >>> Naka >>> http://www5.ocn.ne.jp/~tomohito/TopPage.html >>> >>> */ >>> - Original Message - From: "Jack Klebanoff" >>> <[EMAIL PROTECTED]> >>> To: "Derby Development" >>> Sent: Tuesday, March 29, 2005 4:31 AM >>> Subject: Re: [Patch] Re: About improvement of DERBY-134 >>> >>> >>>> TomohitoNakayama wrote: >>>> >>>>> Hello. >>>>> >>>>> I have added some test to orderby.sql (and correspond result to >>>>> orderby.out) , >>>>> which was suggested by Jack Klebanoff. >>>>> >>>>> And I have executed derbylang test and coulud not found error exept >>>>> for lang/floattypes.sql. >>>>> I think this error is not caused by my patch. >>>>> >>>>> derbylang_report.txt is attached to this mail. >>>>> >>>>> Please check this patch from a point of other person's view. >>>>> >>>>> best regards. >>>>> >>>>> /* >>>>> >>>>> Tomohito Nakayama >>>>> [EMAIL PROTECTED] >>>>> [EMAIL PROTECTED] >>>>> >>>>> Naka >>>>> http://www5.ocn.ne.jp/~tomohito/TopPage.html >>>>> >>>>> */ >>>> >>>> >>>> >>>> The latest patch looks good to me. I looked at the changes, applied >>>> the patch to recently updated Derby source, and successfully ran the >>>> derbylang test suite. (I did not even see the failure in >>>> lang/floattypes.sql that Tomohito saw. It was probably fixed in Derby >>>> updates I picked up today). >>>> >>>> Jack Klebanoff >>>> >>>> >>>> >>>> -- >>>> No virus found in this incoming message. >>>> Checked by AVG Anti-Virus. >>>> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27 >>>> >>>> >>> >>> >> >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Anti-Virus. >> Version: 7.0.308 / Virus Database: 266.8.4 - Release Date: 2005/03/27 >> >> > >
Re: [VOTE][PATCH]updates on forward only resultset using JDBC 2.0 UpdatableResultset APIs
This patch is committed. Thanks for improving performance by moving checks from runtime to compile time. Satheesh Mamta Satoor wrote: On Wed, 09 Mar 2005 09:34:35 -0800, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: +0.8 I think the functionality is correct, but there are some issues in the method checksBeforeUpdateOrDelete(). They could be addressed in a subsequent patch. - The code at the end of checksBeforeUpdateOrDelete to get the table descriptor and perform column correlation name checks is expensive, and seems like it could be done once, rather than on every updateXXX. A final solution would ideally address these concerns at compile time and not runtime, e.g. part of compilation could be identifying if a statement is suitable for updateable result sets. - Making method behaviour depend on the name of the calling method is not a common programming practise in Derby, and again is expensive. Now every updateXXX() call has to perform three String comparisions that are not needed. Ie. this code. //the remaining checks only apply to updateXXX methods + if (methodName.equals("updateRow") || methodName.equals("deleteRow") || methodName.equals("cancelRowUpdates")) +return; The typical way to address this would be to have the code before this in a separate method, have deleteRow, updateRow and cancelRowUpdate methods call that new method, and have checksBeforeUpdateOrDelete call that method (rather than duplicate code). - The lack of synchronization for the updateXXX() methods is also an area of concern. As coded two threads performing concurrent updateXXX() calls on the same result set will mess each other up, leading to missed update values or possibly NullPointerException later if cancelRowUpdates is called. But synchronization is a performance hit, and multiple threads executing concurrent operations on a JDBC object is not recommended. So maybe we can survive without it? [Putting the synchronization in getDVDforColumnUpdates() would be the logical place, not each updateXXX method.] Dan. I have a patch which takes care of first 2 points raised by Dan. Derby does not support correlation name for updatable columns. This check was earlier made at runtime everytime an updateXXX was issued. I have moved the check for correlation name to compile time in CursorNode.java. If the cursor sql has a correlation name for an updatable column, compile time code will throw an exception. The new exception code and message has been added to SQLState.java and messages_en.properties respectively. The changes in EmbedResultSet.java is to remove the runtime check for correlation name and to make the various other checks prior to updateXXX, updateRow and cancelRowUpdates and deleteRow more efficient. In addition, I have changed the existing tests to have couple more checks for compile time catch of correlation name. Can a commiter please commit this patch for me? svn stat M java\engine\org\apache\derby\impl\sql\compile\CursorNode.java M java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java M java\engine\org\apache\derby\iapi\reference\SQLState.java M java\engine\org\apache\derby\loc\messages_en.properties M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java M java\testing\org\apache\derbyTesting\functionTests\master\updatableResultSet.out M java\testing\org\apache\derbyTesting\functionTests\master\jdk14\updatableResultSet.out thanks, Mamta Index: java/engine/org/apache/derby/impl/sql/compile/CursorNode.java === --- java/engine/org/apache/derby/impl/sql/compile/CursorNode.java (revision 159525) +++ java/engine/org/apache/derby/impl/sql/compile/CursorNode.java (working copy) @@ -716,6 +716,7 @@ int size = updatableColumns.size(); TableDescriptor tableDescriptor; String columnName; + ResultColumnList rcls = resultSet.getResultColumns(); for (int index = 0; index < size; index++) { @@ -723,9 +724,22 @@ tableDescriptor = targetTable.getTableDescriptor(); if ( tableDescriptor.getColumnDescriptor(columnName) == null) { - throw StandardException.newException(SQLState.LANG_COLUMN_NOT_FOUND, columnName); + throw StandardException.newException(SQLState.LANG_COLUMN_NOT_FOUND, columnName); } + ResultColumn rc; + //make sure that we are not using correlation names for updatable columns. + //eg select c11 as col1, 2, c13 as col3 from t1 for update of c11, c12 + //In the eg above, correlation name for c11 will cause exception because Derby does not support correlation name for updatable columns + //But correlation name for c13 is ok because it is a read only column + for (int rclsIndex = 0; rclsIndex < rcls.size(); rclsIndex++) {//look through each column in the resultset for cursor + rc = ((ResultColumn) rcls.elementAt(rclsIndex)); + if (rc.
Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
Right... Option 1, adding GENERATED BY DEFAULT AS IDENTITY would be great. Satheesh Kathey Marsden wrote: Danesh Irani wrote: Hello Kathey, Christian when reporting Derby-167 had a few possible solutions, is Satheesh's proposed SQL Standard way included in one of those? If not could you perhaps elaborate a little on what Satheesh proposed. Personally I think all 3 of Christians solutions would add value in terms of flexibility to Derby. Thanks ~Danesh I couldn't find Satheesh's mail but yes it was regarding option 1, generated by default. I looked up the SQL syntax in the sql standard and put a comment in the JIRA entry. Kathey
Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134
Hi Tomohito, I thought a column that is GENERATED BY DEFAULT AS IDENTITY would allow you to insert any user specified value. System would generate a value only if there is no explicit value provided, so I am not sure if there is a need to disable "identity" feature for the column. I looked very briefly at the SQL spec. This is what it says: If is specified,then: If ALWAYS is specified, then an indication that values are always generated. If BY DEFAULT is specified, then an indication that values are generated by default. Derby already has GENERATED ALWAYS option. I think it would be great to add GENERATED BY DEFAULT option. I ran some sample querries on DB2 that I have access to. This is what it does. CREATE TABLE TBL1(COL1 INT GENERATED ALWAYS AS IDENTITY, COL2 INT) CREATE TABLE TBL2(COL1 INT GENERATED BY DEFAULT AS IDENTITY, COL2 INT) CASE1: Any insert value for COL1 is not specified explicitly or provided as DEFAULT. INSERT INTO TBL1(COL2) VALUES(10) INSERT INTO TBL2(COL2) VALUES(10) INSERT INTO TBL1(COL1, COL2) VALUES(DEFAULT, 10) INSERT INTO TBL2(COL1, COL2) VALUES(DEFAULT, 10) In this case, all of above-mentioned insert statements set COL1 to a sequence value. CASE2: An insert value for COL1 is supplied explicitly by a table value constructor. INSERT INTO TBL1(COL1, COL2) VALUES(1, 10) INSERT INTO TBL2(COL1, COL2) VALUES(1, 10) In this case, the first insert fails, but the second passes. Second insert may cause a duplicate value to be inserted into the identity column. If needed, a unique or primay key constraint can be used to prevent duplicate values for the case of GENERATED BY DEFAULT option. CASE3: An update value that is not a default specification is specified for COL1. UPDATE TBL1 SET COL1 = 1 WHERE COL2 = 10 UPDATE TBL2 SET COL1 = 1 WHERE COL2 = 10 First update statement raises an error. (case of GENERATED AS ALWAYS) Second update succeeds. (GENERATED BY DEFAULT). Again, this update may cause duplicate COL1 values, but that could be prevented by using a unique or primay key constraint. Satheesh TomohitoNakayama wrote: Hello. 2:being able to disable the "identity" feature for a column 3:being able to generate a column as non identity and after data is populated, alter table to add the "identity" to the column I think those are needed to allow user to enable loading data "AND" keep values at identity column tidy. (Now "tidy" means user can't decide pk value at their discretion.) We should have both approaches after all ... Then I think this is matter of priority. /*  Tomohito Nakayama  [EMAIL PROTECTED]  [EMAIL PROTECTED]  Naka  http://www5.ocn.ne.jp/~tomohito/TopPage.html */ - Original Message - From: "Kathey Marsden" <[EMAIL PROTECTED]> To: "Derby Development" Sent: Sunday, April 03, 2005 11:12 PM Subject: Re: (Derby 167) was Re: [Patch] Re: About improvement of DERBY-134 TomohitoNakayama wrote: Hello. I was interested in issue of Derby-167... I recognized there was proposed three options. 1:being able to "generate by default as identity" 2:being able to disable the "identity" feature for a column 3:being able to generate a column as non identity and after data is populated, alter table to add the "identity" to the column In my opinion , option 2 and option 3 increase statuses which table can take , identity feature working state and not working state, so they would make it complex to maintain db. On the other hand, if we take option 1, we need to prevent it from to have same value in identity column. I think it's ok to let the user prevent duplicates with a primary key if they want to. When creating the table, the user would need to make sure that they used START WITH to ensure that generation starts with the maximum value + 1. I put a comment in the bug with how I think the process would go. A bit precarious I know if you forget to create your table properly, but at least it makes it *possible* to load data. Later we could enhance support for ALTER TABLE to alter the identity column specification to specify a RESTART WITH value. Thanks Kathey -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 2005/04/01
Re: [jira] Commented: (DERBY-186) isFirst() returns true when relative(x) goes beyond result set
This patch is committed. Satheesh Sending java\engine\org\apache\derby\impl\sql\execute\ScrollInsensitiveResultSet.java Adding java\testing\org\apache\derbyTesting\functionTests\master\testRelative.out Sending java\testing\org\apache\derbyTesting\functionTests\suites\jdbcapi.runall Adding java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\testRelative.java Transmitting file data Committed revision 160247. Shreyas Kaushik wrote: > Did anyone get a chance to look at this and commit it? > > ~ Shreyas > > Shreyas Kaushik wrote: > >> Attached the latest patch. This addition to this patch from the old >> one is that I have added the test >> in the jdbcapi.runall file for it to run in both Embedded and Network >> Server mode. >> >> ~ Shreyas >> >> Shreyas Kaushik wrote: >> >>> Hi Mamta, >>> >>> Thanks for all the info. This definitely gave more insight into this >>> test framework. >>> I recently submitted a patch for Derby-174 and Derby-175 for which I >>> have just submitted a >>> patch for for jdbcapi.runall file. After that gets in I will >>> definitely add this one as well >>> and submit all of it in a fresh patch. I am waiting for that to go >>> in as there could be conflicts >>> in the jdbcapi.runall file. >>> >>> ~ Shreyas >>> >>> Mamta Satoor wrote: >>> On Tue, 29 Mar 2005 22:45:24 +0530, Shreyas Kaushik <[EMAIL PROTECTED]> wrote: > Hi Mamta, > > Thanks for all the info. > From this I see that adding it in jdbcapi will run in both > embedded and > netwrok server mode. > Should I add some properties file specifically for my test? > I'm sorry I ask this again, I'm not clear what changes I have to > do to > my patch ? > > ~ Shreyas > > Hi Shreyas, You will see that each of the directories under functionTests/tests have their own default properties file. If a newly added test does not have a test specific properties file, then the default properties file gets picked up. For eg, test declareGlobalTempTableJavaJDBC30.java has its own properties file because we do not want the test to be run with some jdks and we speify that declareGlobalTempTableJavaJDBC30_app.properties. Since the test you are adding has no special requirements, you donot need a properties file for it and harness will automatically use the default properties file for your test. Feel free to ask more questions if you have any. Since I have been working on this test harness for so long, I might not be visualizing some questions that a new developer might have. thanks, Mamta >> >> >> Index: >> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java >> >> === >> --- >> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java >> >> (revision 159474) >> +++ >> java/engine/org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.java >> >> (working copy) >> @@ -750,6 +750,7 @@ >> else >> { >> afterLast = true; >> +currentPosition = positionInSource + 1; >> } >> } >> >> Index: >> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java >> >> === >> --- >> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java >> >> (revision 0) >> +++ >> java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java >> >> (revision 0) >> @@ -0,0 +1,98 @@ >> +package org.apache.derbyTesting.functionTests.tests.jdbcapi; >> + >> + >> +import java.sql.*; >> + >> +import org.apache.derby.tools.ij; >> +import org.apache.derby.tools.JDBCDisplayUtil; >> + >> +public class testRelative { >> + public static void main(String[] args) { >> +test1(args);+} >> ++public static void test1(String []args) { >> +Connection con; >> +ResultSet rs; >> +PreparedStatement stmt = null; >> +PreparedStatement pStmt = null; >> +Statement stmt1 = null; >> +String returnValue = null; >> + >> +System.out.println("Test testRelative starting"); >> + >> +try >> +{ >> +// use the ij utility to read the property >> file and >> +// make the initial connection. >> +ij.getPropertyArg(args); >> +con = ij.startJBMS(); >> + >> + >> con.setAutoCommit(false); >> ++
Re: jdbcapi/testRelative failing & Derby-186
I will take a look. I submitted the patch for Shreyas and made sure the test passes on embedded driver, but didn't check Network framework. Will do so now.. Satheesh Daniel John Debrunner wrote: I'm seeing jdbcapi/testRelative failing when running with the IBM DB2 universal client and network server. This would seem to be related to Derby-186. Is anyone looking at this to see if it's a test issue, IBM DB2 driver issue or a Derby issue? http://issues.apache.org/jira/browse/DERBY-186 Dan. *** Start: testRelative jdk1.4.2_06 DerbyNet derbynetmats:jdbcapi 2005-04-07 11:45:44 *** 6 del < isFirst=false isLast=false isAfterLast=true 7 del < FAIL -- unexpected exception 8 del < SQLSTATE(24000): SQL Exception: Invalid cursor state - no current row. 9 del < SQL Exception: Invalid cursor state - no current row. 9 add isFirst=false isLast=false isAfterLast=false Value=work1 Test Failed. *** End: testRelative jdk1.4.2_06 DerbyNet derbynetmats:jdbcapi 2005-04-07 11:46:01 ***
Re: UpdatableResultSet test failing ?
Done... Let me know if you still have problems. Satheesh Myrna van Lunteren wrote: I've not tried this test on a solaris box (last time I tried on solaris was before this test was added) but both the test & the .out do not have the svn:eol-style property set. That c/would be the cause of the problem. Can one of the committers please set the svn:eol-style property to native on the .java & the master .out file? Thx... Myrna On Apr 12, 2005 9:52 AM, Shreyas Kaushik <[EMAIL PROTECTED]> wrote: Hi all, I did a fresh check out of the Derby source on a Solaris box. When the I ran the tests, the updatableResultSet.java test failed as there were "Control-M" characters at the end of every line. Is any one seeing this? This could be a windoze problem as the file could have been checked in from there. ~ Shreyas
Re: Is EXCEPT/INTERSECT complete?
My understanding was that it was mostly complete, so do file a JIRA entry with a test case. If you are interested in addressing the bug, I could provide some ideas ... :-) Satheesh Bernt M. Johnsen wrote: Andrew McIntyre wrote (2005-04-12 10:51:40): On Mar 15, 2005 7:43 AM, Bernt M. Johnsen <[EMAIL PROTECTED]> wrote: Running the latest on trunk (svn update today), I get NullPointerException when doing EXCEPT and INTERSECT in a view. If the implementation is supposed to be complete, I'll create an issue. Hi Bernt, Did you create an issue for this? No, I did not. I was wondering if the implementation was complete or if there was some unfinished work underway. I did not get any answer and forgot about the whole thing. I couldn't seem to find it in Jira. Your repro also failed in my sane/debug build, but with a more informative error message: ij> create view view1 as select * from tab1 intersect select * from tab2; 0 rows inserted/updated/deleted ij> select * from view1; ERROR XJ001: Java exception: 'ASSERT FAILED costEstimate is not expected to be null for org.apache.derby.impl.sql.compile.SelectNode: org.apache.derby.iapi.services.sanity.AssertFailure'. ij> exit; andrew
Availability of Derby client ...
As Kathy Saunders announced in February, IBM is contributing attached Derby client to Apache Derby project. Derby client is a type 4 JDBC client driver that is designed to work with Derby Network Server. I am attaching: High-level functional specification of Derby client. This document covers functionality, driver and datasource properties, setting up CLASSPATH, tracing support, security mechanism and testing support. Patch with changes to Derby build. (DerbyClientPatch.txt) Since Derby client code base was too large to for an attachment, it can be downloaded from: DerbyClientSource.jar To build Derby client, (Below ${derby.source} refers to the root of your derby source) Apply the patch DerbyClientPatch.txt. Unjar DerbyClientSource.jar into ${derby.source}/java directory. This should create a 'client' directory under ${derby.source}/java, with org.apache.derby.jdbc and org.apache.derby.client packages and a total of 116 java files under the client directory. The client code is built as part of the standard derby build, and the buildjars target will also create derbyclient.jar. To perform a clean jar build, go to ${derby.source} and then ant clobber ant ant buildjars After this, derbyclient.jar would be placed under 'sane' or 'insane' sub-directories of ${derby.source}/jars depending on your SANE property value. I call for a vote to accept Derby client by end of next week. (April 22nd) I am very excited to have this submission!!! I vote +1 to accept this as part of Derby. Satheesh Title: Derby Network Client Derby Network Client Last update: 4/11/05 Contents Overview Functionality JDBC Driver and DataSource names Ways to Connect using the Derby Client Driver Data Source properties Tracing ClientDataSource Tracing Examples DriverManager Tracing Examples Changing the Default Trace Level Security Packaging, Distribution and Versioning Comparision and/or differences with the Derby Embedded Driver Effects to existing documentation Miscellaneous Overview The Derby network client provides network connectivity to the Derby Network Server. It is distributed as an additional jar file, derbyclient.jar, with an entirely independent code base from the embedded driver. The Derby network client is a type 4, JDBC compliant Driver, which attempts to match the Derby Embedded JDBC driver as much as possible. Initially, it will have some differences from the embedded driver, for example, some SQL States will remain null and error messages will not be localized in the initial offering. Hopefully, over time the functionality of the two drivers will converge. Functionality All functionality for the Derby network client is packaged in the derbyclient.jar file which will be added to the Derby distribution. The client application needs only to include the new jar and application classes in its classpath. derbyclient.jar has no dependencies on the tools, server, or derby database engine classes, nor do those classes depend on derbyclient.jar. Some new client classes are in the same package as the embedded driver, such as org.apache.derby.jdbc.ClientDriver, but the actual classes are contained only in the client jar file. The Derby network client allows connections via JDBC URL using DriverManager by its implementations of JDBC20 data sources, javax.sql.DataSource, javax.sql.ConnectionPoolDataSource. An implementation of javax.sql.XADataSource is also provided for network XA Support. The Derby network client provides a tracing facility to collect JDBC trace information and view protocol flows for debugging. Security mechanisms are also provided for user and password encryption. DataSource properties and connection attributes can be used to enable tracing, as well as security settings. Tools support for ij and dblook as well as test harness support is provided. The sections that follow will describe the functionality and provide examples of using each characteristic mentioned here. JDBC Driver and DataSource names The Derby network client classes and JDBC interfaces they implement are listed below. JDBC Interface Derby network client class java.sql.Driver org.apache.derby.jdbc.ClientDriver javax.sql.DataSource org.apache.derby.jdbc.ClientDataSource javax.sql.XADataSource org.apache.derby.jdbc.ClientXADataSource javax.sql.ConnectionPoolDataSource org.apache.derby.jdbc.ClientConnectionPoolDataSource Connection URL Format The protocol for the client URL is jdbc:derby://. The embedded and client attributes are specified the same way. The embedded driver has been changed to reject URL's with a // following derby: Derby network client URL Format jdbc:derby://server[:port]/databaseName[;attributeKey=value].. An example of using this URL to connect to the Derby network server running on the localhost at port
Re: engine javadoc on the web
This is really cool!... Thanks for getting this going. Satheesh Andrew McIntyre wrote: On 4/7/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Andrew McIntyre wrote: There was some interest a while back about having the Derby engine javadoc posted somewhere on the web. It would be excellent to keep this updated automatically in a known place. One addition needed would be a generation data and/or svn revision number on the index page, or maybe in each header or footer. I've set up a nightly sync of all the javadoc at the following URL, per Jean's suggestion: http://incubator.apache.org/derby/javadoc/ The sync should begin this evening. Engine javadoc specifically is here: http://incubator.apache.org/derby/javadoc/engine/ I've also set up a nightly sync of built user documentation to: http://incubator.apache.org/derby/docs/ Currently, the modification date on the directories at the URLs listed above will give a general idea of how recently it was built, but I will file JIRA entries for adding timestamps to both the javadoc and userdoc build. andrew
Re: Availability of Derby client ...
Good catch... I will remove Microsoft Office headers... Satheesh Jeremy Boynes wrote: > Myrna van Lunteren wrote: > >> I had used Mozilla's html editor when I created the file. >> What's the Microsoft Office junk you refer to? >> > > Stuff like that below taken from the patch ... the Microsoft > proprietary markup makes editing the file difficult using a real HTML > editor (like vi) which is what we will need to do going forward. > > === > --- java/testing/README.htm(revision 161156) > +++ java/testing/README.htm(working copy) > @@ -1,1189 +1,2159 @@ > > - > + +xmlns:w="urn:schemas-microsoft-com:office:word" > +xmlns:st1="urn:schemas-microsoft-com:office:smarttags" > +xmlns="http://www.w3.org/TR/REC-html40";> > + > > - - http-equiv="content-type"> > - readme.htm > + > + > + > + > + > +readme.htm > + namespaceuri="urn:schemas-microsoft-com:office:smarttags" > + name="date"/> > + namespaceuri="urn:schemas-microsoft-com:office:smarttags" > + name="City"/> > + namespaceuri="urn:schemas-microsoft-com:office:smarttags" > + name="State"/> > + namespaceuri="urn:schemas-microsoft-com:office:smarttags" > + name="place"/> > + namespaceuri="urn:schemas-microsoft-com:office:smarttags" > + name="time"/> > +
Re: how to specify join strategy and index
Derby doesn't have a way specify join strategy or index. There has been some discussion on this topic in the past, but currently Derby doesn't support 'optimizer-hints' or 'optimizer-overrides'. Some of the previous postings include: http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200412.mbox/[EMAIL PROTECTED] http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200412.mbox/[EMAIL PROTECTED] http://mail-archives.eu.apache.org/mod_mbox/db-derby-dev/200412.mbox/[EMAIL PROTECTED] Satheesh ?? ? wrote: > Hi, developers > >> From the documentation, we know if we don't like the join strategy >> and index > > choosed by derby system for us, users can speicfy their own. > > But how to specify join strategy or index when querying over derby? > in query statement? or anywhere else? > > If anyone konw, please give me an exmaple. > Thanks. > > _ > Express yourself instantly with MSN Messenger! Download today it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > >
[VOTE] accept derby client contribution
I just realized I called for a vote to accept Derby client without the [VOTE] subject header, in the middle of a longish email. I would like to reissue the call for vote. I call for all those who voted already to vote again, please... [ ] +1: Accept the contribution of the derby client [ ] -1: Reject the contribution of the derby client The voting is open till end of 22nd April, 2004. (GMT) Satheesh
Re: [VOTE] accept derby client contribution
[X] +1: Accept the contribution of the derby client Satheesh Satheesh Bandaram wrote: >I just realized I called for a vote to accept Derby client without the >[VOTE] subject header, in the middle of a longish email. I would like to >reissue the call for vote. I call for all those who voted already to >vote again, please... > >[ ] +1: Accept the contribution of the derby client >[ ] -1: Reject the contribution of the derby client > >The voting is open till end of 22nd April, 2004. (GMT) > >Satheesh > > > > > >
Re: Availability of Derby client ...
Thanks Myrna. If Derby client vote is accepted, I will apply your changes as a patch to original Derby README file. Satheesh Myrna van Lunteren wrote: Hi Satheesh, Jeremy, I looked at the changed java/testing/README.htm, & felt we should replace the references to DerbyNet framework with DerbyNetClient in a couple more places. While I was at it, I also changed some of the notes. So, here is an updated README.htm to go with the DerbyClient offering. I started from the original, so this has no MS references. Myrna On 4/15/05, Satheesh Bandaram <[EMAIL PROTECTED]> wrote: Good catch... I will remove Microsoft Office headers... Satheesh Jeremy Boynes wrote: Myrna van Lunteren wrote: I had used Mozilla's html editor when I created the file. What's the Microsoft Office junk you refer to? Stuff like that below taken from the patch ... the Microsoft proprietary markup makes editing the file difficult using a real HTML editor (like vi) which is what we will need to do going forward. === --- java/testing/README.htm(revision 161156) +++ java/testing/README.htm(working copy) @@ -1,1189 +1,2159 @@ - +"http://www.w3.org/TR/REC-html40"> + - - readme.htm + + + + + +readme.htm + + + + + +> Index: java/testing/README.htm === --- java/testing/README.htm (revision 161498) +++ java/testing/README.htm (working copy) @@ -13,7 +13,7 @@ created by [EMAIL PROTECTED] -last updated on 12/02/2004 by: [EMAIL PROTECTED] +last updated on 04/18/2005 by: [EMAIL PROTECTED] @@ -90,7 +90,9 @@ Before you can run, you need to setup your environment: - Obtain a jdk or jre (based on jdk 1.3.1 specification or higher). + Obtain a jdk or jre (based on jdk 1.3.1 specification See Note1 or +higher). Add the bin directory to your $PATH. Currently supported are: @@ -134,9 +136,11 @@ derby tools classes for tools like ij and dblookderbynet.jar - derby network server classesdb2jcc.jar -and db2jcc_license_c.jar + derby network server classesderbyclient.jar + derby client classesdb2jcc.jar +and db2jcc_license_c.jar + IBM Universal JDBC Driver classes. (See IBM "http://www-106.ibm.com/developerworks/db2/downloads/jcc/">developerworks for download) @@ -158,12 +162,14 @@ (note that $jardir is -only a convenience variable and that the command below has carriage +only a convenience variable and that the set CLASSPATH command below +has carriage returns for formatting reasons): set jardir=/local/derbyjar set -CLASSPATH="$jardir/derby.jar:$jardir/derbytools.jar:$jardir/derbynet.jar:$jardir/db2jcc.jar: -$jardir/db2jcc_license_c.jar:$jardir/derbyTesting.jar:/local/derby/tools/java/jakarta-oro-2.0.8.jar: +CLASSPATH="$jardir/derby.jar:$jardir/derbytools.jar:$jardir/derbynet.jar:$jardir/derbyclient.jar: +$jardir/db2jcc.jar:$jardir/db2jcc_license_c.jar: +$jardir/derbyTesting.jar:/local/derby/tools/java/jakarta-oro-2.0.8.jar: $jardir/derbyLocale_de_DE.jar:$jardir/derbyLocale_es.jar:$jardir/derbyLocale_fr.jar: $jardir/derbyLocale_it.jar:$jardir/derbyLocale_ja_JP.jar:$jardir/derbyLocale_ko_KR.jar: $jardir/derbyLocale_pt_BR.jar:$jardir/derbyLocale_zh_CN.jar:$jardir/derbyLocale_zh_TW.jar: @@ -205,12 +211,13 @@ org.apache.derbyTesting.functionTests.harness.RunTest lang/supersimple.sql -To run a test with network server, add -Dframework=DerbyNet to the run. +To run a test with network server, using the derbyclient driver, add +-Dframework=DerbyNetClient to the run. The test harness will to start network server at port 1527 or connect to a running one, run the test, and stop network server thereafter. for example: - java -Dframework=DerbyNet + java -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest lang/supersimple.sql @@ -275,16 +282,24 @@ tested on a variety of hardware takes from 1.15m to 2.00 hours + derbynetclientmats + +basic network server tests using the derby client + +variety of tests, including some from derbylang suite +tested on a variety of hardware takes from 15 to 30 minutes + derbynetmats -basic network server tests. +basic network server tests using the IBM Universal JDBC driver + variety of tests, including some from derbylang suite tested on a variety of hardware takes from 15 to 30 minutes derbynetautostart -tests networkserver functionality without requiring -networkserver framework +tests network server functionality without requiring +network server framework propertyinfo @@ -424,7 +439,8 @@ i18nTest -tests that characters outside simple ascii scope do not
Re: [jira] Commented: (DERBY-229) Column names on ResultSet.updateXXX and getXXX methods are handled incorrectly
Looks like this bug has all the information needed to reproduce and to generate a patch. Is there any interest to submit a patch for this relatively easy fix? A complete patch would include a fix, along the general idea provided here and a test case added to jdbcapi test suite. Good opportunity for anyone wanting to get started modifying Derby code. Any volunteers? :-) I am willing to help, if needed. Satheesh Mamta A. Satoor (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-229?page=comments#action_63128 ] Mamta A. Satoor commented on DERBY-229: --- The getter [updater] methods with column names (in EmbedResultSet.java) use the protected method findColumnName(String columnName) to determine the column index for the passed column name. And the loop for the lookup starts from the end towards the beginning of the ResultDescription and that seems to be the problem behind the current behavior. ResultDescription rd = resultDescription; // 1 or 0 based? assume 1 (probably wrong) for (int i=rd.getColumnCount(); i>=1; i--) { String name = rd.getColumnDescriptor(i).getName(); if (StringUtil.SQLEqualsIgnoreCase(columnName, name)) { return i; } } Column names on ResultSet.updateXXX and getXXX methods are handled incorrectly -- Key: DERBY-229 URL: http://issues.apache.org/jira/browse/DERBY-229 Project: Derby Type: Bug Components: JDBC Versions: 10.1.0.0, 10.0.2.1 Reporter: Daniel John Debrunner Attachments: x.java Sections 14.2.3 and [14.2.3] of JDBC 3.0 spec say Column names supplied to getter [updater] methods are case insensitive. If a select list contains the same column more than once, the first instance of the column will be returned [updated]. Derby returns or updates the last column in the select list, not the first. With the attached Java class I see PRE-UPDATE 1,100 POST-UPDATE 1,500 POST-UPDATE getXXX(name) AB:500,ab500
Re: [PATCH] Re: [jira] Updated: (DERBY-219) EXCEPT/INTERSECT fails in views
Submitted this patch. Satheesh Sending java\engine\org\apache\derby\impl\sql\compile\IntersectOrExceptNode.java Sending java\testing\org\apache\derbyTesting\functionTests\master\intersect.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\intersect.sql Transmitting file data ... Committed revision 162098. Jack Klebanoff wrote: I have made a fix for the problem. Actually the bug affects any subquery, not just a view. The fix includes an expanded lang/intersect.sql test. The fix passes the derbylang test suite. The patch is included here and in Jira. Jack Klebanoff Index: java/engine/org/apache/derby/impl/sql/compile/IntersectOrExceptNode.java === --- java/engine/org/apache/derby/impl/sql/compile/IntersectOrExceptNode.java (revision 161138) +++ java/engine/org/apache/derby/impl/sql/compile/IntersectOrExceptNode.java (working copy) @@ -224,6 +224,18 @@ RowOrdering rowOrdering) throws StandardException { + leftResultSet = optimizeSource( + optimizer, + leftResultSet, + (PredicateList) null, + outerCost); + + rightResultSet = optimizeSource( + optimizer, + rightResultSet, + (PredicateList) null, + outerCost); + CostEstimate costEstimate = getCostEstimate(optimizer); CostEstimate leftCostEstimate = leftResultSet.getCostEstimate(); CostEstimate rightCostEstimate = rightResultSet.getCostEstimate(); Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/intersect.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/intersect.sql (revision 161138) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/intersect.sql (working copy) @@ -143,3 +143,20 @@ -- Invalid order by select id,i1,i2 from t1 intersect select id,i1,i2 from t2 order by t1.i1; select id,i1,i2 from t1 except select id,i1,i2 from t2 order by t1.i1; + +-- views using intersect and except +create view view_intr_uniq as select id,i1,i2 from t1 intersect select id,i1,i2 from t2; +select * from view_intr_uniq order by 1 DESC,2,3; + +create view view_intr_all as select id,i1,i2 from t1 intersect all select id,i1,i2 from t2; +select * from view_intr_all order by 1,2,3; + +create view view_ex_uniq as select id,i1,i2 from t1 except select id,i1,i2 from t2; +select * from view_ex_uniq order by 1,2,3; + +create view view_ex_all as select id,i1,i2 from t1 except all select id,i1,i2 from t2; +select * from view_ex_all order by 1 DESC,2,3; + +-- intersect joins +select t1.id,t1.i1,t2.i1 from t1 join t2 on t1.id = t2.id +intersect select t1.id,t1.i2,t2.i2 from t1 join t2 on t1.id = t2.id; Index: java/testing/org/apache/derbyTesting/functionTests/master/intersect.out === --- java/testing/org/apache/derbyTesting/functionTests/master/intersect.out (revision 161138) +++ java/testing/org/apache/derbyTesting/functionTests/master/intersect.out (working copy) @@ -350,4 +350,44 @@ ERROR 42877: A qualified column name 'T1.I1' is not allowed in the ORDER BY clause. ij> select id,i1,i2 from t1 except select id,i1,i2 from t2 order by t1.i1; ERROR 42877: A qualified column name 'T1.I1' is not allowed in the ORDER BY clause. +ij> -- views using intersect and except +create view view_intr_uniq as select id,i1,i2 from t1 intersect select id,i1,i2 from t2; +0 rows inserted/updated/deleted +ij> select * from view_intr_uniq order by 1 DESC,2,3; +ID |I1 |I2 +--- +5 |NULL |NULL +2 |1 |2 +1 |1 |1 +ij> create view view_intr_all as select id,i1,i2 from t1 intersect all select id,i1,i2 from t2; +0 rows inserted/updated/deleted +ij> select * from view_intr_all order by 1,2,3; +ID |I1 |I2 +--- +1 |1 |1 +2 |1 |2 +5 |NULL |NULL +ij> create view view_ex_uniq as select id,i1,i2 from t1 except select id,i1,i2 from t2; +0 rows inserted/updated/deleted +ij> select * from view_ex_uniq order by 1,2,3; +ID |I1 |I2 +--- +3 |1 |3 +4 |1 |3 +6 |NULL |NULL +ij> create view view_ex_all as select id,i1,i2 from t1 except all select id,i1,i2 from t2; +0 rows inserted/updated/deleted +ij> select * from view_ex_all order by 1 DESC,2,3; +ID |I1 |I2 +--- +6 |NULL |NULL +4 |1 |3 +3 |1 |3 +ij> -- intersect joins +select t1.id,t1.i1,t2
Re: [PATCH] Some small test change for Network Server
Committed this patch. Satheesh Sending java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java Sending java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\holdCursorIJ.out Sending java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\scrollCursors1.out Sending java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\holdCursorIJ.out Sending java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\scrollCursors1.out Sending java\testing\org\apache\derbyTesting\functionTests\master\holdCursorIJ.out Sending java\testing\org\apache\derbyTesting\functionTests\master\scrollCursors1.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\holdCursorIJ.sql Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\scrollCursors1.sql Transmitting file data . Committed revision 164284. [bandaram:satheesh] Army wrote: Attached is a small patch that does the following two things: 1) Changes the "lang/holdCursorIJ.sql" and "lang/scrollCursors1.sql" tests to clean up after each test case (by closing any opened cursors). Without this cleanup, some later versions of JCC can show false failures for these two tests. 2) Adds a "sed" filter to the harness that will filter out some unwanted JCC text that can be appended to certain error messages. This text isn't related to the actual errors in question and thus looks to be irrelevant. By filtering it out, we can avoid some false failures that can occur with later versions of JCC. Could a committer please commit? Thanks, Army Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/scrollCursors1.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/scrollCursors1.sql (revision 164154) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/scrollCursors1.sql (working copy) @@ -233,6 +233,7 @@ update t1 set i = 666 where i = 2; first c1; rollback; +close c1; -- verify that statement cache works -- correctly with scroll and forward only Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/holdCursorIJ.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/holdCursorIJ.sql (revision 164154) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/holdCursorIJ.sql (working copy) @@ -34,6 +34,10 @@ close jdk4; next jdk4; +-- clean up. +close jdk1; +close jdk2; + -- second test - make sure that all the cursors (including holdability true) -- have their resultsets closed after rollback. @@ -56,6 +60,11 @@ next jdk2; next jdk4; +-- clean up. +close jdk1; +close jdk2; +close jdk4; + -- third test - Define a hold cursor on a table. Shouldn't be able to drop that -- table before & after commit. Have to close the cursor before table can be dropped. @@ -74,6 +83,9 @@ close jdk4; drop table t1; +-- clean up. +close jdk1; + -- recreate and populate the table for next test create table t1(c11 int, c12 int); insert into t1 values(1,1); @@ -98,6 +110,9 @@ close jdk4; set isolation to serializable; +-- clean up. +close jdk1; + -- fifth test - try isolation level change alongwith changing the isolation -- level of just one statement get with hold cursor jdk4 as 'SELECT * FROM t1'; @@ -113,6 +128,9 @@ set isolation READ UNCOMMITTED; set isolation RS; +-- clean up. +close jdk1; + -- sixth test - try positioned update with hold cursor get with hold cursor jdk4 as 'SELECT * FROM t1 FOR UPDATE'; -- following should give error because cursor is not positioned on any row @@ -186,5 +204,8 @@ next scrollCursor; update t1 set c12=c12+1 where current of scrollCursor; +-- clean up. +close scrollCursor; + Index: java/testing/org/apache/derbyTesting/functionTests/harness/Sed.java === --- java/testing/org/apache/derbyTesting/functionTests/harness/Sed.java (revision 164154) +++ java/testing/org/apache/derbyTesting/functionTests/harness/Sed.java (working copy) @@ -178,6 +178,10 @@ //Filter to suppress absould paths in error message for roll forward recovery tests searchStrings.addElement("Directory.*.wombat.already.exists"); +// Filter for "DB2ConnectionCorrelator" text that can be printed as +// part of some JCC error messages. +searchStrings.addElement(" DB2ConnectionCorrelator: [0-9A-Z.]*"); + Vector subStrings = new Vector(); subStrings.addElement(""); subStrings.addElement(""); @@ -222,6 +226,8 @@ subStrings.addElement("-"); } subStrings.addElement("Directory DBLOCATION/wombat already exists"); + // ignore the 'DB2ConnectionCorrelator' thing altogether. + subStrings.addElement(""); doWork(srcFile
Re: [PATCH] upgrade fix related to checksum support for transaction log to recognize out of order log writes during recovery (Derby-96)
I wish eventually we could consolidate all the version checking logic in one place, common to the whole engine. Current Derby client patch has similar logic, in package org.apache.derby.client.am.ProductLevel, though this is also used for other purpose. Satheesh Suresh Thalamati wrote: Attached is the new patch with the suggested changes to make softupgrade correctly with the transaction log checksum feature in 10.1 Added checkVersion() method to log factory it self, becuase that is where the version numbers are read from from the log control file , but did not export the call it to the rawstore factory as it is not needed now. (This can be done easlily when there is a need for upgrade checks in the other store modules..) Thanks -suresht Mike Matrigali wrote: Ok, that is the info I needed. Suresh could you resubmit the change with comments like the one dan has below. And change the check to simply check if the on disk version is is 10.0, no need to check current version. It would be nice to have some sort of store facility like the one language has, but the problem for this case is that logging system needs it during boot and there is not much else available until boot is finished. Daniel John Debrunner wrote: Mike Matrigali wrote: Given that Dan is working on the upgrade stuff, I think the change below handles the current, and next release fine. More changes can be made as it becomes clear how rest of code is handling soft upgrade. Going forward I would like to see a better model for the code below. For this discussion assume current release is 10.0.x and next 2 releases are 10.1.x and 10.2.x. If derby supports soft upgrade from 10.0.x directly to 10.2.x then the code below will have to change, meaning someone is going to have to remember to change it (maybe a sanity statement could force an error if version is not what is expected?): Soft upgrade is expected to work on any previous release, and the code to handle it should work without having to change every release. Take a language feature that was added in release X and cannot be used in soft upgrade mode because it writes new information to the system catalogs, that would not be understood by releases earlier than X. The language layer handles this by checking that the database (on disk) has been upgraded to at least release X before allowing compilation or execution of the feature, by calling the method DataDictionary.checkVersion(). E.g. for a routine with a method signature (new in 10.1) this check is made (I'm just about to commit this code). // Support for Java signatures in Derby was added in 10.1 // Check to see the catalogs have been upgraded to 10.1 before // accepting such a method name for a routine. Otherwise // a routine that works in 10.1 soft upgrade mode would // exist when running 10.0 but not resolve to anything. if (this.methodName.indexOf('(') != -1) { getDataDictionary().checkVersion( DataDictionary.DD_VERSION_DERBY_10_1, "EXTERNAL NAME 'class.method()'"); } This style of check will work with any future version so it's a safe approach. The store layer needs to have a similar policy. Dan. Index: java/engine/org/apache/derby/impl/store/raw/log/LogAccessFile.java === --- java/engine/org/apache/derby/impl/store/raw/log/LogAccessFile.java (revision 164300) +++ java/engine/org/apache/derby/impl/store/raw/log/LogAccessFile.java (working copy) @@ -35,6 +35,7 @@ import org.apache.derby.iapi.services.io.FormatIdOutputStream; import org.apache.derby.iapi.services.io.ArrayOutputStream; +import org.apache.derby.iapi.store.raw.RawStoreFactory; /** @@ -116,7 +117,7 @@ private long checksumInstant = -1; private int checksumLength; private int checksumLogRecordSize; //checksumLength + LOG_RECORD_FIXED_OVERHEAD_SIZE - private boolean writeChecksum = true; //gets set to false incase of a soft upgrade. + private boolean writeChecksum; private ChecksumOperation checksumLogOperation; private LogRecord checksumLogRecord; private LogToFile logFactory; @@ -152,7 +153,14 @@ } currentBuffer = (LogAccessFileBuffer) freeBuffers.removeFirst(); - + + // Support for Transaction Log Checksum in Derby was added in 10.1 + // Check to see if the Store have been upgraded to 10.1 or later before + // writing the checksum log records. Otherwise recovery will fail + // incas
[RESULT] [VOTE] accept derby client contribution
Passed, with nine +1 votes and no -1 vote. However, Derby client checkin into trunk may get delayed, pending resolution of CCLA discussion, initialied by Geir: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL PROTECTED] Follow up questions from Ken and Dan are pending still: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL PROTECTED] Satheesh --- Begin Message --- I just realized I called for a vote to accept Derby client without the [VOTE] subject header, in the middle of a longish email. I would like to reissue the call for vote. I call for all those who voted already to vote again, please... [ ] +1: Accept the contribution of the derby client [ ] -1: Reject the contribution of the derby client The voting is open till end of 22nd April, 2004. (GMT) Satheesh --- End Message ---
Re: [PATCH] Conversions to Date and Timestamp
Submitted this patch. Nicely done patch. I added new UnaryDateTimestampOperatorNode to the list of nodes in DBMSnodes.properties, so that Derby JAR build will pick up the class. Otherwise, I suspect tests on JAR build might fail. Satheesh Sending java\engine\org\apache\derby\iapi\reference\SQLState.java Sending java\engine\org\apache\derby\iapi\sql\compile\C_NodeTypes.java Sending java\engine\org\apache\derby\iapi\types\DataValueFactory.java Sending java\engine\org\apache\derby\iapi\types\DataValueFactoryImpl.java Sending java\engine\org\apache\derby\iapi\types\SQLDate.java Sending java\engine\org\apache\derby\iapi\types\SQLTime.java Sending java\engine\org\apache\derby\iapi\types\SQLTimestamp.java Sending java\engine\org\apache\derby\impl\sql\compile\C_NodeNames.java Sending java\engine\org\apache\derby\impl\sql\compile\NodeFactoryImpl.java Adding java\engine\org\apache\derby\impl\sql\compile\UnaryDateTimestampOperatorNode.java Sending java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj Sending java\engine\org\apache\derby\loc\messages_en.properties Sending java\testing\org\apache\derbyTesting\functionTests\master\datetime.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\datetime.sql Sending tools\jar\DBMSnodes.properties Transmitting file data ... Committed revision 164873. Jack Klebanoff wrote: The attached path contains some fixes to conversions to dates and timestamps. 1. According to the Derby documentation the DATE and TIMESTAMP functions provide some conversions beyond those handled by the normal casts. This patch implements them. The DATE function converts a numeric argument to a date by taking the integer portion of the number and considering it as the number of days since Jan. 1 1970. The DATE function also handles a string of length 7 in the format 'ddd'. It is taken to indicate the ddd'th day of year . The TIMESTAMP function handles string arguments of length 14 in the format 'MMddhhmmss'. Any other arguments to the DATE and TIMESTAMP functions are handled as normal casts to date or timestamp. (The TIME function does not do any special conversions. It is the same as the CAST function). 2. The string to time cast has been made more lenient by making the seconds field optional. Previously the DATE and unary TIMESTAMP functions were implemented by converting them to calls to CAST. This was done in the parser. The patch changes this. The parser now generates a UnaryDateTimestampOperatorNode to represent these functions. The generated code calls new DataValueFactory methods. Most of the actual work is done in the SQLDate and SQLTimestamp classes. The patch passed the derbyall suite. Jack Klebanoff Index: java/engine/org/apache/derby/impl/sql/compile/NodeFactoryImpl.java === --- java/engine/org/apache/derby/impl/sql/compile/NodeFactoryImpl.java (revision 164436) +++ java/engine/org/apache/derby/impl/sql/compile/NodeFactoryImpl.java (working copy) @@ -554,6 +554,9 @@ case C_NodeTypes.SAVEPOINT_NODE: return C_NodeNames.SAVEPOINT_NODE_NAME; + case C_NodeTypes.UNARY_DATE_TIMESTAMP_OPERATOR_NODE: +return C_NodeNames.UNARY_DATE_TIMESTAMP_OPERATOR_NODE_NAME; + case C_NodeTypes.TIMESTAMP_OPERATOR_NODE: return C_NodeNames.TIMESTAMP_OPERATOR_NODE_NAME; Index: java/engine/org/apache/derby/impl/sql/compile/UnaryDateTimestampOperatorNode.java === --- java/engine/org/apache/derby/impl/sql/compile/UnaryDateTimestampOperatorNode.java (revision 0) +++ java/engine/org/apache/derby/impl/sql/compile/UnaryDateTimestampOperatorNode.java (revision 0) @@ -0,0 +1,196 @@ +/* + + Derby - Class org.apache.derby.impl.sql.compile.UnaryDateTimestampOperatorNode + + Copyright 2004 The Apache Software Foundation or its licensors, as applicable. + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + + */ + +package org.apache.derby.impl.sql.compile; + +import org.apache.derby.iapi.types.DataValueFactory; +import org.apache.derby.iapi.types.DataTypeDescriptor; +import org.apache.derby.iapi.types.DataValueDescriptor; +import org.apache.derby.iapi.types.DateTimeDataValue; +import org.apache.derby.iapi.services.compiler.MethodBuilder; +import org.
Re: [jira] Commented: (DERBY-229) Column names on ResultSet.updateXXX and getXXX methods are handled incorrectly
Cool. Thanks! Let me know if I can help. Satheesh Shreyas Kaushik wrote: > I will start looking at this. I volunteer ;-) > > ~ Shreyas > > Satheesh Bandaram wrote: > >> Looks like this bug has all the information needed to reproduce and >> to generate a patch. Is there any interest to submit a patch for this >> relatively easy fix? A complete patch would include a fix, along the >> general idea provided here and a test case added to jdbcapi test >> suite. Good opportunity for anyone wanting to get started modifying >> Derby code. Any volunteers? :-) >> >> I am willing to help, if needed. >> >> Satheesh >> >> Mamta A. Satoor (JIRA) wrote: >> >>> [ >>> http://issues.apache.org/jira/browse/DERBY-229?page=comments#action_63128 >>> ] >>> Mamta A. Satoor commented on DERBY-229: >>> --- >>> >>> The getter [updater] methods with column names (in >>> EmbedResultSet.java) use the protected method findColumnName(String >>> columnName) to determine the column index for the passed column >>> name. And the loop for the lookup starts from the end towards the >>> beginning of the ResultDescription and that seems to be the problem >>> behind the current behavior. ResultDescription rd = >>> resultDescription; >>> >>>// 1 or 0 based? assume 1 (probably wrong) >>>for (int i=rd.getColumnCount(); i>=1; i--) { >>> >>>String name = rd.getColumnDescriptor(i).getName(); >>>if (StringUtil.SQLEqualsIgnoreCase(columnName, name)) { >>>return i; >>>} >>>} >>> >>> >>> >>> >>>> Column names on ResultSet.updateXXX and getXXX methods are handled >>>> incorrectly >>>> -- >>>> >>>> >>>> Key: DERBY-229 >>>> URL: http://issues.apache.org/jira/browse/DERBY-229 >>>> Project: Derby >>>>Type: Bug >>>> Components: JDBC >>>>Versions: 10.1.0.0, 10.0.2.1 >>>>Reporter: Daniel John Debrunner >>>> Attachments: x.java >>>> >>>> Sections 14.2.3 and [14.2.3] of JDBC 3.0 spec say >>>> Column names supplied to getter [updater] methods are case >>>> insensitive. If a select list >>>> contains the same column more than once, the first instance of the >>>> column will be >>>> returned [updated]. >>>> Derby returns or updates the last column in the select list, not >>>> the first. With the attached Java class I see >>>> PRE-UPDATE >>>> 1,100 >>>> POST-UPDATE >>>> 1,500 >>>> POST-UPDATE getXXX(name) >>>> AB:500,ab500 >>>> >>> >>> >>> >>> > > >
Re: Timing code in Derby
That information can be seen using system procedures to get runtime statistics. You can set statistics gathering using SYSCS_SET_RUNTIMESTATISTICS() and get the statistics gathered after a query is executed using SYSCS_GET_RUNTIMESTATISTICS(). There should be more info about these in Derby manuals or you can check out some test cases in 'lang' test directory. Satheesh Shreyas Kaushik wrote: > Hi all, > > I have seen code like the following lines in many places in Derby code. > > *beginTime = getCurrentTimeMillis()* and *openTime += > getElapsedTime(beginTime). > * > I presume these methods are used to calculate the time taken to > perform some operation like a fetch, open, etc. Is this information > stored anywhere in the logs ? I could not see this anywhere. Is there > something extra ( a parameter setting or some properties file) that > needs to be done to enable this and see the results? > > ~ Shreyas > > > >
Re: [RESULT] [VOTE] accept derby client contribution
Submitted Derby client source to trunk. Post any problems you notice with Derby client. Enjoy! Please use the functional spec for usage. I will work with Jean to host it at Derby website. Satheesh Kathy Saunders wrote: > Satheesh Bandaram wrote: > >> Passed, with nine +1 votes and no -1 vote. However, Derby client checkin >> into trunk may get delayed, pending resolution of CCLA discussion, >> initialied by Geir: >> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL >> PROTECTED] >> >> >> Follow up questions from Ken and Dan are pending still: >> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL >> PROTECTED] >> >> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL >> PROTECTED] >> >> >> Satheesh >> >> > Hi, > > IBM faxed an amended CCLA, which includes the contribution of the > Derby client, to Apache this morning. > > Kathy > > >
Derby client bugs ...
I have created a new 'Network Client' component in Jira for Derby project. If you encounter a bug with Derby client, either post it to this alias or file it in Jira under this component. Satheesh
Re: [jira] Assigned: (DERBY-13) Quoted names with embedded period mishandled in from list
U are correct... I think both of them seem to have been fixed, based on the test case in the defect. I will close both of them, if everyone agrees. Satheesh Shreyas Kaushik wrote: > I thought this was patched ?? > > ~ Shreyas > > Jack Klebanoff (JIRA) wrote: > >> [ http://issues.apache.org/jira/browse/DERBY-13?page=all ] >> >> Jack Klebanoff reassigned DERBY-13: >> --- >> >>Assign To: Jack Klebanoff >> >> >> >>> Quoted names with embedded period mishandled in from list >>> - >>> >>> Key: DERBY-13 >>> URL: http://issues.apache.org/jira/browse/DERBY-13 >>> Project: Derby >>>Type: Bug >>> Components: SQL >>>Versions: 10.0.2.0 >>>Reporter: Ramandeep Kaur >>>Assignee: Jack Klebanoff >>>Priority: Minor >>> Attachments: Derby-13.diff, Derby-13.patch, derbylang_report.txt >>> >>> Opening this bug on behalf of Satheesh Bandaram >>> - >>> The compiler mishandles quoted names with embedded periods when >>> checking uniqueness of table names in the from list of a SELECT. >>> Consider the following SQL: >>> create table "S1.T1" (id int not null primary key, d1 int); >>> create schema s1; >>> create table s1.t1 (id int not null primary key, d2 int); >>> select * from s1.t1, "S1.T1" where s1.t1.id = "S1.T1".id; >>> Derby throws an error on the final SELECT statement: >>> "ERROR 42X09: The table or alias name 'S1.T1' is used more than once >>> in the FROM list". However s1.t1 and "S1.T1" are different tables. >>> >> >> >> >> > > >
Re: [PATCH] Derby-250 With client setObject( parameterIndex, x, java.sql.DOUBLE) throws conversion exception if the object passed is a BigDecimal with more than 31 digits
+1. I suspect the change to TestRelative is for some other purpose, but that looks right too. Not sure if Shreyas was going to checkin that part, though. Satheesh Kathey Marsden wrote: This is a patch for Derby-250 to eliminate the conversion error when a BigDecimal with more than 31 digits is passed to setObject with a targetSqlType. public void setObject(int parameterIndex, Object x, int targetSqlType) throws SQLException or public void setObject(int parameterIndex, Object x, int targetSqlType, int scale) throws SQLException The approach of the patch is to have setObject calls with a targetSqlType to always convert before sending to the value to the server for all types. Taking this approach exposed other issues with the client's conversion mechanism for Date, Time and Timestamp, which were customized valueOf methods to support ISO format. Since the extended format is not needed for Derby, I replaced these with the standard .valueOf calls. The patch also fixes issues with scale getting set properly when specified for these calls. I'll commit this afternoon if there are no objections. Thanks Kathey Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java === --- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java (revision 165209) +++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java (working copy) @@ -8,32 +8,34 @@ public class testRelative { - static final String EXPECTED_SQL_STATE = "24000"; - static Connection con; - static ResultSet rs; - static PreparedStatement stmt = null; - static PreparedStatement pStmt = null; - static Statement stmt1 = null; - static String returnValue = null; - + static final String NO_CURRENT_ROW_SQL_STATE = "24000"; + public static void main(String[] args) { -test1(args); + System.out.println("Test testRelative starting"); + Connection con = null; + try { + // use the ij utility to read the property file and + // make the initial connection. + ij.getPropertyArg(args); + con = ij.startJBMS(); + test1(con); + } catch (Exception e) + { + unexpectedException(e); + } } -public static void test1(String []args) { -System.out.println("Test testRelative starting"); - -try -{ -// use the ij utility to read the property file and -// make the initial connection. -ij.getPropertyArg(args); -con = ij.startJBMS(); - - con.setAutoCommit(false); - -stmt = con.prepareStatement("create table testRelative(name varchar(10), i int)"); - stmt.executeUpdate(); +public static void test1(Connection con) { + ResultSet rs = null; + PreparedStatement pStmt = null; + Statement stmt1 = null; + String returnValue = null; + + try + { + con.setAutoCommit(false); + pStmt = con.prepareStatement("create table testRelative(name varchar(10), i int)"); + pStmt.executeUpdate(); con.commit(); pStmt = con.prepareStatement("insert into testRelative values (?,?)"); @@ -89,7 +91,7 @@ System.out.println("Value="+returnValue); } catch(SQLException sqle) { - dumpSQLExceptions(sqle); + expectedException(sqle, NO_CURRENT_ROW_SQL_STATE); } catch(Throwable e) { System.out.println("FAIL -- unexpected exception: "+e.getMessage()); e.printStackTrace(System.out); @@ -98,28 +100,42 @@ } /** -* This is to print the expected Exception's details. We are here because we got an Exception -* when we expected one, but checking to see that we got the right one. -**/ - static private void dumpSQLExceptions (SQLException se) { - if( se.getSQLState() != null && (se.getSQLState().equals(EXPECTED_SQL_STATE))) { + * Print the expected Exception's details if the SQLException SQLState + * matches the expected SQLState. Otherwise fail + * + * @param se SQLException that was thrown by the test + * @param expectedSQLState The SQLState that we expect. + * + **/ + static private void expectedException (SQLException se, String expectedSQLState) { + if( se.getSQLState() != null && (se.getSQLState().equals(expectedSQLState))) { System.out.println("PASS -- expected exception"); while (se != null) { System.out.println("SQLSTATE("+se.getSQLState()+"): "+se.getMessage()); se = se.getNextException();
Re: Use of 3rd party libraries
I agree that reuse is a great idea. I wonder if we should consider this option for new development or when other significant changes are being made, rather than change existing mechanisms just to use common components. I think someone suggested enhancing network server scripts to use NT service mechanism sometime ago. That could be a great project to pilot some of the common frameworks. Satheesh Jeremy Boynes wrote: > David Van Couvering wrote: > >> I like code reuse rather than having to write and maintain our own >> work. That's a big pull of open source is building from what others >> have done. I vote for including the libraries in derby.jar, rather >> than having jar-file explosion. >> > > The reuse aspect is really why I want to explore this. Re-implementing > everything in Derby may be OK for simple stuff like command line > parsing but will be problematic for more complex things like JMX. > > The open community aspect should not be underestimated - a project > that refuses to even consider other open source solutions will very > rapidly become isolated. > > I would not recommend bundling things inside derby.jar as that leads > to classes being loaded from unexpected places (e.g. I would not > expect org.apache.commons.cli.Something to come from derby.jar). > >> One concern is making sure we include third-party stuff with >> compatible licensing. What is the process for making we don't get >> into some legal tangle? >> > > The ASF has strict policies on what can be used by ASF projects to > ensure that the final distribution is compatible with the Apache > License. This basically comes down to only being able to use other > software if its license is no more restrictive than the Apache License. > > -- > Jeremy > > >
Re: assigning a jira
I have added 'lancea' to derby-developer list. Also added Shreyas. You should be able to assign and close bugs now. Satheesh Lance J. Andersen wrote: > thanks, i just sent him an email. > > Regards > lance > > Andrew McIntyre wrote: > >> >> On Apr 29, 2005, at 11:44 AM, Lance J. Andersen wrote: >> >>> Perhaps it is me, but I swear i used to be able to assign myself a >>> jira. Now i cannot find a way to do this. >>> >>> Any special access needed? >> >> >> >> To assign issues to yourself, you do need to be added as a developer >> to a specific project, and I don't currently see you in the list of >> Derby developers. Satheesh has admin rights to Jira I believe, so >> send him your Jira userid and he should be able to add you to the >> project. >> >> andrew >> > > >
Re: Assigned bugs in Jira
No problem.. You can keep it. :-) I suspect Dan was making a general statement since we have seen more active developers on the list recently. One should always assign a defect they are actively working on, unassigns if they have stopped working on it for any reason. Go Derby! Satheesh Lance J. Andersen wrote: Sorry, I assumed when Mamta sent the email that it was the intent for someone to take this over. I can reassign this back to Satheesh if you like. I just assumed it was unassigned given the email was sent out. I did noticce when I assigned it that it showed Satheesh as the owner. Just let me know. Regards Lance Daniel John Debrunner wrote: Lance J. Andersen wrote: I can take this if no one else wants it. Mamta Satoor wrote: I think this is a very easy bug to fix. So, if someone is looking for an opportunity to start with a simple bug, this will be a good one. Key: DERBY-242 Assigned to: Satheesh Bandaram Just as a point of order, hopefully a Jira bug being assigned to someone means that they are actively working on it. So before trying to fix a bug it's worth checking to see if it is assigned. If you are interested in working on a bug that is assigned then you can of course offer to help out or even take over the bug completely. Dan.
Re: Question about softupgrade mode ..
I have now added you to 'derby-developer' list, as another Derby developer. Now you should be able to assign bugs and close them once done. Thanks for getting involved with Derby and tackling important enhancements. Satheesh TomohitoNakayama wrote: > > By the way, how can I assign myself to task? > I saw next url, but could not found UI to assign myself to it... > http://issues.apache.org/jira/browse/DERBY-134 > >
Re: [jira] Commented: (DERBY-203) setNull(x,JDBCType.DATE) does not work when batching is turned on
Assign the bug to yourself, to indicate you are working on it. I have added you to 'derby-developer' list now. Satheesh Shreyas Kaushik wrote: > I am planning to work on this may be this week, but definitely next > week. I did a similar fix for Blob and Timestamp. But as a part of the > patch for this I want to solve this problem not just for this specific > case but for all DataTypes where this problem could occur. > > ~ Shreyas > > Shreyas Kaushik (JIRA) wrote: > >> [ >> http://issues.apache.org/jira/browse/DERBY-203?page=comments#action_63028 >> ] >> Shreyas Kaushik commented on DERBY-203: >> --- >> >> I had fixed smilar problem with Blob and Timestamp. I will look into >> this and other types with which this problem can arise. >> >> >> >>> setNull(x,JDBCType.DATE) does not work when batching is turned on >>> - >>> >>> Key: DERBY-203 >>> URL: http://issues.apache.org/jira/browse/DERBY-203 >>> Project: Derby >>>Type: Bug >>> Components: JDBC >>>Versions: 10.0.2.1 >>> Environment: -- Java Information -- >>> Java Version:1.4.2_07 >>> Java Vendor: Sun Microsystems Inc. >>> Java home: /usr/local/java/j2sdk1.4.2_07/jre >>> Java classpath: >>> /home/oleg/prg/cs/lib/derby.jar:/home/oleg/prg/cs/lib/derbytools.jar: >>> OS name: Linux >>> OS architecture: i386 >>> OS version: 2.6.8.1-24mdk >>> Java user name: oleg >>> Java user home: /home/oleg >>> Java user dir: /usr/local/home/oleg/prg/cs/frameworks/embedded/bin >>> - Derby Information >>> [/usr/local/home/oleg/prg/cs/lib/derby.jar] 10.0.2.0 - (30301) >>> [/usr/local/home/oleg/prg/cs/lib/derbytools.jar] 10.0.2.0 - (30301) >>> -- >>> - Locale Information - >>> -- >>>Reporter: Oleg Anastasyev >>> >> >> >> >> >>> Trying to execute batch on which setNull(x,DATE) was called gives >>> the following exception: >>> SQL Exception: An attempt was made to get a data value of type >>> 'DATE' from a data value of type 'null'. >>>at >>> org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java) >>>at >>> org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java) >>>at >>> org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java) >>>at >>> org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java) >>> >>>at >>> org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(ConnectionChild.java) >>> >>>at >>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.dataTypeConversion(EmbedPreparedStatement.java) >>> >>>at >>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.setObject(EmbedPreparedStatement.java) >>> >>>at org.apache.derby.iapi.types.DataType.setInto(DataType.java) >>>at >>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeBatchElement(EmbedPreparedStatement.java) >>> >>>at >>> org.apache.derby.impl.jdbc.EmbedStatement.executeBatch(EmbedStatement.java) >>> >>>at >>> net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:54) >>> >>> DATE column is nullable in db schema, so it should pass there ok. I >>> believe the problem is in org.apache.derby.iapi.types.SQLDate, which >>> does not implement setInto method, so DataType.setInto method is >>> executed, calling setObject(x,null). setObject thinks this is JDBC >>> spec violation and fails on exception. >>> Problem exists in both 10.0.2.1 and 10.0.2.0 >>> >> >> >> >> > > >
Re: [RESULT] [VOTE] accept derby client contribution
Hi Susan, Thanks for taking this up. I am OK with your suggestion. Should it be forrest generated or posted as is? May be we could put the current version for now and then modify it later? ;-) Satheesh Susan Cline wrote: Hi Satheesh, I can get this ready for Jean to commit. I was thinking it could go under the 'Papers' tab, http://incubator.apache.org/derby/papers/index.html, and we could create a new category called 'Derby Network Client'. It wouldn't be appropriate under the 'Derby Engine' section. Or, we could have a new 'Functional Spec' category where any future Functional Spec for anything could go as well. Do either of those sound okay? If not, please suggest where you would like the functional spec to go. Susan Satheesh Bandaram <[EMAIL PROTECTED]> wrote: Submitted Derby client source to trunk. Post any problems you notice with Derby client. Enjoy! Please use the functional spec for usage. I will work with Jean to host it at Derby website. Satheesh
Re: Question about softupgrade mode ..
Since I merged your fix into trunk, I have marked it as FIXED and closed the bug. In the future, you would be able to assign and close bugs yourself. Satheesh TomohitoNakayama wrote: > > By the way, how can I assign myself to task? > I saw next url, but could not found UI to assign myself to it... > http://issues.apache.org/jira/browse/DERBY-134
Re: Can someone please assign me to Derby-205
I have added Dag and Oystein to derby-developer list. This should allow them to assign and resolve/close bugs. Do follow Jira guidelines as mentioned in Dan's message: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/[EMAIL PROTECTED] Satheesh Dag H. Wanvik wrote: Hi, Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl I volunteer to do this one, but I can't assign myself. Dag
Re: [RESULT] [VOTE] accept derby client contribution
I am OK with formatting it. If forrest option is preferred, I can look into that. I thought Jean was suggesting putting it up in HTML format? Satheesh Susan Cline wrote: > ... Okay, I'll modify the Papers tab to include a Derby Network > Client section and add a link to the functional spec which is in raw > html, unless you want to format it in forrest.xml. > ... Jean T. Anderson wrote: > Susan Cline wrote: > >> ... My feeling is whoever contributes a paper should take the >> responsibility to format it in the desired way prior to asking >> someone to update the site, just like patches need to be in a >> specific format prior to submission. >> ... > > > +1 > > That much said, volunteers with cycles/desire to improve the format of > content are always welcome -- all you need do is offer and I'm sure > you'll have many takers. > > -jean > > > >
Re: DataSource class hierarchy in client
I suspect the class hierarchy has been made this way partly to match Embedded driver. I am still thinking why the Embedded driver does this.. Satheesh Jeremy Boynes wrote: > The class hierarchy the client DataSources is: > > ClientBaseDataSource > | > +-- ClientDataSource > | > +-- ClientXADataSource > | > +-- ClientConnectionPoolDataSource > > The three standard interfaces DataSource, ConnectionPoolDataSource and > XADataSource are not related to each other with different > get??Connection methods that return different classes. > > I would like to propose refactoring this so that all three extend > ClientBaseDataSource directly which will mean moving some of the > properties from ClientDataSource down into the base class. > > Any thoughts on why this should not be done? > > -- > Jeremy > > >
Re: [RESULT] [VOTE] accept derby client contribution
I agree with Jean... Functional specs might be better off posting in HTML. I like option b) Susan Cline wrote: Hi Satheesh, Sorry if I was confusing. Submitting it in html is just fine, as per the info in the How to Contribute Papers document: http://incubator.apache.org/derby/papers/index.html#How+to+Contribute+Papers What I was trying to say is if the person who submits/contributes the original document wants it in forrest xml, it should be submitted that way initially. Or, as Jean was saying, if someone wants to volunteer to reformat stuff once it is already on the site, they could volunteer to do so. What I was volunteering to do was to update the Papers tab to point to the html document. If you do want to reformat the document into forrest.xml I can either a) hold off until you have it in forrest.xml or b) update the site now with the raw html. Please let me know what you prefer. Thanks, Susan Satheesh Bandaram <[EMAIL PROTECTED]> wrote: I am OK with formatting it. If forrest option is preferred, I can look into that. I thought Jean was suggesting putting it up in HTML format? Satheesh Susan Cline wrote: > ... Okay, I'll modify the Papers tab to include a Derby Network > Client section and add a link to the functional spec which is in raw > html, unless you want to format it in forrest.xml. > ... Jean T. Anderson wrote: > Susan Cline wrote: > >> ... My feeling is whoever contributes a paper should take the >> responsibility to format it in the desired way prior to asking >> someone to update the site, just like patches need to be in a >> specific format prior to submission. >> ... > > > +1 > > That much said, volunteers with cycles/desire to improve the format of > content are always welcome -- all you need do is offer and I'm sure > you'll have many takers. > > -jean > > > >
Re: Derby Newtork Client documentation
+1. I think we should include JCC section, for the benifit of current 10.0 users. Let me know if I can help in anyway. Satheesh Jeff Levitt wrote: >I'd like to take a shot at updating the documentation >to include the Derby Client. I've been mulling >several ways to do this, seeing as the current docs >use the IBM DB2 JCC Driver, db2jcc.jar etc. > >So do want to replace all that with information from >the Derby Client (I would plan to use the Derby Client >spec to do that). All syntax and examples would have >to be updated, but that's not too difficult. The >question is what to do with the existing information. >Do we want to create a new section, say in the Server >Admin Guide appendix, that describes using the IBM JCC >Client rather than the Derby Client for those who >still want to use it? Or should we take it out >altogether, and maybe make a separate whitepaper? > >Either way, I think possibly a whitepaper on moving >from the old client to the Derby client would be >useful as well. > >Suggestions? Concerns? > > > > >
Re: DERBY-104 (Was: Contributing to Derby, Tips and Tasks To Get You Started)
You should have access now. Derby has 26 members in 'derby-developer' alias... one of the highest. Satheesh >I'll volunteer for this one. Could somebody assign it to me (or give >me access to aaign myself)? > >
Re: [PATCH]Derby-229
Thanks for the patch. Couple of comments: New test caseInsensitiveColumn is not part of any testsuite. So, the test will not get run. You would need to add this to an existing suite. Also, you should consider enhancing an existing test script when adding a new test, rather than creating a new test everytime. This increases number of tests in a suite, taking it longer to run them. Instead, updating an existing test is better. The patch needs to be generated from the trunk directory, so your directory path wouldn't show in the patch. (/drivers/derby/trunk) Satheesh Shreyas Kaushik wrote: Hi, This is the latest patch. I have taken care of comments from Mamta and Dan. Please let me know if I have missed anything. ~ Shreyas Index: /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/master/caseInsensitiveColumn.out === --- /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/master/caseInsensitiveColumn.out (revision 0) +++ /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/master/caseInsensitiveColumn.out (revision 0) @@ -0,0 +1,9 @@ +Test caseInsensitiveColumn starting +Before updation... +ResultSet is: 1 +ResultSet is: 346 +After update... +Column Number 1: 900 +Column Number 2: 346 +Col COL1: 900 +Col col1: 900 Index: java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java === --- java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java (revision 165091) +++ java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java (working copy) @@ -3591,8 +3591,14 @@ ResultDescription rd = resultDescription; // 1 or 0 based? assume 1 (probably wrong) - for (int i=rd.getColumnCount(); i>=1; i--) { +// Changing the order in which columns are found from 1 till column count. +// This is necessary in cases where the column names are the same but are in different cases. +// This is because in updateXXX and getXXX methods column names are case insensitive +// and in that case the first column should be returned. + +int columnCount = rd.getColumnCount(); +for(int i = 1 ; i<= columnCount;i++) { String name = rd.getColumnDescriptor(i).getName(); if (StringUtil.SQLEqualsIgnoreCase(columnName, name)) { return i; Index: /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/caseInsensitiveColumn.java === --- /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/caseInsensitiveColumn.java (revision 0) +++ /drivers/derby/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/caseInsensitiveColumn.java (revision 0) @@ -0,0 +1,97 @@ +package org.apache.derbyTesting.functionTests.tests.jdbcapi; + + +import java.sql.*; + +import org.apache.derby.tools.ij; +import org.apache.derby.tools.JDBCDisplayUtil; + +public class caseInsensitiveColumn { + +public static void main(String[] args) { +test1(args); +} + +public static void test1(String []args) { +Connection con; +ResultSet rs; +Statement stmt = null; +PreparedStatement stmt1 = null; + +System.out.println("Test caseInsensitiveColumn starting"); + +try +{ +// use the ij utility to read the property file and +// make the initial connection. +ij.getPropertyArg(args); +con = ij.startJBMS(); + + con.setAutoCommit(false); + +stmt = con.createStatement(); + + // create a table with two columns, their names differ in they being in different cases. +stmt.executeUpdate("create table caseiscol(COL1 int ,\"col1\" int)"); + + con.commit(); + + stmt.executeUpdate("insert into caseiscol values (1,346)"); + + con.commit(); + +// select data from this table for updating + stmt1 = con.prepareStatement("select COL1, \"col1\" from caseiscol FOR UPDATE",ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE); + rs = stmt1.executeQuery(); + + // Get the data and disply it before updating. +System.out.println("Before updation..."); + while(rs.next()) { + System.out.println("ResultSet is: "+rs.getObject(1)); + System.out.println("ResultSet is: "+rs.getObject(2)); + } +rs.close(); + rs = stmt1.executeQuery(); + while(rs.next()) { + // Update the two columns with different data. + // Since update is case insensitive only the first column should get updated in both cases. + rs.updateInt("col1",100
Re: Schedule for beta and release of 10.1
One month seems like a good amount time to figure out some of these, at least just to formulate a plan. I am eager to see Derby client get rigorous testing that precedes a full release and to get it to derby users. I am concerned about potential resource leakage, platform specific, multi-threading issues that may or may not be present. These issues are typically found and addressed during a full release process. I also think current dependence on JCC client driver in 10.0 hinders wider adaptability of Derby. You do raise some touch questions. :-) Like you suggested, we can work on getting a plan in place for these soon. Satheesh > I think aiming for a release in a month or so would be good. > > However, I do not want to rush out the first version of the client as > that will suddenly give us a legacy codebase. We have only just seen > this code and there are a couple of areas that we should consider: > > * which JREs will it run on > * do we need JSR-169 support > * what are the plans for SSL transport, including client auth > * what do we do with Referenceable > * what are our plans for connector support > * do we have the right properties > * do we change the commmand line processing for NetworkServer > > and probably a few more things as well. We don't need to resolve all > of these but at least figure out what the plan is. > > -- > Jeremy > > >
Re: [jira] Created: (DERBY-242) DatabaseMetaData.supportsGetGeneratedKeys needs to return FALSE, since Derby only has limited support.
Committed this patch. I also searched for all references to supportsGetGeneratedKeys() in the test & master files. This was the only reference. Lance, can you RESOLVE the Jira entry and then CLOSE it, please? Satheesh r168176 | bandaram | 2005-05-04 12:50:21 -0700 (Wed, 04 May 2005) | 3 lines Derby-242: Make DatabaseMetadata.supportsMultipleOpenResults() return FALSE. Submitted by Lance Anderson. ([EMAIL PROTECTED]) Lance J. Andersen wrote: Hi Mamta, The only test I saw and ran was DBMetaDataJdbc30 when I searched the codeline. (You saw my notes on my other failures in jdk14 test run, but this one passed) I also noticed that the other drivers were already set to false. Regards Lance Mamta Satoor wrote: Hi Lance, I looked at the review package and it looks good. Good comments in the EmbedDatabaseMetaData.java. Just wondered if you ran the existing tests to make sure nothing got affected by the change. Mamta On 5/4/05, Lance J. Andersen <[EMAIL PROTECTED]> wrote: Oh, I forgot to mention that i validated that the dbMetaDataJdbc30 in jdk14 passed. Lance Andersen wrote: Attached is the patch. Regards Lance Mamta Satoor wrote: Hi Lance, Thanks for taking it. Yes, it is for Embedded Driver. Mamta On 4/29/05, Lance J. Andersen <[EMAIL PROTECTED]> wrote: I take it this is with the Embedded Driver as it looks like the code for the new Client Driver is returning false. I can take this if no one else wants it. Mamta Satoor wrote: Hi, I think this is a very easy bug to fix. So, if someone is looking for an opportunity to start with a simple bug, this will be a good one. Mamta On 4/26/05, Satheesh Bandaram (JIRA) wrote: DatabaseMetaData.supportsGetGeneratedKeys needs to return FALSE, since Derby only has limited support. -- Key: DERBY-242 URL: http://issues.apache.org/jira/browse/DERBY-242 Project: Derby Type: Bug Components: JDBC Versions: 10.0.2.0 Environment: ALL Reporter: Satheesh Bandaram Assigned to: Satheesh Bandaram Fix For: 10.1.0.0 Derby only has partial support for retrieving generated values. Because of this, it is desirable to make DatabaseMetaData.supportsGetGeneratedKeys return FALSE. One of the restrictions include Jira entry Derby-201. Till this is fixed, we should change derby to return FALSE for this. This would also match Derby client behavior. -- 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 Index: java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java === --- java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java (revision 168122) +++ java/engine/org/apache/derby/impl/jdbc/EmbedDatabaseMetaData.java (working copy) @@ -2880,7 +2880,13 @@ */ public boolean supportsGetGeneratedKeys() { - return true; + /* + * Currently reverting the returned value to false until there + * is more support for autogenerated keys in Derby. + * (such as support for specifying the returned columns for + * the autogenerated key) + */ + return false; } /** Index: java/testing/org/apache/derbyTesting/functionTests/master/dbMetaDataJdbc30.out === --- java/testing/org/apache/derbyTesting/functionTests/master/dbMetaDataJdbc30.out (revision 168122) +++ java/testing/org/apache/derbyTesting/functionTests/master/dbMetaDataJdbc30.out (working copy) @@ -4,7 +4,7 @@ supportsSavepoints() : true supportsNamedParameters() : false supportsMultipleOpenResults() : true -supportsGetGeneratedKeys() : true +supportsGetGeneratedKeys() : false supportsResultSetHoldability(HOLD_CURSORS_OVER_COMMIT) : true supportsResultSetHoldability(CLOSE_CURSORS_AT_COMMIT) : true getJDBCMajorVersion() : 3 >
Re: [PATCH] Jira-189 ResultSetMetaData.getSchemaName and ResultSetMetaData.isWritable donot return correct values
I am getting ready to submit this patch. Satheesh Mamta Satoor wrote: Hi David, I have attached a new patch to take care of the comments from your review. 1)Good catch about impl.sql.compile.ResultColumnList.getResultColumnThroughExpression(). It is left over code from another solution I was trying to fix the problem. I have taken it out of the review package attached to this mail. 2)The change in ResultColumnDescriptor.java for getSourceSchemaName is for clarity and consistency reasons (similar to getSourceTableName). With this change, EmbedResultSetMetaData now calls getSourceXXXName for getTableName and getSchemaName. Similarly, in GenericColumnDescriptor(which implements ResultColumnDescriptor), we have getSourceXXXName to keep the source table and source schema name. 3)I have reformatted code and comments to not exceed 80 characters. Also, changed the comments for method commonCodeForUpdateableBySql from .. to /** and */ thanks, Mamta On 5/2/05, David Van Couvering <[EMAIL PROTECTED]> wrote: Hi, Mamta, this looks good. It built, and I ran as many tests as I could before I had to leave for the day. My God, those tests take a long time to run. But that's a topic for a separate discussion :) Here are my comments and questions... - What you have looks good and makes sense, but I don't know the code well enough to know if you're missing something. I guess the tests help guarantee that, but someone more familiar with the code taking a look would be great. - I was curious how impl.sql.compile.ResultColumnList.getResultColumnThroughExpression() was used. In NetBeans I searched for all usages of it and could find none. To double-check, I did a full search of the codeline and only found it where it is defined, and no uses. Is there a reason to have this method if nothing uses it? - in ResultColumnDescriptor.java, why did you change the method from getSchemaName() to getSourceSchemaName()? Is this just to make it more clear what the method is doing? - A lot of your comments and code seem to far exceed 80 characters in length per line. This makes it hard to read in diff output and text-based editors, and it requires scrolling in IDEs. Could you please limit your source lines to 80 characters? - The method commonCodeForUpdateableBySql in ResultColumnList.java should have comments with /** and */ rather than // It took me a while in 'vi' to determine this was a new method, to the eye it looks like a continuation of the previous method. David Mamta Satoor wrote: Hi, I am sorry if I sound like a broken record, but please, will someone review this? And if no concerns from anyone, will a commiter commit it? thanks, Mamta On 4/27/05, Mamta Satoor <[EMAIL PROTECTED]> wrote: Hi, I wondered if anyone got a chance to review this patch? thanks, Mamta On 4/24/05, Mamta Satoor <[EMAIL PROTECTED]> wrote: Hi Dan, I have a new patch for this bug which also fixes the problem you brought up with sql select * from a.t as X. The fix for this required change in impl.sql.compile.FromBaseTable's method genResultColList(). I changed the code such that we set the TableDescriptor on the ColumnDescriptor instance. This TableDescriptor is later used by ResultColumn.getTableName to get the base table name of the column. In addition to that, I changed ColumnReference.getSourceTableName and ColumnReference.getSourceSchemaName so that they don't look at the user supplied correlation name (if any) to fetch the base table/schema name. I have also added some test cases for the code changes above in jdbcapi/resultset.java Other than this, the rest of the patch stays the same as what you tried applying last week. I have run the tests and there is no new failure because of my changes. svn stat output M java\engine\org\apache\derby\impl\sql\compile\ResultColumn.java M java\engine\org\apache\derby\impl\sql\compile\VirtualColumnNode.java M java\engine\org\apache\derby\impl\sql\compile\CursorNode.java M java\engine\org\apache\derby\impl\sql\compile\FromBaseTable.java M java\engine\org\apache\derby\impl\sql\compile\BaseColumnNode.java M java\engine\org\apache\derby\impl\sql\compile\ColumnReference.java M java\engine\org\apache\derby\impl\sql\compile\ValueNode.java M java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java M java\engine\org\apache\derby\impl\sql\GenericColumnDescriptor.java M java\engine\org\apache\derby\impl\jdbc\EmbedResultSet.java M java\engine\org\apache\derby\impl\jdbc\EmbedResultSetMetaData.java M java\engine\org\apache\derby\iapi\sql\dictionary\ColumnDescriptor.java M java\engine\org\apache\derby\iapi\sql\ResultColumnDescriptor.java M java\testing\org\apache\derbyTesting\functionTests\tests\lang\updatableResultSet.java M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\resultset.java M java\testing\org\apa
Derby-12 and Derby-13 ...
Shreyas, since you worked on both these bugs, can close them after confirming they are indeed fixed and we have a test case for both in our testsuites? Since you can close bugs, it is best if you take action. Satheesh
Does anyone know about Derby-179?
I was briefly looking at Derby-179. The bug started describing a problem that is actually unsupported syntax on Derby. Then there were couple of notes indicating current problem with Hibernate and Derby integration is Derby-127. Jack seems to be working on Derby-127, so I was wondering if Derby-127 is addressed how can we test Derby-179? I was looking at Derby-179 since it seems to have highest priority and Hibernate integration would be good for Derby as well. Satheesh
Re: DERBY-167 has done but ...
(B (B (B (BGreat job getting this done. This is indeed a very useful Enhancement (Bto Derby. (B (BLooking briefly at the attached patch, some comments: (B (B I think syntax for GENERATED BY DEFAULT needs to include the BY, (Baccording to SQL standard. (B One of the main uses of this new clause is for importing data (Binto IDENTITY columns. I would like to see some tests that import data (Binto tables created with the new identity option. Import code actually (Buses bulkInsert option, so it would be good to test this code path too. (BI can help, if needed, on these tests. Before commiting the patch, it (Bwould be good to add more tests in general. (B I couldn't fully apply the patch. Had issues with two files, (BResultColumnList and ColumnDescriptor. I think these files might have (Bbeen updated since you started working on the patch. It would be good (Bif you can merge up to the latest version. (B (B (BAgain, great to see the patch. (B (BSatheesh (B (BTomohitoNakayama wrote: (BHello. (B (B (BI think coding for solution-1 of DERBY-167 has done. (B (BI attach patch file to this mail for others to confirm it. (B (B (BRelating test , autoincrement and columnDefaults , was passed. (B (B (B (BHowever, In derbyall test , I found many errors which seems not caused (Bby my modification. (B (BErrors seems to be devided three kind ... (B (B1:Error of parameterMapping. I don't know what is parameter Mapping (Bmean, (B (Bbut file names told so. (B (B2:Error of i18n. It seems that English message was generated though (Btest assume Spanish. (B (B3:Error of derbynetclientmats. (B (B (BI uploaded $TEST_DIR/derbyall_fail.txt and $TEST_DIR/derbyall_diff.txt (Bto my web directory, (B (Bbecause size was too large. (B (Bhttp://www5.ocn.ne.jp/~tomohito/20050505/derbyall_fail.txt (B (Bhttp://www5.ocn.ne.jp/~tomohito/20050505/derbyall_diff.txt (B (B (BSomething is going on ...? (B (B (B (BBest regards. (B (B (B (B/* (B (B (B Tomohito Nakayama (B (B [EMAIL PROTECTED] (B (B [EMAIL PROTECTED] (B (B (B Naka (B (B http://www5.ocn.ne.jp/~tomohito/TopPage.html (B (B (B*/ (B (B (BNo virus found in this outgoing message. (BChecked by AVG Anti-Virus. (BVersion: 7.0.308 / Virus Database: 266.11.5 - Release Date: 2005/05/04 (B (B (B (B
Re: DataSource class hierarchy in client
I think the ClientBaseDataSource was not meant to be a public class. We tried to localize all public classes into the 'jdbc' package and use only the jdbc package to generate public javadoc. That is one of the reasons for putting all public tracing support in ClientDataSource. I would also like to match API with Embedded driver as much as possible. It would be real bad if applications need changes when using two different driver offerings of Derby. Your suggestions probably don't break this, but something to watch for. We tried to match Embedded behavior, unless it was deemed WRONG. Satheesh Jeremy Boynes wrote: > Satheesh Bandaram wrote: > >> I suspect the class hierarchy has been made this way partly to match >> Embedded driver. I am still thinking why the Embedded driver does this.. >> > > I don't know if it is relevant but most of the implementation in the > client code uses ClientDataSource instances rather than the base class > - in fact, the base class itself is never really used at all. I have a > feeling there is some legacy leftover here. > > I am going to go through the client code and switch the usages to the > base class (which declares the methods being used) and then change the > hierarchy here as proposed. > > -- > Jeremy > > >
Re: [jira] Assigned: (DERBY-263) Remove IJ support for setting unicodeescape option.
Hi Lance, You are fast... I have a patch ready already, so if you don't mind, I will submit it? Satheesh Lance Andersen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-263?page=all ] Lance Andersen reassigned DERBY-263: Assign To: Lance Andersen Remove IJ support for setting unicodeescape option. --- Key: DERBY-263 URL: http://issues.apache.org/jira/browse/DERBY-263 Project: Derby Type: Sub-task Components: Tools Versions: 10.1.0.0 Reporter: Satheesh Bandaram Assignee: Lance Andersen Priority: Minor Derby doesn't support setting unicodeescape option in IJ. Need to remove the option from IJ, in addition to removing the documentation.
Re: Patch for Derby-263 ...
Hi Lance, Thanks for the review. I think ijConstants.java is a generated file... Once we submit ij.jj change, new versions of this generated file should not have references to UNICODEESCAPE. Satheesh I have committed this patch: Sending java\testing\org\apache\derbyTesting\functionTests\master\UnicodeEscape_JP.out Sending java\testing\org\apache\derbyTesting\functionTests\master\ij.out Sending java\testing\org\apache\derbyTesting\functionTests\master\j9_13\ij.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\i18n\UnicodeEscape_JP.sql Sending java\tools\org\apache\derby\impl\tools\ij\Main.java Sending java\tools\org\apache\derby\impl\tools\ij\ij.jj Sending java\tools\org\apache\derby\loc\toolsmessages.properties Sending java\tools\org\apache\derby\loc\toolsmessages_de_DE.properties Sending java\tools\org\apache\derby\loc\toolsmessages_es.properties Sending java\tools\org\apache\derby\loc\toolsmessages_fr.properties Sending java\tools\org\apache\derby\loc\toolsmessages_it.properties Sending java\tools\org\apache\derby\loc\toolsmessages_ja_JP.properties Sending java\tools\org\apache\derby\loc\toolsmessages_ko_KR.properties Sending java\tools\org\apache\derby\loc\toolsmessages_pt_BR.properties Sending java\tools\org\apache\derby\loc\toolsmessages_zh_CN.properties Sending java\tools\org\apache\derby\loc\toolsmessages_zh_TW.properties Transmitting file data Committed revision 169502. Lance J. Andersen wrote: Hi Satheesh, This looks good. I noticed that ijConstants.java also has references to unicodeescape, should these be removed as part of this patch? Regards, lance Satheesh Bandaram wrote: Simple patch to remove UNICODEESCAPE option in IJ. Satheesh Index: java/tools/org/apache/derby/impl/tools/ij/ij.jj === --- java/tools/org/apache/derby/impl/tools/ij/ij.jj (revision 168631) +++ java/tools/org/apache/derby/impl/tools/ij/ij.jj (working copy) @@ -610,7 +610,6 @@ | | | -| | | | @@ -973,7 +972,6 @@ | r=RunStatement() | r=SetConnectionStatement() | r=ShowConnectionsStatement() -| r=UnicodeEscape() | r=WaitForStatement() | r=XA_DataSourceStatement() | r=XA_ConnectStatement() @@ -2146,28 +2144,6 @@ } /** - * Unicodeescape controls ASCII Unicode escape processing - * - * Syntax: - * UNICODEESCAPE [ ON | OFF ] ; - */ -ijResult UnicodeEscape() -: -{ - Token on=null; -} -{ - - ( on= - | - ) - { - LocalizedResource.setUnicodeEscape((on==null?false:true)); - return null; - } -} - -/** * ReadOnly lets you control this aspect of the connection. * REMIND: should have a general way to set all connection attributes, * this is a shortcut for immediate needs. @@ -3128,7 +3104,6 @@ | tok = | tok = | tok = -| tok = | tok = | tok = | tok = Index: java/tools/org/apache/derby/impl/tools/ij/Main.java === --- java/tools/org/apache/derby/impl/tools/ij/Main.java (revision 168631) +++ java/tools/org/apache/derby/impl/tools/ij/Main.java (working copy) @@ -85,7 +85,6 @@ String inputResourceName; boolean gotProp; - String tmpUnicode = null; Properties connAttributeDefaults = null; // load the property file if specified @@ -133,11 +132,6 @@ } } - // set initial Unicode Escape Mode - tmpUnicode = util.getSystemProperty("ij.unicodeEscape"); - if ((tmpUnicode != null) && tmpUnicode.toUpperCase(Locale.ENGLISH).equals("ON")) { - LocalizedResource.setUnicodeEscape(true); - } String outFile = util.getSystemProperty("ij.outfile"); if (outFile != null && outFile.length()>0) { LocalizedOutput oldOut = out; Index: java/tools/org/apache/derby/loc/toolsmessages_it.properties === --- java/tools/org/apache/derby/loc/toolsmessages_it.properties (revision 168631) +++ java/tools/org/apache/derby/loc/toolsmessages_it.properties (working copy) @@ -90,7 +90,6 @@ \ GETCURRENTROWNUMBER name;-- restituisce il numero di righe per la posizione corrente del cursore di scorrimento denominato\n\ \ -- (quando il cursore non \u00e8 posizionato su una riga viene restituito 0.) \n\ \ CLOSE name; -- chiude il cursore denominato\n\ -\ UNICODEESCAPE [ ON | OFF ]; -- imposta la modalit\u00e0 unicode escape per il flusso di input\n\ \ LOCALIZEDDISPLAY [ ON | OFF ];\n\ \ -- controlla la rappresentazione dei dati sensibile alle impostazioni internazionali\n\ \ \n\ Index: java/tools/org/apache/derby/loc/toolsmessages.properties === --- java/tools/org/apache/derby/loc/toolsmessages.properties (rev
Re: Info of what fixes go into 10.1 release ?
Hi Bernd, Sorry, I promised to help complete this patch, but haven't been providing much of a help. The patch as attached is not complete. As Jack pointed out, we do need to raise error when there is an ORDER BY on a correlation name that is ambiguous. For example, > select i as a, j as a from t A A --- --- 1 1 2 2 0 4 3 record(s) selected. > select i as a, j as a from t order by a <== Needs to raise error, as order by a could be refering to i or j But > select i, i, i from t order by i <=== This is OK, since all references to i point to same base column. Do you have time and interest to adjust the patch? We still have time to submit this change to 10.1 release. There is active discussion on when that release might happen. Satheesh Bernd Ruehlicke wrote: Hi there, I added a patch to http://issues.apache.org/jira/browse/DERBY-147 a while ago. I just want to know how I can figure out if this is making it into the next release. Do we have a site where we list what is going into the 10.1 release ? Thanx B-) - I use Derby because I'm worth it
Re: [jira] Created: (DERBY-251) DISTINCT query is returning duplicate rows
It seems the patch is not built on latest codebase, so I couldn't apply this patch. Would it be possible to send updated patch based on latest code? I looked at the patch anyway and wonder if we are only fixing a narrow case where we are applying DISTINCT elimination logic incorrectly. I suspect there may be a few more related cases that the fix might be missing, but this could be just my not understanding the patch yet. :-) I will look at this again once updated patch is available. Satheesh Mamta Satoor wrote: Hi, I have a patch for this optimizer bug. Basically, the issue turned out to be the logic for DISTINCT elimination. During the optimization phase, if a query has DISTINCT clause, then impl.sql.compile.FromList class's returnsAtMostSingleRow() method gets called. This method returns true if the method concludes that DISTINCT in the query is redundant (based on a complex logic that decides that the query is going to return distinct rows on its own without the DISTINCT clause. The details of the current logic for DISTINCT elimination can be found in the comments at the method level.) For the query in question in this bug, the method returned true for DISTINCT elimination which is wrong. The explanation is as follows. First of all, I was able to simplify the query reported in the bug to following query. select distinct q1."NO1" from IDEPT q1, IDEPT q2 where ( q2."DISCRIM_DEPT" = 'HardwareDept') and ( q1."DISCRIM_DEPT" = 'SoftwareDept') and ( q1."NO1" <> ALL (select q3."NO1" from IDEPT q3 where (q3."REPORTTO_NO" = q2."NO1"))) This query gets converted to following during optimization select distinct q1."NO1" from IDEPT q1, IDEPT q2 where ( q2."DISCRIM_DEPT" = 'HardwareDept') and ( q1."DISCRIM_DEPT" = 'SoftwareDept') and not exists ( (select q3."NO1" from IDEPT q3 where ( q3."REPORTTO_NO" = q2."NO1" and q3."NO1" = q1."NO1") ) ) ; This optimized query has 4 predicates associated with it q3.reportto_no = q2.no1 q2.discrim_dept = 'HardwareDept' q1.descrim_dept = 'SoftwareDept' q1.no1 = q3.no1 Next, on this optimized query(since it has DISTINCT clause in it), the returnsAtMostSingleRow() method gets called. The method incorrectly returns true indicating that DISTINCT can be eliminated. The reason for this is that method is looking at predicates that belong to the inside query with the exists clause (which is on table IDEPT q3) to determine DISTINCT elimination for the outer level. The fix is that the predicates from the exists query, (in this particular case, q3."NO1" = q1."NO1" and q3.reportto_no = q2.no1) should not be considered when deciding elimination of DISTINCT in the outer query. That is what the attached patch does. Hope this helps understand the problem and the proposed fix for it. The files impacted by the change are as follows svn stat M java\engine\org\apache\derby\impl\sql\compile\FromList.java M java\testing\org\apache\derbyTesting\functionTests\tests\lang\distinctElimination.sql M java\testing\org\apache\derbyTesting\functionTests\master\distinctElimination.out Please send in comments you may have. I have run the existing tests and the patch didn't cause any failures. thanks, Mamta On 4/29/05, Mamta A. Satoor (JIRA) wrote: DISTINCT query is returning duplicate rows -- Key: DERBY-251 URL: http://issues.apache.org/jira/browse/DERBY-251 Project: Derby Type: Bug Components: SQL Versions: 10.1.0.0 Reporter: Mamta A. Satoor Assigned to: Mamta A. Satoor Following query on a table with primary key returns duplicate rows select distinct q1."NO1" from IDEPT q1, IDEPT q2 where ( q2."DISCRIM_DEPT" = 'HardwareDept') and ( q1."DISCRIM_DEPT" = 'SoftwareDept') and ( q1."NO1" <> ALL ( select q3."NO1" from IDEPT q3 where ( q3."REPORTTO_NO" = q2."NO1") ) ) ; The sql script to create the table and load data into it is as follows CREATE TABLE "APP"."IDEPT" ("DISCRIM_DEPT" VARCHAR(32), "NO1" INTEGER NOT NULL, "NAME" VARCHAR(50), "AUDITOR_NO" INTEGER, "REPORTTO_NO" INTEGER, "HARDWAREASSET" VARCHAR(15), "SOFTWAREASSET" VARCHAR(15)); -- primary/unique ALTER TABLE "APP"."IDEPT" ADD CONSTRAINT "PK_IDEPT" PRIMARY KEY ("NO1"); insert into idept values ('Dept', 1, 'Department1', null, null, null, null); insert into idept values ('HardwareDept', 2, 'Department2', 25, 1, 'hardwareaset2', null); insert into idept values ('HardwareDept', 3, 'Department3', 25, 2, 'hardwareaset3', null); insert into idept values ('SoftwareDept', 4, 'Department4', 25, 1, null, 'softwareasset4'); insert into idept values ('SoftwareDept', 5, 'Department5', 30, 4, null, 'softwareasset5'); The problem appears to be in org.apache.derby.impl.sql.compile.FromList.returnsAtMostSingleRow() method. This method along with other things tries to determine if the DISTINCT can be dropped without causing duplicate rows. For the query in question, this method decides that DISTINCT is not necessary which I think is in
Re: Derby 270 (need to be added to the JIRA derby devs group
You should know have the karma now to assign and close issues. Satheesh Jeff Levitt wrote: >I created Derby-270, but then realized that the change >I was goign to make for it is not needed. However, I >can't close my own JIRA issue. I think I need to be >in the derby dev group in Jira. Can my id be added to >that group? My id is jlevitt. > >Thanks! > > > > >
Re: [PATCH] (DERBY-251) DISTINCT query is returning duplicate rows
Submitted this patch. Thanks for addressing the review comments quickly. Satheesh Sending java\engine\org\apache\derby\impl\sql\compile\FromList.java Sending java\testing\org\apache\derbyTesting\functionTests\master\distinctElimination.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\distinctElimination.sql Transmitting file data ... Committed revision 169735. Mamta Satoor wrote: Hi Jack, Appreciate you taking the time to do the review and catching the predicate with _expression_. I have changed the code and also added a test case for it. I have fired the derbyall suite on my codeline to make sure everything else runs smoothly. Attached is the updated patch anyways. thanks, Mamta On 5/11/05, Jack Klebanoff <[EMAIL PROTECTED]> wrote: The patch does not completely fix the problem. It does not handle the case where the exists table column is embedded in an _expression_. Try the following variation on the test select: select distinct q1."NO1" from IDEPT q1, IDEPT q2 where ( q2."DISCRIM_DEPT" = 'HardwareDept') and ( q1."DISCRIM_DEPT" = 'SoftwareDept') and ( q1."NO1" <> ALL (select q3."NO1" from IDEPT q3 where ( ABS(q3."REPORTTO_NO") = q2."NO1"))) Because q3."REPORTTO_NO" is inside a call to ABS the code added to FromList.returnsAtMostSingleRow does not see it. I would suggest using JBitSet referencedTables = and.getLeftOperand().getTablesReferenced(); if( referencedTables.get( existsTableNumber)) { predicatesTemp.removeElementAt(predicatesTempIndex); break; } instead of BinaryRelationalOperatorNode beon = (BinaryRelationalOperatorNode) and.getLeftOperand(); ValueNode left = beon.getLeftOperand(); ValueNode right = beon.getRightOperand(); /* If left or right side of predicate refer to exists base table, then remove it */ if ((left instanceof ColumnReference) && ((ColumnReference) left).getTableNumber() == existsTableNumber) { predicatesTemp.removeElementAt(predicatesTempIndex); break; } else if ((right instanceof ColumnReference) && ((ColumnReference) right).getTableNumber() == existsTableNumber) { predicatesTemp.removeElementAt(predicatesTempIndex); break; } I have tried it out and it seems to work. Jack Klebanoff Mamta Satoor wrote: Hi, I have a patch for this optimizer bug. Basically, the issue turned out to be the logic for DISTINCT elimination. During the optimization phase, if a query has DISTINCT clause, then impl.sql.compile.FromList class's returnsAtMostSingleRow() method gets called. This method returns true if the method concludes that DISTINCT in the query is redundant (based on a complex logic that decides that the query is going to return distinct rows on its own without the DISTINCT clause. The details of the current logic for DISTINCT elimination can be found in the comments at the method level.) For the query in question in this bug, the method returned true for DISTINCT elimination which is wrong. The explanation is as follows. First of all, I was able to simplify the query reported in the bug to following query. select distinct q1."NO1" from IDEPT q1, IDEPT q2 where ( q2."DISCRIM_DEPT" = 'HardwareDept') and ( q1."DISCRIM_DEPT" = 'SoftwareDept') and ( q1."NO1" <> ALL (select q3."NO1" from IDEPT q3 where (q3."REPORTTO_NO" = q2."NO1"))) This query gets converted to following during optimization select distinct q1."NO1" from IDEPT q1, IDEPT q2 where ( q2."DISCRIM_DEPT" = 'HardwareDept') and ( q1."DISCRIM_DEPT" = 'SoftwareDept') and not exists ( (select q3."NO1" from IDEPT q3 where ( q3."REPORTTO_NO" = q2."NO1" and q3."NO1" = q1."NO1") ) ) ; This optimized query has 4 predicates associated with it q3.reportto_no = q2.no1 q2.discrim_dept = 'HardwareDept' q1.descrim_dept = 'SoftwareDept' q1.no1 = q3.no1 Next, on this optimized query(since it has DISTINCT clause in it), the returnsAtMostSingleRow() method gets called. The method incorrectly returns true indicating that DISTINCT can be eliminated. The reason for this is that method is looking at predicates that belong to the inside query with the exists clause (which is on table IDEPT q3) to determine DISTINCT elimination for the outer level. The fix is that the predicates from the exists query, (in this particular case, q3."NO1" = q1."NO1" and q3.reportto_no = q2.no1) should not be considered when deciding elimination of DISTINCT in the outer query. That is what the attached patch does. Hope this helps understand the prob
Re: "-Dframework=DerbyNetClient"? (Re: BulkInsert ? (Re: DERBY-167 has done but ...))
; Well .. I'm not sure default command option "-Dframework=DerbyNet" > generated by RunSuite > > Best regards. > > /* > > Tomohito Nakayama > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > Naka > http://www5.ocn.ne.jp/~tomohito/TopPage.html > > */ > - Original Message - > From: "TomohitoNakayama" <[EMAIL PROTECTED]> > To: "Derby Development" > Sent: Tuesday, May 10, 2005 8:37 PM > Subject: Re: BulkInsert ? (Re: DERBY-167 has done but ...) > > >> Hello. >> >> I see. >> I understood bulk insert. >> Thank you. >> Now, I have just tryed derbyall-test problem and there seems to be >> trouble in derbynet/DerbyNetAutoStart.. >> >> I will report it in detail later. >> >> Best regards. >> /* >> >> Tomohito Nakayama >> [EMAIL PROTECTED] >> [EMAIL PROTECTED] >> >> Naka >> http://www5.ocn.ne.jp/~tomohito/TopPage.html >> >> */ >> - Original Message - >> From: "Kathey Marsden" <[EMAIL PROTECTED]> >> To: "Derby Development" >> Sent: Tuesday, May 10, 2005 5:02 AM >> Subject: Re: BulkInsert ? (Re: DERBY-167 has done but ...) >> >> >>> Satheesh Bandaram wrote: >>> >>>> BulkInsert is an internal mechanism, that gets used when you import >>>> data into a table, using Derby's import mechanism. >>>> (SYSCS_UTIL.SYSCS_IMPORT_TABLE >>>> ) This is not directly >>>> exposed to applications using JDBC or SQL, so there is no way to >>>> directly invoke it. If you write some test cases for your feature >>>> using this procedure, you are testing bulkInsert code. Are you >>>> familiar with importing/exporting tables? Looking at Derby manuals >>>> for >>>> information would be very useful. >>> >>> I think you could add a test to tools/ieptests.sql >>> which tests loading a table with an identity column. >>> >>> Kathey >>> >>> >>> >>> >>> >>> -- >>> No virus found in this incoming message. >>> Checked by AVG Anti-Virus. >>> Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 2005/05/06 >>> >> >> >> -- >> No virus found in this outgoing message. >> Checked by AVG Anti-Virus. >> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 2005/05/09 >> >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Anti-Virus. >> Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 2005/05/09 >> >> > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 2005/05/09 > > > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 2005/05/09 > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.7 - Release Date: 2005/05/09
Re: [PATCH] Derby-127
Commited this patch. Sending java\engine\org\apache\derby\impl\sql\compile\OrderByColumn.java Sending java\engine\org\apache\derby\impl\sql\compile\ResultColumnList.java Sending java\engine\org\apache\derby\impl\sql\compile\TableName.java Sending java\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj Sending java\testing\org\apache\derbyTesting\functionTests\master\orderby.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\orderby.sql Transmitting file data .. Committed revision 169744. Jack Klebanoff wrote: I have attached a patch that fixes Jira bug Derby-127 (http://issues.apache.org/jira/browse/DERBY-127). The problem is with select statements that use a correlation name in the select list, a group by clause, and an order by clause that refers to a column by its database name instead of its correlation name. e.g. select c1 as x from t where ... group by x order by c1 Derby throws an exception with SQLState 42x04 complaining that it cannot resolve "c1". The underlying problem is that the Derby parser transforms the select into a query tree for the following statement: select * from (select c1 as x from t where ...) order by c1 The code in class OrderByColumn did not take this into account. I changed methods pullUpOrderByColumn and bindOrderByColumn to handle this case specially. pullUpOrderByColumn adds the sort key to the ResultColumnList if it cannot find it there. It is called before binding and before select list wildcards ("*") are expanded. I changed it to pull the sort key into the ResultColumnList of the subselect generated to handle GROUP BY. I also changed it to remember where it was added. This simplifies the bindOrderByColumn, which is called after pullUpOrderByColumn. I also fixed the handling of table names in class OrderByColumn. It treated them as strings, which does not work when the schema or table name is a quoted string containing a period. I changed OrderByColumn to use class TableName to represent a table name. The ResultColumnList.getOrderByColumn methods where changed accordingly Jack Klebanoff. Index: java/engine/org/apache/derby/impl/sql/compile/TableName.java === --- java/engine/org/apache/derby/impl/sql/compile/TableName.java (revision 168148) +++ java/engine/org/apache/derby/impl/sql/compile/TableName.java (working copy) @@ -206,6 +206,9 @@ */ public boolean equals(TableName otherTableName) { +if( otherTableName == null) +return false; + String fullTableName = getFullTableName(); if (fullTableName == null) { Index: java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj === --- java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj (revision 168148) +++ java/engine/org/apache/derby/impl/sql/compile/sqlgrammar.jj (working copy) @@ -7305,6 +7305,12 @@ * * RESOLVE - someday we should try to find matching aggregates * instead of just adding them. + * + * NOTE: This rewriting of the query tree makes the handling of an ORDER BY + * clause difficult. See OrderByColumn.pullUpOrderByColumn. It makes specific + * assumptions about the structure of the generated query tree. Do not make + * any changes to this transformation without carefully considering the + * OrderByColumn pullUpOrderByColumn and bindOrderByColumn methods. */ if (havingClause != null) { Index: java/engine/org/apache/derby/impl/sql/compile/OrderByColumn.java === --- java/engine/org/apache/derby/impl/sql/compile/OrderByColumn.java (revision 168148) +++ java/engine/org/apache/derby/impl/sql/compile/OrderByColumn.java (working copy) @@ -30,6 +30,8 @@ import org.apache.derby.iapi.sql.compile.NodeFactory; import org.apache.derby.iapi.sql.compile.C_NodeTypes; +import org.apache.derby.iapi.util.ReuseFactory; + /** * An OrderByColumn is a column in the ORDER BY clause. An OrderByColumn * can be ordered ascending or descending. @@ -44,6 +46,12 @@ private ResultColumn resultCol; private boolean ascending = true; private ValueNode _expression_; +/** + * If this sort key is added to the result column list then it is at result column position + * 1 + resultColumnList.size() - resultColumnList.getOrderBySelect() + addedColumnOffset + * If the sort key is already in the reault colum list then addedColumnOffset < 0. + */ +private int addedColumnOffset = -1; /** @@ -161,31 +169,23 @@ } }else{ - ResultColumnList targetCols = target.getResultColumns(); - ResultColumn col = null; - int i = 1; - - for(i = 1; - i <= targetCols.size(); - i ++){ - -col = targetCols.getOrderByColumn(i); -if(c
Re: [PATCH] Derby-127
I have committed this patch. If you would like to submit test updates later, that would be fine. Satheesh Jack Klebanoff wrote: > Army wrote: > >> Jack Klebanoff wrote: >> >>> I have attached a patch that fixes Jira bug Derby-127 >>> (http://issues.apache.org/jira/browse/DERBY-127). >> >> >> >> I reviewed this patch, applied it to a clean codeline without >> problem, and ran the orderby.sql test that was included. From what I >> can tell, everything looks good here. >> >> My only minor comment is that it might be nice to add a case to the >> orderby.sql test to make sure things work if _multiple_ columns are >> provided in an order by clause. Ex. >> >> ij> select c1 as x, c2 as y from bug2769 group by bug2769.c1, >> bug2769.c2 order by c1, c2; >> >> ij> select c1 as x, c2 as y from bug2769 group by bug2769.c1, >> bug2769.c2 order by c1, y; >> >> I tried these and they both work fine--no problems there. But it was >> something I was wondering while I was reviewing, so it might be nice >> to include it in the test...*shrug* >> >> In any event, the patch gets my +1, >> Army >> >> > I agree with Army's suggestion for an extra test. Should I wait for my > original patch to be committed and submit the new test in a new patch, > or should I revise and re-submit my patch? Since Army has shown that > the patch does handle his test case I suggest committing my current > patch first. This will get things moving. Adding a few cases to an > existing test results in a small, easily reviewed patch. If I revise > the submitted patch it will be more difficult to review the submission. > > Jack Klebanoff > > >
Re: [PATCH] (DERBY-104) Get rid of the Max lenght of 18 for constraint names
Hi Bernt, I tried to apply your patch. Most of the patch applied correctly, except for sqlgrammar.jj. There have been other modifications to sqlgrammar.jj since the patch was made. I could either try to fix them up or ask you to submit another patch. It may be best if you submit a new patch, based on Friday evening code. I will apply the patch and run tests in my environment to catch any major failures. Then I will submit it on Saturday morning, if the plan works for you. You can decide if you would like to change the names of DB2 specific constant names being discussed here. I am OK eitherway. Satheesh Bernt M. Johnsen wrote: See comments inline. Army wrote (2005-05-11 16:18:42): Bernt M. Johnsen wrote: Hi all, Could somebody review this patch (my first)? Now all identifiers should have a max length of 128 (note: MAX_USERID_LENGTH is unchanged). I reviewed this patch and it looks good to me. I noticed that in the JIRA entry for this bug, you had written that you wanted to do the following: [ begin quote ] 2) Ensure that all DB2 related constants are prefixed by DB2_ There are now 6 constants which do not have the prefix: MIN_COL_LENGTH_FOR_CURRENT_USER, MIN_COL_LENGTH_FOR_CURRENT_SCHEMA, MAX_USERID_LENGTH, MAX_DECIMAL_PRECISION_SCALE, DEFAULT_DECIMAL_PRECISION, DEFAULT_DECIMAL_SCALE These should get the DB2_ prefix if they are DB2-related (are they?) [ end quote ] Did you decide to not do this part? I never got an answer, so I decided not to touch these constants. For the record, the comments in the code suggest that the first three of these (MIN_COL_LENGTH_FOR_CURRENT_USER, MIN_COL_LENGTH_FOR_CURRENT_SCHEMA, and MAX_USERID_LENGTH) are definitely DB2-related, so adding the "DB2_" prefix to those would make sense. Should I add "DB2_"-prefix to these constants, then? (and leave the latter-three unchanged?). As for the latter three, one might assume that they are DB2-specific since they were declared in the "DB2Limits.java" file, but maybe that's not a valid assumption...anyone out there know?? On the one hand, I think these "DB2_" prefix changes could easily be checked in later with a different patch, if someone wants to do it. On the other, it might be less inuitive to people browsing changes to see a solo patch that adds a "DB2_" prefix to some constants in "Limits.java"--at the very least, the patch to do so would have to be very well-commented, or else it could lead to confusion. NOTE: I couldn't get svn diff to reflect that I have renamed one file (done with svn rename). If it is a problem, I can undo the rename and submit a new patch. I did have problems applying the patch to the my local codeline, and I'm pretty sure it was because of this. In order to get the patch to apply, I manually copied "DB2Limit.java" to "Limits.java"--after doing that (and only that), I was then able to successfully apply the patch. So whoever commits this might need to do the same, or else use some other trick to get the patch to apply correctly. Seems to me that this is a weakness in the way we submit pathces (probably a weakness in svn). After applying the patch I ran a couple of the tests that were affected, and they passed as expected. One last question: did you have a chance to run the "derbyall" suite on this to make sure you caught all of the relevant tests? I'm guessing that you did based on the number of masters that you updated, but it'd be nice to confirm--typically when you submit a patch, it's good to indicate what tests you ran (and on what platforms/JVMs) just so that reviewers know you actually tested your patch before posting it (which you clearly did!) ;) Yes, I ran derbyall: Java Version:1.4.2_02 Java Vendor: Sun Microsystems Inc. OS name: Linux OS architecture: i386 OS version: 2.4.20-31.9 All in all, looks good to me. Thanks.
Re: Strange behaviour when combining column alias and group by
Well, fix for Derby-127 doesn't fix this. Looks like we need a new Jira entry. Exposed name handling is getting better, but looks like still has some kinks. Satheesh Bernt M. Johnsen wrote: >I stumbeled across this strange behaviour when combining coumn alias >and group by: > >ij> select * from tt; >I |J >--- >1 |2 >2 |3 >1 |2 >2 |3 >2 |3 > >5 rows selected >ij> select i, count(*) as cnt from tt group by i; >I |CNT >--- >1 |2 >2 |3 > >2 rows selected >ij> select i, count(*) as i from tt group by i; >I |I >--- >1 |1 >2 |2 > >2 rows selected > >The last select is obviously wrong! This might be related to >DERBY-127, but if it's not I'll file it asa separate issue. > > > >
Re: Can someone assign me to DERBY-253?
You should be able to assign it to yourself now. You have been added to 'derby-developers' alias. Satheesh Olav Sandstaa wrote: >Hi, > >I volunteer to look into the following JIRA issue: > > DERBY-253: Client should throw not implemented exception for depricated > setUnicodeStream/getUnicodeStream > >I can't assign myself, so can someone please assign it to me? > >JIRA username: olav > >Thanks, >Olav > > >
Re: Can someone assign me to DERBY-249?
I have added 'dyret' to 'derby-developers' list. You should be able to assign bugs to yourself. Please follow proper procedures when modifying Jira entries. This link has some info: http://incubator.apache.org/derby/binaries/FilingDerbyIssuesInJira.doc Also follow Derby bug guidelines: http://incubator.apache.org/derby/DerbyBugGuidelines.html Satheesh [EMAIL PROTECTED] wrote: >JIRA Username: dyret > >Thanks, > > >
Re: [PATCH] Timestamp Arithmetic
How about TernaryOperatorNode? It is currently being used to implement disparate operations, TRIM, LOCATE, SUBSTR and LIKE. Gets little ugly to overload, but it might be worth the effort... Satheesh >> >> Dan. >> >> >> > The timestamp escape functions are ternary functions, not binary > operators. I looked at trying to consolidate them with the binary or > unary operator nodes, but there was not that much commonality. It was > an awkard fit. > > Jack > > >
Re: Patch again again for DERBY-167.
Thanks for applying review comments. Overall, the patch looks good. Some minor comments: ColumnDefinitionNode: I would like to see following comments be more descriptive. Initially I thought these refer to another method, but that is not the case. + //validateDefaultOfAutoInc + //validateDefaultOfDefault ColumnDescriptor.java: Is there an extra assert for autoincInc being non-zero at line: 156? (Second constructor). Also 'static' is not needed for assertAutoinc() method. Please apply Army's and my comments. I also invite others to review the patch, since I will be looking to commit this one soon, after getting an updated patch. :-) Satheesh TomohitoNakayama wrote: Hello. I send new patch for DERBY-167 , which is attached to this mail. Please review it. Best regards. /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */ - Original Message - From: "Army" <[EMAIL PROTECTED]> To: "Derby Development" Sent: Saturday, May 14, 2005 9:13 AM Subject: Re: Patch again for DERBY-167. TomohitoNakayama wrote: Hello. I send new patch for DERBY-167. Please review it again. I tried to apply this patch to my local codeline (which I just updated) so that I could review it more closely, but the patch fails to apply in several places. I know it's annoying, but could you perhaps "svn update" your codeline and then re-create the patch based on the latest files? If I can get the patch to apply, it makes it easier to review the code. Also, I can then run the new/updated tests and verify that everything works as intended... Thanks, Army -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 2005/05/13 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 2005/05/13