[jira] Updated: (DERBY-1463) Resolve javadoc warnings in BrokeredCallableStatement40
[ http://issues.apache.org/jira/browse/DERBY-1463?page=all ] V.Narayanan updated DERBY-1463: --- Attachment: JavaDocWarnings.diff JavaDocWarnings.stat Please find attached patch for fix. thanx Narayanan Resolve javadoc warnings in BrokeredCallableStatement40 --- Key: DERBY-1463 URL: http://issues.apache.org/jira/browse/DERBY-1463 Project: Derby Type: Bug Components: Javadoc Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Attachments: JavaDocWarnings.diff, JavaDocWarnings.stat following javadoc warnings in trunk: [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:287: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:303: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:319: warning - @param argument parameterIndex is not a parameter name. -- 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
Privilege requirements for a constraint
Hi, As part of Derby SQL Authorization mode, I am looking intocollecting privilege requirements for a new constraint and saving it into SYSDEPENDS using dependency manager. Constraints are unlike views and triggers in the sense thatone can create only single view or trigger with a given sql statement. And hence, all the privileges collected during the bind phase of create view/trigger applies to that view/trigger. But with constraints, one can define multiple constraints using a single sql statement. eg user1 connects create table t11 (c111 int not null primary key); create table t12 (c121 int not null primary key); grant references on t11 to user2; grant references on t12 to user2; user2 connects create table t21 (c211 int constraint t21c1 references user1.t11, c212 int constraint t21c2 references user1.t12); -- For the create table t21 sql above, it has privilege dependency on mamta1.t11 and mamta1.t12, both of REFERENCES type. But the constraint t21c1 should depend only REFERENCES type privilege on mamta1.t11 And constraint t21c2 should depend only on REFERENCES type privilege on mamta1.t12The sql statement level privilege requirements somehow needsbe broken down into constraint specific privilege list. And that list will be saved in SYSDEPENDS using the dependency manager. Nothing is coming to my mind right away about how I would break statement privilege requirement into constraint specific privilege requirementand wondered if community had any tips/pointers for me. As always, any feedback greatly appreciated, Mamta
Re: minor javadoc warnings in trunk
Hi, Thank You for pointing this out. Related to patch for 1445. Have raised a JIRA issue and attached patch. thanx Narayanan Deepa Remesh wrote On 06/29/06 08:07,: Noticed following javadoc warnings in trunk: [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:287: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:303: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:319: warning - @param argument parameterIndex is not a parameter name. Thanks, Deepa
[jira] Resolved: (DERBY-1463) Resolve javadoc warnings in BrokeredCallableStatement40
[ http://issues.apache.org/jira/browse/DERBY-1463?page=all ] Knut Anders Hatlen resolved DERBY-1463: --- Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 417953. Resolve javadoc warnings in BrokeredCallableStatement40 --- Key: DERBY-1463 URL: http://issues.apache.org/jira/browse/DERBY-1463 Project: Derby Type: Bug Components: Javadoc Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Fix For: 10.2.0.0 Attachments: JavaDocWarnings.diff, JavaDocWarnings.stat following javadoc warnings in trunk: [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:287: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:303: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:319: warning - @param argument parameterIndex is not a parameter name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1463) Resolve javadoc warnings in BrokeredCallableStatement40
[ http://issues.apache.org/jira/browse/DERBY-1463?page=comments#action_12418399 ] V.Narayanan commented on DERBY-1463: thanx for the commit knut Narayanan Resolve javadoc warnings in BrokeredCallableStatement40 --- Key: DERBY-1463 URL: http://issues.apache.org/jira/browse/DERBY-1463 Project: Derby Type: Bug Components: Javadoc Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Fix For: 10.2.0.0 Attachments: JavaDocWarnings.diff, JavaDocWarnings.stat following javadoc warnings in trunk: [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:287: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:303: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:319: warning - @param argument parameterIndex is not a parameter name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-937) Instability in wisconsin test
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ] Andreas Korneliussen updated DERBY-937: --- Attachment: DERBY-937.diff DERBY-937.stat I was able to reproduce this problem on every run on a very fast laptop (it was not reproducible on any other Windows lab machine I have tried). This laptop happens to be the same kind as Ole uses for the nightly tests. Adding a 10 second sleeping period after the population of the tables, did not have any effect. I therefore tried to do run a compress on the tables (based on the assumption that statistics is updated on compress), and now the test does not fail for me anymore. Attached is the patch which makes this test stop failing. The patch does not seem to have any sideeffects on other platforms (Solaris) tested, however the test will use more time. Instability in wisconsin test - Key: DERBY-937 URL: http://issues.apache.org/jira/browse/DERBY-937 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.1.2.4 Reporter: Rick Hillegas Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat The lang/wisconsin.java test prints out query plans. These plans differ depending on your platform. When run under cygwin on xp, the plans vary from the canonized results. I am seeing this instability in my own test environment and in the tinderbox tests against cygwin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-937) Instability in wisconsin test
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ] Andreas Korneliussen reassigned DERBY-937: -- Assign To: Andreas Korneliussen Instability in wisconsin test - Key: DERBY-937 URL: http://issues.apache.org/jira/browse/DERBY-937 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.1.2.4 Reporter: Rick Hillegas Assignee: Andreas Korneliussen Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat The lang/wisconsin.java test prints out query plans. These plans differ depending on your platform. When run under cygwin on xp, the plans vary from the canonized results. I am seeing this instability in my own test environment and in the tinderbox tests against cygwin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - Derby 417826 - Sun DBTG
[Auto-generated mail] *Derby* 417826/2006-06-28 19:46:06 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 2715713 0 105.95% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-417826.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/417826.html *Jvm: 1.5* 4675671 2 101.09% CYGWIN_NT-5.1_i686-unknown 2675673 2 116.66% CYGWIN_NT-5.2_i686-unknown 0675675 2 114.16% Linux-2.6.14-1.1644_FC4_i686-i686 0675675 2 105.58% Linux-2.6.9-34.ELsmp_x86_64-x86_64 4675671 2 171.26% SunOS-5.10_i86pc-i386 1675674 2 158.97% SunOS-5.10_sun4u-sparc 0675675 2 107.85% SunOS-5.11_i86pc-i386 0675675 2 111.92% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-417826.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/417826.html *Jvm: 1.4* 3669666 496.60% CYGWIN_NT-5.1_i686-unknown 0669669 4 113.88% Linux-2.6.14-1.1644_FC4_i686-i686 0669669 4 105.20% Linux-2.6.9-34.ELsmp_x86_64-x86_64 3669666 4 213.83% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-417826.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/417826.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/417826.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Regression Test Failure! - TinderBox_Derby 417953 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 417953/2006-06-29 09:03:01 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1675674 2 117.11% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-417953.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/417953.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/417953.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Derby as desktop database
I've been looking for some time for a good embedded database that would work for desktop applications. Derby is ideal for that and I am starting to use it more and more in various examples and tutorials that I am writing for Cayenne. But there is one feature that I am missing in Derby (or any other database for that matter) - an ability to share the same database between multiple desktop applications (or multiple VM instances of the same Java application). I asked this question the Derby folks from Sun at ApacheCon in Dublin the other day and the answer was basically - run the network server. In other words db sharing and embedded mode are not compatible. So I wonder what it would take to make it compatible? Since we are talking desktop apps, the following conditions are at play: (a) all apps run on the same machine (but in different VMs) (b) usually only one instance at a time would work with the database, but other instances can occasionally access the db in the background (no need to deal with massive concurrency) (c) usually the database is small-to-medium size. Any ideas? One possible solution is cloning the DB for each instance and using multicast for peer-to-peer synchronization. Another (more promising) is to do collaborative peer-to-peer connection pool (DataSource), so that when a client needs a local Derby connection it sends a multicast so that current lock owner in a different VM can finish its thing, shutdown Derby and release the lock. I wonder if anyone has done that already? Andrus -- Andrus (aka Andrei) Adamchik Cayenne Persistence Framework Creator, Committer http://incubator.apache.org/projects/cayenne.html
Derby as desktop database
I've been looking for some time for a good embedded database that would work for desktop applications. Derby is ideal for that and I am starting to use it more and more in various examples and tutorials that I am writing for Cayenne. But there is one feature that I am missing in Derby (or any other database for that matter) - an ability to share the same database between multiple desktop applications (or multiple VM instances of the same Java application). I asked this question the Derby folks from Sun at ApacheCon in Dublin the other day and the answer was basically - run the network server. In other words db sharing and embedded mode are not compatible. So I wonder what it would take to make it compatible? Since we are talking desktop apps, the following conditions are at play: (a) all apps run on the same machine (but in different VMs) (b) usually only one instance at a time would work with the database, but other instances can occasionally access the db in the background (no need to deal with massive concurrency) (c) usually the database is small-to-medium size. Any ideas? One possible solution is cloning the DB for each instance and using multicast for peer-to-peer synchronization. Another (more promising) is to do collaborative peer-to-peer connection pool (DataSource), so that when a client needs a local Derby connection it sends a multicast so that current lock owner in a different VM can finish its thing, shutdown Derby and release the lock. I wonder if anyone have done that already? Andrus -- Andrus (aka Andrei) Adamchik Cayenne Persistence Framework Creator, Committer http://incubator.apache.org/projects/cayenne.html
Re: Derby as desktop database
Hi Andrus! After you left, we were playing around with the problem and were thinking along the same lines as your second solution. Some peer-to-peer protocol or some multicast membership protocol (e.g. something like JGroups http://www.jgroups.org/javagroupsnew/docs/index.html. I have done similar stuff before, and with the proper library, it's not that hard to implement) for group communication and voting for a master (which would be the server). The system should distribute information on where the server is and put up local connection pools which should be invalidated when the master dies. If the master dies another master is voted for. The application should be written with the proper catch/rollback/retry cycles for transactions, since losing the connection as a transient error in such a system. (We've been working with distributed databases before, so this is just something you have to do when you're starting to distribute database usage). Bernt Olav Andrus Adamchik wrote: I've been looking for some time for a good embedded database that would work for desktop applications. Derby is ideal for that and I am starting to use it more and more in various examples and tutorials that I am writing for Cayenne. But there is one feature that I am missing in Derby (or any other database for that matter) - an ability to share the same database between multiple desktop applications (or multiple VM instances of the same Java application). I asked this question the Derby folks from Sun at ApacheCon in Dublin the other day and the answer was basically - run the network server. In other words db sharing and embedded mode are not compatible. So I wonder what it would take to make it compatible? Since we are talking desktop apps, the following conditions are at play: (a) all apps run on the same machine (but in different VMs) (b) usually only one instance at a time would work with the database, but other instances can occasionally access the db in the background (no need to deal with massive concurrency) (c) usually the database is small-to-medium size. Any ideas? One possible solution is cloning the DB for each instance and using multicast for peer-to-peer synchronization. Another (more promising) is to do collaborative peer-to-peer connection pool (DataSource), so that when a client needs a local Derby connection it sends a multicast so that current lock owner in a different VM can finish its thing, shutdown Derby and release the lock. I wonder if anyone have done that already? Andrus -- Andrus (aka Andrei) Adamchik Cayenne Persistence Framework Creator, Committer http://incubator.apache.org/projects/cayenne.html -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: OpenPGP digital signature
Re: Derby as desktop database
Cool. I actually started prototyping something similar this morning, with one difference that I am not defining a master server, but rather making it peer-to-peer (where the ownership of the database is transferred on demand between the applications). This will likely reduce the throughput (as reassigning the ownership would require a full shutdown), but hopefully address the need to handle dropped connections. Cayenne has a generic distributed EventManager (with pluggable transports, JavaGroups being one supported option) that I can try for this purpose. We'll see how that works. Andrus On Jun 29, 2006, at 11:07 AM, Bernt M. Johnsen wrote: Hi Andrus! After you left, we were playing around with the problem and were thinking along the same lines as your second solution. Some peer-to- peer protocol or some multicast membership protocol (e.g. something like JGroups http://www.jgroups.org/javagroupsnew/docs/index.html. I have done similar stuff before, and with the proper library, it's not that hard to implement) for group communication and voting for a master (which would be the server). The system should distribute information on where the server is and put up local connection pools which should be invalidated when the master dies. If the master dies another master is voted for. The application should be written with the proper catch/rollback/retry cycles for transactions, since losing the connection as a transient error in such a system. (We've been working with distributed databases before, so this is just something you have to do when you're starting to distribute database usage). Bernt Olav Andrus Adamchik wrote: I've been looking for some time for a good embedded database that would work for desktop applications. Derby is ideal for that and I am starting to use it more and more in various examples and tutorials that I am writing for Cayenne. But there is one feature that I am missing in Derby (or any other database for that matter) - an ability to share the same database between multiple desktop applications (or multiple VM instances of the same Java application). I asked this question the Derby folks from Sun at ApacheCon in Dublin the other day and the answer was basically - run the network server. In other words db sharing and embedded mode are not compatible. So I wonder what it would take to make it compatible? Since we are talking desktop apps, the following conditions are at play: (a) all apps run on the same machine (but in different VMs) (b) usually only one instance at a time would work with the database, but other instances can occasionally access the db in the background (no need to deal with massive concurrency) (c) usually the database is small-to-medium size. Any ideas? One possible solution is cloning the DB for each instance and using multicast for peer-to-peer synchronization. Another (more promising) is to do collaborative peer-to-peer connection pool (DataSource), so that when a client needs a local Derby connection it sends a multicast so that current lock owner in a different VM can finish its thing, shutdown Derby and release the lock. I wonder if anyone have done that already? Andrus -- Andrus (aka Andrei) Adamchik Cayenne Persistence Framework Creator, Committer http://incubator.apache.org/projects/cayenne.html -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
Re: MySQL to Derby Migration Tool
Hi David, Thanks for your comments. My comments inline Thanks, Ramin On 6/27/06, David Van Couvering [EMAIL PROTECTED] wrote: Hi, Ramin. Great document! Very nicely done. Here are my comments: - You're a UML use case guy. Great! Wish there was more of that in software design, especially for tools. - What's the mapping from MySql YEAR to Derby? Derby does not seem to have a YEAR data type. We can probably use INTEGER insteadAny thoughts? - Can you explain a little more how DdlUtils takes care of data type mapping? ddlutils tool uses JDBC datatypes rather than SQL datatypes which are database dependent. Looking at http://db.apache.org/ddlutils/database-support.html, explains mapping between JDBC types and SQL types. For example, a TIINYINT datatype from MySQL, will be mapped to SMALLINT in Derby. I will explain this in detail in the document. - Can you explain a little more what you mean by A possible solution would be to execute database-specific commands to capture required information. when you say DdlUtils doesn't support constraints, triggers, stored procedures, etc. In the case of MySQL, we can use the SHOW command to capture the exact string to re-create the original object. For example SHOW CREATE PROCEDURE or SHOW CREATE FUNCTION can be used to capture the original statement used to create function/procedure. I will add these information to the document. - I guess I don't follow the application flow very well when using DdlUtils. What exactly are the steps taken by the user and/or the tool using DdlUtils? I probably need another usecase diagram for ddlutils. I will add that to the document. - What is *your* recommended approach (DatabaseMetadata vs. DdlUtils) and why? I would think a combination of ddlutils and DatabaseMetadata approach is needed to handle cases not supported by ddlutils like stroed procedures. I will add a section to the document on this. - Can you talk more to what happens if there is an error during migration at various phases. What steps does the tool take to set things right? Can you end up with a half-created database? What do you do to fix the errors and start over? I suspect migration is often a repetitive effort as you catch migration/mapping errors, fix things, and try again... This should be as painless as possible. Sure, I will add this information as well. - Can you please show the proposed syntax and other details (input files, config files, env variables, exit status) for the CLI? Ok. - Does the CLI have a headless mode (e.g. no interactive prompts) so you can run it in a script? Good suggestion.I was not thinking about CLI with headless mode. I will add information on this. - What is the syntax for starting the tool? Will you make use of derbyrun.jar? I will need to investigate this. - Can you cover quickly how you'll address internationalizing the GUI? Sure - Can you explain briefly how, using this architecture, you can plug in other data sources besides MySQL? Ok. - You might want to touch on the impact to existing JDBC applications that are running against MySQL, which you want to migrate to Derby. How are *those* migrated, and how much or how little does this tool help with that? If anything, just make it clear that application migration is out of the scope of this tool. Ok - What mechanism are you going to use to do the data transfer? Simple JDBC inserts? Bulk insert? For large databases the mechanism you use can have a large impact on performance, and may actually prevent some databases from migrating. It would be good to have a section on performance and what approaches you will take to improve performance and test performance. I will add a section on performance. - What about migration of users, groups, permissions, etc. -- is that out of scope? Good suggestionI did not think about this. I will add it to the docuemtn - Perhaps it would be good to be *very* explicit about what you plan to migrate and what you *don't* plan to migrate in this tool, and what you recommend for users for the bits that aren't being migrated (applications, authorizations, triggers, whatever is on that list). Ok - This may not be your itch to scratch, but can you address what you're planning to do to (or not do) to address governmental accessibility requirements (called Section 508)? See http://java.sun.com/products/jfc/accessibility/index.jsp. At a minimum it would be great if you don't do anything that makes it difficult for someone else to make the tool accessible. Ok. I will look into this. Thanks! David Ramin Moazeni wrote: Hello, I am a Google Summer of code participant working on the Derby Migration tool project. The High level design document is posted at http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument There are 2 approaches described in the document -- one based on the use DatabaseMetaData class and the other is based on the use ddlUtils
Re: MySQL to Derby Migration Tool
Hi Satheesh Thanks for your commentsI will post the document ddlutils-dev alias as well. Thanks, Ramin On 6/27/06, Satheesh Bandaram [EMAIL PROTECTED] wrote: Great document and good comments from David. I think it would be good to follow ddlUtils approach (approach 2) if feasible. Ramin, should this approach be also discussed on ddlUtils development alias? I think you would need to handle some database objects like CHECK constraints and others in a database specific way in either approach. DatabaseMetadata doesn't provide a way and probably why ddlUtil doesn't support that either. These objects will have to be migrated by reading source database specific system tables... so your generic migration tool would probably need a source database specific plug-in... I would also like to encourage others to review the document as Ramin seems to be making good progress towards implementation. Satheesh On 6/27/06, David Van Couvering [EMAIL PROTECTED] wrote: Hi, Ramin. Great document! Very nicely done. Here are my comments: - You're a UML use case guy. Great! Wish there was more of that in software design, especially for tools. - What's the mapping from MySql YEAR to Derby? - Can you explain a little more how DdlUtils takes care of data type mapping? - Can you explain a little more what you mean by A possible solution would be to execute database-specific commands to capture required information. when you say DdlUtils doesn't support constraints, triggers, stored procedures, etc. - I guess I don't follow the application flow very well when using DdlUtils. What exactly are the steps taken by the user and/or the tool using DdlUtils? - What is *your* recommended approach (DatabaseMetadata vs. DdlUtils) and why? - Can you talk more to what happens if there is an error during migration at various phases. What steps does the tool take to set things right? Can you end up with a half-created database? What do you do to fix the errors and start over? I suspect migration is often a repetitive effort as you catch migration/mapping errors, fix things, and try again... This should be as painless as possible. - Can you please show the proposed syntax and other details (input files, config files, env variables, exit status) for the CLI? - Does the CLI have a headless mode ( e.g. no interactive prompts) so you can run it in a script? - What is the syntax for starting the tool? Will you make use of derbyrun.jar? - Can you cover quickly how you'll address internationalizing the GUI? - Can you explain briefly how, using this architecture, you can plug in other data sources besides MySQL? - You might want to touch on the impact to existing JDBC applications that are running against MySQL, which you want to migrate to Derby. How are *those* migrated, and how much or how little does this tool help with that? If anything, just make it clear that application migration is out of the scope of this tool. - What mechanism are you going to use to do the data transfer? Simple JDBC inserts? Bulk insert? For large databases the mechanism you use can have a large impact on performance, and may actually prevent some databases from migrating. It would be good to have a section on performance and what approaches you will take to improve performance and test performance. - What about migration of users, groups, permissions, etc. -- is that out of scope? - Perhaps it would be good to be *very* explicit about what you plan to migrate and what you *don't* plan to migrate in this tool, and what you recommend for users for the bits that aren't being migrated (applications, authorizations, triggers, whatever is on that list). - This may not be your itch to scratch, but can you address what you're planning to do to (or not do) to address governmental accessibility requirements (called Section 508)? See http://java.sun.com/products/jfc/accessibility/index.jsp. At a minimum it would be great if you don't do anything that makes it difficult for someone else to make the tool accessible. Thanks! David Ramin Moazeni wrote: Hello, I am a Google Summer of code participant working on the Derby Migration tool project. The High level design document is posted at http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument There are 2 approaches described in the document -- one based on the use DatabaseMetaData class and the other is based on the use ddlUtils tool (http://db.apache.org/ddlutils) which is also an apache project. I would appreciate your feedback and comments Thanks much Ramin Moazeni
[jira] Resolved: (DERBY-1444) Using -Djvmflags option causes NoClassDefFoundError
[ http://issues.apache.org/jira/browse/DERBY-1444?page=all ] Andreas Korneliussen resolved DERBY-1444: - Resolution: Fixed Derby Info: (was: [Patch Available]) Resolving the issue since the patch has been committed to both trunk and 10.1 branch. Using -Djvmflags option causes NoClassDefFoundError --- Key: DERBY-1444 URL: http://issues.apache.org/jira/browse/DERBY-1444 Project: Derby Type: Bug Components: Test Versions: 10.1.3.0, 10.2.0.0 Environment: Suns jvm 1.5 Reporter: Vemund Østgaard Assignee: Vemund Østgaard Priority: Minor Fix For: 10.1.3.1, 10.2.0.0 Attachments: 1444-diff, 1444-diff.stat When starting tests with the -Djvmflags option, the harness (RunList class) places around the argument to -Djvmflags when executing the java launcher to start a new jvm. This is (at least by suns java launcher) interpreted as a Class and not as a command line option, because of the . Because of this I get a NoClassDefFoundError. I believe this is a problem that happens only when using Suns java launcher. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1461) Separate writeScalarStream to methods which handle either encrypted or plain streams.
[ http://issues.apache.org/jira/browse/DERBY-1461?page=all ] Tomohito Nakayama updated DERBY-1461: - Attachment: DERBY-1461.patch Description of the patch : * The method writeScalarStream was separeted to two methods for encrypted stream and plain. Test : * Execute derbyall and found no error other than one found in DERBY-1351. Separate writeScalarStream to methods which handle either encrypted or plain streams. - Key: DERBY-1461 URL: http://issues.apache.org/jira/browse/DERBY-1461 Project: Derby Type: Sub-task Reporter: Tomohito Nakayama Assignee: Tomohito Nakayama Attachments: DERBY-1461.patch Reading writeScalarStream in Request class, I found it would be possible to separate this method to two methods, one is for encrypted stream and another is for plain, because original writeScalarStream hardly share code for encrypted and for plain. Separating this method will help me to realize DERBY-1301 separatingly for encrypted and plain, as I planned in http://issues.apache.org/jira/browse/DERBY-1301#action_12417684 . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1351) lang/forupdate.sql fails with derbyclient in the 10.1 branch
[ http://issues.apache.org/jira/browse/DERBY-1351?page=all ] Fernanda Pizzorno reassigned DERBY-1351: Assign To: Fernanda Pizzorno lang/forupdate.sql fails with derbyclient in the 10.1 branch Key: DERBY-1351 URL: http://issues.apache.org/jira/browse/DERBY-1351 Project: Derby Type: Bug Components: Test Versions: 10.1.2.5, 10.2.0.0 Environment: Windows 2000 and Sun jdk 15 Reporter: Rajesh Kartha Assignee: Fernanda Pizzorno Priority: Minor Fix For: 10.1.4.0 Derby 10.1 branch - 10.1.2.5 - (409283) *** Start: forupdate jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006-05-24 21:24:26 *** 333 del SQL_CURLH000C3 333a333 SQL_CURLH000C1 393 del SQL_CURLH000C3 393a393 SQL_CURLH000C1 Test Failed. *** End: forupdate jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006-05-24 21:24:41 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[
http://issues.apache.org/jira/browse/DERBY-1393?page=comments#action_12418457 ]
Knut Anders Hatlen commented on DERBY-1393:
---
Thanks for the info, Rick! Seems like setObject() with
targetSqlType==JAVA_OBJECT should be supported too, then. For instance, this
works:
PreparedStatement ps = c.prepareStatement
(select aliasinfo from sys.sysaliases where aliasinfo = ?);
ps.setObject(1, new org.apache.derby.catalog.AliasInfo() {
public String getMethodName() {
return John Cleese;
}
});
ps.executeQuery();
It should also work when targetSqlType is specified.
PreparedStatement.setObject(Object,int,int) should throw for unsupported types
--
Key: DERBY-1393
URL: http://issues.apache.org/jira/browse/DERBY-1393
Project: Derby
Type: Bug
Components: JDBC, SQL
Versions: 10.2.0.0
Environment: JDBC 4, jdk 1.6
Reporter: Dyre Tjeldvoll
Assignee: Knut Anders Hatlen
Priority: Minor
Fix For: 10.2.0.0
From the javadoc:
Throws:
...
SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB,
CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF,
ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this
data type
Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR,
LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw
SQLFeatureNotSupportedException if used with any of these types. Currently a
general type conversion exception is thrown:
1)
testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL
Exception: An attempt was made to get a data value of type 'CLOB' from a
data value of type '2003'.
Caused by: SQL Exception: An attempt was made to get a data value of type
'CLOB' from a data value of type '2003'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Derby as desktop database
Andrus Adamchik wrote: (a) all apps run on the same machine (but in different VMs) (b) usually only one instance at a time would work with the database, but other instances can occasionally access the db in the background (no need to deal with massive concurrency) The way this is usually accomplished is with embedded server. Network server is started in the same JVM as the primary instance. The primary instance accesses with embedded connections. Other JVM's can access with client. See: http://db.apache.org/derby/docs/10.1/adminguide/radminembeddedserverex.html Also the StartNetworkServerSample demo shows how this works using the derby.drda.startNetworkServer property. You should be able to just add derby.drdal.startNetworkServer=true to your derby.properties and be able to start connecting from other JVM's right away. http://svn.apache.org/viewvc/db/derby/code/branches/10.1/java/demo/nserverdemo/SimpleNetworkServerSample.java?view=logpathrev=408612 Kathey
Synchronization on the connection in JDBC calls
Hello,
When working on EmbedPreparedStatement.java, I noticed that a few
methods synchronize on the connection object, for instance addBatch. The
code typically looks like this:
synchronized (getConnectionSynchronization()) {
// Do stuff
}
The getConnectionSynchronization-method returns a reference to the root
connection. I also saw that EmbedResultSet uses this more.
The rest of the JDBC methods in EmbedPreparedStatement don't synchronize
on this object.
I think a single connection is not expected to be shared between
multiple threads simultaneously. Maybe the necessary synchronization is
done at a lower level in the system.
Would anyone care to share their thoughts/knowledge on this issue?
Thanks,
--
Kristian
[jira] Created: (DERBY-1464) runtimestatistics can show that an index is being used even when it isn't
runtimestatistics can show that an index is being used even when it isn't -- Key: DERBY-1464 URL: http://issues.apache.org/jira/browse/DERBY-1464 Project: Derby Type: Bug Components: SQL Versions: 10.1.2.5 Reporter: Kathey Marsden Assigned to: Manish Khettry Priority: Minor The patch for DERBY-578 also fixes an issue that runtimestatistics may print that an index is being used, even when it isn't. Here is the explanation from DERBY-578. Earlier, we would set the indexName field in DistinctScanResult to the conglomerate name (cd.getName()) used to scan the table. If the conglomerate was the base table itself then this was just plain wrong. The change, for this patch, passes null if no index is being used. This bug should be marked fixed when DERBY-578 is checked in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1465) NetworkServerControl.start() should throw an exception and not just print exceptions starting network server
NetworkServerControl.start() should throw an exception and not just print exceptions starting network server Key: DERBY-1465 URL: http://issues.apache.org/jira/browse/DERBY-1465 Project: Derby Type: Bug Components: Network Server Versions: 10.1.2.1 Reporter: Kathey Marsden Priority: Minor NetworkServerControl.start() will not throw an exception if another server is already running on the same port.I am not sure but think perhaps this was changed at one point to accomodate the derby.drda.startNetworkServer property so that the embedded server could continue to boot even if the network server failed to start, but I think this is wrong for normal usage. http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Derby as desktop database
Kathey Marsden wrote: The way this is usually accomplished is with embedded server. Network server is started in the same JVM as the primary instance. The primary instance accesses with embedded connections. Other JVM's can access with client. Yes. But Angus' extra problem as I understand it, is that the apps will be started and stopped in an undefined order, so there's no natural server to chose. See: http://db.apache.org/derby/docs/10.1/adminguide/radminembeddedserverex.html Also the StartNetworkServerSample demo shows how this works using the derby.drda.startNetworkServer property. You should be able to just add derby.drdal.startNetworkServer=true to your derby.properties and be able to start connecting from other JVM's right away. http://svn.apache.org/viewvc/db/derby/code/branches/10.1/java/demo/nserverdemo/SimpleNetworkServerSample.java?view=logpathrev=408612 Kathey -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: OpenPGP digital signature
[jira] Updated: (DERBY-1465) NetworkServerControl.start() should throw an exception and not just print exceptions if the server fails to start
[ http://issues.apache.org/jira/browse/DERBY-1465?page=all ] Kathey Marsden updated DERBY-1465: -- Summary: NetworkServerControl.start() should throw an exception and not just print exceptions if the server fails to start (was: NetworkServerControl.start() should throw an exception and not just print exceptions starting network server) NetworkServerControl.start() should throw an exception and not just print exceptions if the server fails to start Key: DERBY-1465 URL: http://issues.apache.org/jira/browse/DERBY-1465 Project: Derby Type: Bug Components: Network Server Versions: 10.1.2.1 Reporter: Kathey Marsden Priority: Minor NetworkServerControl.start() will not throw an exception if another server is already running on the same port.I am not sure but think perhaps this was changed at one point to accomodate the derby.drda.startNetworkServer property so that the embedded server could continue to boot even if the network server failed to start, but I think this is wrong for normal usage. http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] 10.1.3.1 release
+1 We have run a testcycle on 10.1.3.1 with tests as specified below on platforms as specified below. We did NOT discover any regressions. We saw only one new failure, as compared to tests on previous versions: filed as http://issues.apache.org/jira/browse/DERBY-1430 We do not regard this as a showstopper. All tests were run with both Sun jvm 1.5.0 and Sun jvm 1.4.2 Tests/testsuites run: demo derbyall derbylang derbynetclientmats derbynetmats derbytools encryptionAES encryptionAll encryptionBlowfish encryptionCFB encryptionDES encryptionECB encryptionOFB encryption i18nTest j9derbynetclientmats j9derbynetmats jdbc20 jdbcapi jdk14 multi nist propertyinfo simpledemo storeall storemats storemore storetests storeunit unit xa In addition some extra testing was done under jvm1.5: * JDBC compatibility-testing * Large Date Volume-testing Platforms used: Red Hat Enterprise Linux AS release 3 (Taroon Update 7) 64bits Linux 2.4.21-40.ELsmp #1 SMP Red Hat Enterprise Linux AS release 4 (Nahant Update 3) 64bits Linux 2.6.9-34.ELsmp #1 SMP Red Hat Enterprise Linux AS release 4 (Nahant Update 3) 32bits Linux 2.6.9-34.ELsmp #1 SMP Solaris 10 1/06 s10x_u1wos_19a X86 64bits SunOS 5.10 Generic_118844-26 Solaris 10 1/06 s10x_u1wos_19a X86 32bits SunOS 5.10 Generic_118844-26 Solaris 9 9/05 s9x_u8wos_05 x86 32bits SunOS 5.9 Generic_118559-23 Solaris 10 1/06 s10s_u1wos_19a SPARC 64bits SunOS 5.10 Generic_118822-25 Solaris Nevada snv_39 SPARC 64 bits SunOS 5.11 snv_39 Solaris 9 9/04 s9s_u7wos_09 SPARC 64bits SunOS 5.9 Generic_118558-08 Solaris 8 2/04 s28s_hw4wos_05a SPARC 64bits SunOS 5.8 Generic_117350-29 Windows Server 2003 Enterprise Edition Service Pack 1 Windows Server 2000 Advanced Server Windows XP Professional Service Pack 2 HP-UX B.11.11 U (only with HP jvm1.5) Details will be published on http://www.multinet.no/~solberg/public/Apache/index.html . -- With kind regards, Henri van de Scheur QA - Database Technology Group Sun Microsystems Trondheim
Re: Derby as desktop database
Bernt M. Johnsen wrote: Yes. But Angus' extra problem as I understand it, is that the apps will I apologize for spelling Andrus' name wrong. Sorry. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway signature.asc Description: OpenPGP digital signature
Re: [VOTE] 10.1.3.1 release
Andrew McIntyre [EMAIL PROTECTED] writes: Hello derby-dev, I have posted a new release candidate for 10.1.3 here: http://people.apache.org/~fuzzylogic/10.1.3.1/ +1 to make 10.1.3.1 an official release. I have tested the release candidates by running derbyall on the following platforms: 10.1.3.0 FreeBSD 6.1 (i386), Diablo 1.5.0_06 - no failures OpenBSD 3.9 (i386), J2SE 1.4.2 (SCSL + BSD patchset 7) - no failures OpenBSD 3.9 (i386), J2SE 5.0 (SCSL + BSD patchset 2) - forupdate (DerbyNetClient) - DERBY-1351 10.1.3.1 FreeBSD 6.1 (i386), J2SE 5.0 (SCSL + BSD patchset 3) - T_Diagnosticable: Shutting down due to unit test failure. NetBSD 3.0 (i386), J2SE 5.0 (SCSL + BSD patchset 3) - wisconsin (embedded, DerbyNet, DerbyNetClient) - DERBY-937 - NSinSameJVM (DerbyNet, DerbyNetClient) - test stopped after 1 hour - testSecMec (DerbyNet, DerbyNetClient) - test stopped after 1 hour - forupdate (DerbyNetClient) - DERBY-1351 - T_Diagnosticable: Shutting down due to unit test failure - JapanCodeConversion: IOException: native2ascii: not found I don't think any of these issues should stop the release. -- Knut Anders
[jira] Created: (DERBY-1466) Network Server should flush the PrintWriter after console output
Network Server should flush the PrintWriter after console output Key: DERBY-1466 URL: http://issues.apache.org/jira/browse/DERBY-1466 Project: Derby Type: Improvement Components: Network Server Versions: 10.1.2.1 Reporter: Kathey Marsden If Network Server is started with a PrintWriter specified for console output it will not automatically flush output such as starting the server. This can be confusing as the console output shows no activity. Users currently need to specify the PrintWriter to autoflush e.g. starterWriter = new PrintWriter(new FileOutputStream(new File(SERVER_START_LOG)),true); derbyServer = new NetworkServerControl(); derbyServer.start(starterWriter); For repro see: http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html And change the following line in the program to not autoflush as follows: starterWriter = new PrintWriter(new FileOutputStream(new File(SERVER_START_LOG)),false); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-1467) It would be useful to have a NetworkServerControl start API that took a timeout parameter
It would be useful to have a NetworkServerControl start API that took a timeout parameter -- Key: DERBY-1467 URL: http://issues.apache.org/jira/browse/DERBY-1467 Project: Derby Type: Improvement Components: Network Server Versions: 10.1.2.1 Reporter: Kathey Marsden Priority: Minor Applications starting network server using the API have to ping the server for some period of time to verify that it it came up and is ready for connections. It would be useful to provide a start API that has a timeout parameter and will ping for some period of time before throwing an exception if it cannot connect. Discussion in: http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Derby as desktop database
Not a problem :-) Yeah, I am looking for a solution that would work with a bunch of independent applications. Andrus On Jun 29, 2006, at 2:23 PM, Bernt M. Johnsen wrote: Bernt M. Johnsen wrote: Yes. But Angus' extra problem as I understand it, is that the apps will I apologize for spelling Andrus' name wrong. Sorry. -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
Re: [VOTE] 10.1.3.1 release
+1 to make 10.1.3.1 an official release. I have manually tested that DERBY-1058 has been fixed. -- Andreas
[jira] Updated: (DERBY-1351) lang/forupdate.sql fails with derbyclient in the 10.1 branch
[ http://issues.apache.org/jira/browse/DERBY-1351?page=all ] Fernanda Pizzorno updated DERBY-1351: - Attachment: derby-1351.diff derby-1351.stat I have run this test several times on Solaris, Linux, and Windows with low priority and I have not been able to reproduce the problem. The attached patch (derby-1351.diff) adds a property file for the test (forupdate_sed.properties) so as to filter the cursor names. I have successfully run lang/forupdate.sql tests with this patch. Can someone please review this patch? lang/forupdate.sql fails with derbyclient in the 10.1 branch Key: DERBY-1351 URL: http://issues.apache.org/jira/browse/DERBY-1351 Project: Derby Type: Bug Components: Test Versions: 10.1.2.5, 10.2.0.0 Environment: Windows 2000 and Sun jdk 15 Reporter: Rajesh Kartha Assignee: Fernanda Pizzorno Priority: Minor Fix For: 10.1.4.0 Attachments: derby-1351.diff, derby-1351.stat Derby 10.1 branch - 10.1.2.5 - (409283) *** Start: forupdate jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006-05-24 21:24:26 *** 333 del SQL_CURLH000C3 333a333 SQL_CURLH000C1 393 del SQL_CURLH000C3 393a393 SQL_CURLH000C1 Test Failed. *** End: forupdate jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006-05-24 21:24:41 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1351) lang/forupdate.sql fails with derbyclient in the 10.1 branch
[ http://issues.apache.org/jira/browse/DERBY-1351?page=all ] Fernanda Pizzorno updated DERBY-1351: - Derby Info: [Patch Available] lang/forupdate.sql fails with derbyclient in the 10.1 branch Key: DERBY-1351 URL: http://issues.apache.org/jira/browse/DERBY-1351 Project: Derby Type: Bug Components: Test Versions: 10.1.2.5, 10.2.0.0 Environment: Windows 2000 and Sun jdk 15 Reporter: Rajesh Kartha Assignee: Fernanda Pizzorno Priority: Minor Fix For: 10.1.4.0 Attachments: derby-1351.diff, derby-1351.stat Derby 10.1 branch - 10.1.2.5 - (409283) *** Start: forupdate jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006-05-24 21:24:26 *** 333 del SQL_CURLH000C3 333a333 SQL_CURLH000C1 393 del SQL_CURLH000C3 393a393 SQL_CURLH000C1 Test Failed. *** End: forupdate jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006-05-24 21:24:41 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] 10.1.3.1 release
Kathey Marsden wrote: Andrew McIntyre wrote: Hello derby-dev, I have posted a new release candidate for 10.1.3 here: http://people.apache.org/~fuzzylogic/10.1.3.1/ +1. No unknown failures found. I ran the derbyall suite and other tests on the following platforms: OS: Red Hat Enterprise Linux AS release 4 (Nahant) Linux 2.6.9-5.ELsmp and Red Hat Enterprise Linux ES release 4 (Nahant Update 3) Linux 2.6.9-34.0.1.ELsmp Java: 1) Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a (with and without -Xjit:count=0) Failures related to DERBY-1221 2) java version 1.5.0_07 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode) (with and without -server option) No failures OS:
[jira] Commented: (DERBY-1465) NetworkServerControl.start() should throw an exception and not just print exceptions if the server fails to start
[ http://issues.apache.org/jira/browse/DERBY-1465?page=comments#action_12418481 ] John H. Embretsen commented on DERBY-1465: -- The relationship between the Network Server API and the derby.drda.startNetworkServer property (and its related functionality) is indeed puzzling. See my comment to DERBY-1326 (June 16th), particularly observation b), for another example: http://issues.apache.org/jira/browse/DERBY-1326#action_12416494 NetworkServerControl.start() should throw an exception and not just print exceptions if the server fails to start Key: DERBY-1465 URL: http://issues.apache.org/jira/browse/DERBY-1465 Project: Derby Type: Bug Components: Network Server Versions: 10.1.2.1 Reporter: Kathey Marsden Priority: Minor NetworkServerControl.start() will not throw an exception if another server is already running on the same port.I am not sure but think perhaps this was changed at one point to accomodate the derby.drda.startNetworkServer property so that the embedded server could continue to boot even if the network server failed to start, but I think this is wrong for normal usage. http://www.nabble.com/Questions-about-Network-Server-API-Behavior-p5055814.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-822) Client driver: Pre-fetch data on executeQuery()
[ http://issues.apache.org/jira/browse/DERBY-822?page=all ] Kathey Marsden updated DERBY-822: - Derby Info: [Existing Application Impact, Release Note Needed] (was: [Patch Available]) RELEASE NOTE: Pre-fetching with Network Client/Server is a performance optimization that eliminates a round trip to the server. Essentially the first ResultSet next() call is executed on the Statement executeQuery() or execute(). Applications are typically prepared to handle this but the following issue may be seen, PROBLEM Queries may fail earlier and locks may be aquired earlier when executing queries. Location where errors occur embedded environment is different. SYMPTOM Errors that happen as part of the normal execution path are moved earlier. For example, code to execute a query, with executeQuery() retrieve the result set metadata and then perform a next() might fail with a lock timeout on executeQuery() instead of next(). Locking changes are observed. CAUSE Pre-fetching moves execution of retrieval of data earlier for network client/server configurations. SOLUTION This was an intentional behavior change to improve performance. No Derby product solution is offered. WORKAROUND Application code needs to be changed to adjust error handling if needed. Client driver: Pre-fetch data on executeQuery() --- Key: DERBY-822 URL: http://issues.apache.org/jira/browse/DERBY-822 Project: Derby Type: Improvement Components: Network Server, Performance Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-822-v1.diff, DERBY-822-v1.stat, DERBY-822-v2.diff, DERBY-822-v2.stat, DERBY-822-v3.diff, DERBY-822-v3.stat Currently, the client driver does not pre-fetch data when executeQuery() is called, but it does on the first call to ResultSet.next(). Pre-fetching data on executeQuery() would reduce network traffic and improve performance. The DRDA protocol supports this. From the description of OPNQRY (open query): The qryrowset parameter specifies whether a rowset of rows is to be returned with the command. This is only honored for non-dynamic scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming to the limited block query protocol. The target server fetches no more than the requested number of rows. It may fetch fewer rows if it is restricted by extra query block limits, or if a fetch operation results in a negative SQLSTATE or an SQLSTATE of 02000. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-822) Client driver: Pre-fetch data on executeQuery()
Kathey Marsden (JIRA) wrote: Location where errors occur embedded environment is different. I guess something went wrong when writing this sentence ... -- Øystein
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
Sanket Sharma wrote: This sounds like a perfect case for JMX soultion and can be added to list of requirements on derby Wiki. Tracing options (enable/disable) The requirement for this is that we have something that can be turned on quickly by the user when talking to tech support so we can easily get the traces produced and back for analysis without the need to download any additional software or libraries. I am sure it would be much more helpful if I knew something about JMX, but given those requirements, would JMX work for this? Kathey
Re: [jira] Updated: (DERBY-822) Client driver: Pre-fetch data on executeQuery()
Øystein Grøvlen wrote: Kathey Marsden (JIRA) wrote: Location where errors occur embedded environment is different. Maybe The location where errors occur in client/server environments is different than embedded. ? I had an example of how a user that called executeQuery(), retrieved ResultSet metadata and then called next() would never see the metadata call made and would see an error typically expected on next() to show up during executeQuery() but I went with for brevity in the end bit cut out too much. Please make adjustments as you see fit. Kathey
Re: MySQL to Derby Migration Tool
Thanks, Ramin, no further comments or issues, I look forward to your next revision. David Ramin Moazeni wrote: Hi David, Thanks for your comments. My comments inline Thanks, Ramin On 6/27/06, David Van Couvering [EMAIL PROTECTED] wrote: Hi, Ramin. Great document! Very nicely done. Here are my comments: - You're a UML use case guy. Great! Wish there was more of that in software design, especially for tools. - What's the mapping from MySql YEAR to Derby? Derby does not seem to have a YEAR data type. We can probably use INTEGER insteadAny thoughts? - Can you explain a little more how DdlUtils takes care of data type mapping? ddlutils tool uses JDBC datatypes rather than SQL datatypes which are database dependent. Looking at http://db.apache.org/ddlutils/database-support.html, explains mapping between JDBC types and SQL types. For example, a TIINYINT datatype from MySQL, will be mapped to SMALLINT in Derby. I will explain this in detail in the document. - Can you explain a little more what you mean by A possible solution would be to execute database-specific commands to capture required information. when you say DdlUtils doesn't support constraints, triggers, stored procedures, etc. In the case of MySQL, we can use the SHOW command to capture the exact string to re-create the original object. For example SHOW CREATE PROCEDURE or SHOW CREATE FUNCTION can be used to capture the original statement used to create function/procedure. I will add these information to the document. - I guess I don't follow the application flow very well when using DdlUtils. What exactly are the steps taken by the user and/or the tool using DdlUtils? I probably need another usecase diagram for ddlutils. I will add that to the document. - What is *your* recommended approach (DatabaseMetadata vs. DdlUtils) and why? I would think a combination of ddlutils and DatabaseMetadata approach is needed to handle cases not supported by ddlutils like stroed procedures. I will add a section to the document on this. - Can you talk more to what happens if there is an error during migration at various phases. What steps does the tool take to set things right? Can you end up with a half-created database? What do you do to fix the errors and start over? I suspect migration is often a repetitive effort as you catch migration/mapping errors, fix things, and try again... This should be as painless as possible. Sure, I will add this information as well. - Can you please show the proposed syntax and other details (input files, config files, env variables, exit status) for the CLI? Ok. - Does the CLI have a headless mode (e.g. no interactive prompts) so you can run it in a script? Good suggestion.I was not thinking about CLI with headless mode. I will add information on this. - What is the syntax for starting the tool? Will you make use of derbyrun.jar? I will need to investigate this. - Can you cover quickly how you'll address internationalizing the GUI? Sure - Can you explain briefly how, using this architecture, you can plug in other data sources besides MySQL? Ok. - You might want to touch on the impact to existing JDBC applications that are running against MySQL, which you want to migrate to Derby. How are *those* migrated, and how much or how little does this tool help with that? If anything, just make it clear that application migration is out of the scope of this tool. Ok - What mechanism are you going to use to do the data transfer? Simple JDBC inserts? Bulk insert? For large databases the mechanism you use can have a large impact on performance, and may actually prevent some databases from migrating. It would be good to have a section on performance and what approaches you will take to improve performance and test performance. I will add a section on performance. - What about migration of users, groups, permissions, etc. -- is that out of scope? Good suggestionI did not think about this. I will add it to the docuemtn - Perhaps it would be good to be *very* explicit about what you plan to migrate and what you *don't* plan to migrate in this tool, and what you recommend for users for the bits that aren't being migrated (applications, authorizations, triggers, whatever is on that list). Ok - This may not be your itch to scratch, but can you address what you're planning to do to (or not do) to address governmental accessibility requirements (called Section 508)? See http://java.sun.com/products/jfc/accessibility/index.jsp. At a minimum it would be great if you don't do anything that makes it difficult for someone else to make the tool accessible. Ok. I will look into this. Thanks! David Ramin Moazeni wrote: Hello, I am a Google Summer of code participant working on the Derby Migration tool project. The High level design document is posted at http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument There are 2 approaches
Re: Synchronization on the connection in JDBC calls
Kristian Waagan wrote: I think a single connection is not expected to be shared between multiple threads simultaneously. Maybe the necessary synchronization is done at a lower level in the system. This is not intended to be a complete answer, and perhaps I'm misunderstanding the thrust of your question, but I thought this quote from Appendix A of the old JDBC reference manual might be relevant/helpful: Since Java is a multithreaded environment, there seems to be no real need to provide support for asynchronous statement execution. Java programmers can easily create a separate thread if they wish to execute statements asynchronously with respect to their main thread. Some drivers may allow more concurrent execution than others, but developers should be able to assume fully concurrent execution. If the driver requires some form of synchronization, then the driver should provide it. In this situation, the only difference visible to the developer should be that applications run with reduced concurrency. For example, two Statement objects on the same connection can be executed concurrently, and their ResultSets can be processed concurrently (from the perspective of the developer). Some drivers will provide this full concurrency. Others may execute one statement and wait until it completes before sending the next one. My feeling is that the Derby implementation should strive to allow the greatest concurrency possible, but should perform the necessary synchronization automatically. thanks, bryan
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
IMHO, this is exactly the kind of thing JMX is suited for. David Kathey Marsden wrote: Sanket Sharma wrote: This sounds like a perfect case for JMX soultion and can be added to list of requirements on derby Wiki. Tracing options (enable/disable) The requirement for this is that we have something that can be turned on quickly by the user when talking to tech support so we can easily get the traces produced and back for analysis without the need to download any additional software or libraries. I am sure it would be much more helpful if I knew something about JMX, but given those requirements, would JMX work for this? Kathey
Re: [VOTE] 10.1.3.1 release
Andrew McIntyre wrote: Hello derby-dev, I have posted a new release candidate for 10.1.3 here: http://people.apache.org/~fuzzylogic/10.1.3.1/ +1 for this release. I have tested the release candidates with some simple performance tests with 1.4.2 vm on windows and linux and it looks good to me. Thanks, Sunitha.
Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Andreas Korneliussen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-937?page=all ] Andreas Korneliussen updated DERBY-937: --- Attachment: DERBY-937.diff DERBY-937.stat I was able to reproduce this problem on every run on a very fast laptop (it was not reproducible on any other Windows lab machine I have tried). This laptop happens to be the same kind as Ole uses for the nightly tests. Adding a 10 second sleeping period after the population of the tables, did not have any effect. I therefore tried to do run a compress on the tables (based on the assumption that statistics is updated on compress), and now the test does not fail for me anymore. Attached is the patch which makes this test stop failing. The patch does not seem to have any sideeffects on other platforms (Solaris) tested, however the test will use more time. It is great that this fixes the problem on your reproducible case, I say we should commit. But I don't know why it does. To me it looks like the loader program always first inserts all the data into the base tables and then creates the indexes. In this case Derby automatically creates the statistics that you mention here, and they should be no different than what is recreated when you do the compress. Also derby will create packed indexes in this case which again should look no different than what compress will do (since all that has happened are inserts into the table - if deletes or updates were involved it would be a different story). What the change does do is alter the cache a lot, and alter the I/O timing a lot. Also I wanted to again make sure people understand what statistics mean in derby. What is usually called statistics in other db's comes in 3 forms in derby: 1) key distribution information o this is automatically maintained by derby by using existing indexes, no user interaction is ever needed and it is always up to date. Basically we use the index itself to estimate a given number of rows for a range of keys. Most other db's I know require some sort of update statistics to get this info. 2) base table row counts o also automatically maintained by derby, but can be slightly out of date as it is only an estimate for performance reasons. Row counts are updated at insert/delete time on a per page basis automatically, but we delay the rollup. The rollup is done always when the page goes to disk. The rollup may also be done earlier if the change is significant to the total - I think if delta is 10% or more of the table. The row count estimate is also updated if they system ever happens to do a full scan on the table. 3) cardinality statistic This is basically one number which is the average number of duplicate keys for a given key, where key is a leading set of columns in an index. So a one key index has one number and an index with 3 columns (a, b, c) has 3 numbers indicating the cardinality of (a), (a, b) and (a, b, c). o This statistic is automatically created when an index is created, and also when a number of bait/switch ddl operations are done like compress table. There have been a number of discussions on the list on how to automate the update of this. My opinion is that we should attack it in the following 3 ways: o provide a way for users to schedule it to be calculated, other than by running compress. Not greate for a zero-admin - just a work around until we can better automate it. The code exists, just not shown through to users right now. o Develop a back ground zero-admin component which would programtically figure out how and when to schedule this kind of activity. o see if there is any smart quick way to estimate the values automatically by doing some statistical analysis of the the btree leaf pages.
Re: Derby as desktop database
Andrus Adamchik wrote: Not a problem :-) Yeah, I am looking for a solution that would work with a bunch of independent applications. Andrus Just to understand is the reason network server solution is not ok performance? Or is the problem that you don't want to have to start a server up just in case one of the independent apps wants it?
[jira] Updated: (DERBY-1410) SQL State DATA_SQLDATA_READ_ILLEGAL_ACCESS_EXCEPTION does not have a matching message
[ http://issues.apache.org/jira/browse/DERBY-1410?page=all ] Mike Matrigali updated DERBY-1410: -- Fix Version: 10.2.0.0 Assign To: Mike Matrigali SQL State DATA_SQLDATA_READ_ILLEGAL_ACCESS_EXCEPTION does not have a matching message - Key: DERBY-1410 URL: http://issues.apache.org/jira/browse/DERBY-1410 Project: Derby Type: Bug Components: Store Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4, 10.1.2.5, 10.1.4.0 Reporter: David Van Couvering Assignee: Mike Matrigali Fix For: 10.2.0.0 This SQL State is used by the class impl.store.raw.data.StoredPage in three different places, but there is no message for XSDAN.S. Uncovered by the i18n/MessageBundleTest recently checked in. The MessageBundleTest master file shows this is as having no matching message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-1410) SQL State DATA_SQLDATA_READ_ILLEGAL_ACCESS_EXCEPTION does not have a matching message
[ http://issues.apache.org/jira/browse/DERBY-1410?page=all ] Mike Matrigali resolved DERBY-1410: --- Resolution: Fixed m1_142:88svn commit Sendingjava\engine\org\apache\derby\loc\messages_en.properties Transmitting file data . Committed revision 418095. SQL State DATA_SQLDATA_READ_ILLEGAL_ACCESS_EXCEPTION does not have a matching message - Key: DERBY-1410 URL: http://issues.apache.org/jira/browse/DERBY-1410 Project: Derby Type: Bug Components: Store Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4, 10.1.2.5, 10.1.4.0 Reporter: David Van Couvering Assignee: Mike Matrigali Fix For: 10.2.0.0 This SQL State is used by the class impl.store.raw.data.StoredPage in three different places, but there is no message for XSDAN.S. Uncovered by the i18n/MessageBundleTest recently checked in. The MessageBundleTest master file shows this is as having no matching message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Derby as desktop database
This is the later - I don't want the users to start the server. BTW, I just prototyped a simple distributed peer-to-peer DataSource [1]. In my tests I can run about 7 parallel processes on my MacBook laptop that access the same database non-stop (each doing a select, then insert, then going to sleep for 2 seconds). When I started more processes, timeouts and errors start to occur, but playing with the DataSource parameters can increase the concurrency. Not ideal but works. I may clean this up in the future, removing Cayenne EventManager dependency, coding it straight to the JavaGroups API. Comments? Andrus [1] http://svn.apache.org/repos/asf/incubator/cayenne/sandbox/derby- pool/ On Jun 29, 2006, at 6:25 PM, Mike Matrigali wrote: Andrus Adamchik wrote: Not a problem :-) Yeah, I am looking for a solution that would work with a bunch of independent applications. Andrus Just to understand is the reason network server solution is not ok performance? Or is the problem that you don't want to have to start a server up just in case one of the independent apps wants it?
Re: [VOTE] 10.1.3.1 release
+1 for this release I have tested 10.1.3 release candidate on Windows Server 2003 and Linux Suse 9.2. Summary and details of testing are as following: Summary -Mostly known failures - Some failures which passed on rerun Details Windows Server 2003 ibm142 --- JVM: ibm142, Suite: derbyall java version 1.4.2Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cn142-20060421 (SR5) (JIT enabled: jitc)) Test Results: - Some failures which passed on rerun ibm15 with and without xjit option --- JVM: ibm15, Suite: derbyall java version 1.5.0Java(TM) 2 Runtime Environment, Standard Edition (build pwa64dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows Server 2003 amd64-64 j9vmwa6423-20060504 (JIT enabled)J9VM - 20060501_06428_LEdSMrJIT - 20060428_1800_r8GC - 20060501_AA)JCL - 20060511a Test Results: -Mostly known failures - Some failures which passed on rerun Suse 9.2 ibm142 --- JVM: ibm142, Suite: derbyall java version 1.4.2Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20050929 (SR3) (JIT enabled: jitc)) Test Results: - All passed ibm15 with and without xjit option --- JVM: ibm15, Suite: derbyall java version 1.5.0Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20060511 (SR2))IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20060504 (JIT enabled)J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8GC - 20060501_AA)JCL - 20060511a Test Results: -Mostly known failures - Some failures which passed on rerun -- Ramandeep Kaur[EMAIL PROTECTED]
Re: svn commit: r418095 - /db/derby/code/trunk/java/engine/org/apache/derby/loc/messages_en.properties
On 6/29/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+XSDAN.S=Exception during restore of a SQLData object of class {0}. The
specified class cannot be encountered an illegal access exception.
Typo? Looks like the 'cannot be' snuck in by accident.
andrew
[jira] Updated: (DERBY-937) Instability in wisconsin test
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ] Mike Matrigali updated DERBY-937: - Fix Version: 10.2.0.0 committed Instability in wisconsin test - Key: DERBY-937 URL: http://issues.apache.org/jira/browse/DERBY-937 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.1.2.4 Reporter: Rick Hillegas Assignee: Andreas Korneliussen Fix For: 10.2.0.0 Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat The lang/wisconsin.java test prints out query plans. These plans differ depending on your platform. When run under cygwin on xp, the plans vary from the canonized results. I am seeing this instability in my own test environment and in the tinderbox tests against cygwin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-937) Instability in wisconsin test
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ] Mike Matrigali updated DERBY-937: - committed change to trunk: r418108 | mikem | 2006-06-29 11:27:51 -0700 (Thu, 29 Jun 2006) | 16 lines DERBY-937, committing change by Andreas Korneliussen. notes by Andreas: I was able to reproduce this problem on every run on a very fast laptop (it was not reproducible on any other Windows lab machine I have tried). This laptop hap pens to be the same kind as Ole uses for the nightly tests. Adding a 10 second sleeping period after the population of the tables, did not h ave any effect. I therefore tried to do run a compress on the tables (based on t he assumption that statistics is updated on compress), and now the test does not fail for me anymore. Attached is the patch which makes this test stop failing. The patch does not see m to have any sideeffects on other platforms (Solaris) tested, however the test will use more time. note by mike: I ran this change 20 times and it worked on my laptop, it would always fail a few times out of 20 before the fix. I am not sure why this fix works as the test seems to already create indexes after tables so statistics should already be up to date. Instability in wisconsin test - Key: DERBY-937 URL: http://issues.apache.org/jira/browse/DERBY-937 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.1.2.4 Reporter: Rick Hillegas Assignee: Andreas Korneliussen Fix For: 10.2.0.0 Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat The lang/wisconsin.java test prints out query plans. These plans differ depending on your platform. When run under cygwin on xp, the plans vary from the canonized results. I am seeing this instability in my own test environment and in the tinderbox tests against cygwin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] 10.1.3.1 release
On 6/26/06, Andrew McIntyre [EMAIL PROTECTED] wrote: Hello derby-dev, I have posted a new release candidate for 10.1.3 here: http://people.apache.org/~fuzzylogic/10.1.3.1/ +1 for my part. On the 10.1.3.0 version I ran: - Sun's j2ee cts suite (jdbc part only) with IBM jcc 2.6 (90) (all tests passed), - derbyall and a few extra tests on a: Red Hat Enterprise Linux AS release 4 (Nahant Update 3) Kernel 2.6.9-34.ELsmp on an x86_64 (i.e. 64 bit) with sun jvm 15: Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_04-b05, mixed mode) and with ibm jvm 15: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20060511 (SR2)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20060504 (JIT enabled) J9VM - 20060501_06428_lHdSMR JIT - 20060428_1800_r8 GC - 20060501_AA) JCL - 20060511a b. Windows 2000 (32 bit) and found no bugs that way in the derby code. On 10.1.3.1 I reran derbyall (and the extra tests) again with ibm jvm 15 found no failures different than the earlier run, except for lang/triggerGeneral.sql, which passed when rerun by itself.
[jira] Resolved: (DERBY-937) Instability in wisconsin test
[ http://issues.apache.org/jira/browse/DERBY-937?page=all ] Mike Matrigali resolved DERBY-937: -- Resolution: Fixed I am closing this intermittent bug with fix committed as: 418108. If it shows up again file a new issue with the new details. Instability in wisconsin test - Key: DERBY-937 URL: http://issues.apache.org/jira/browse/DERBY-937 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.1.2.4 Reporter: Rick Hillegas Assignee: Andreas Korneliussen Fix For: 10.2.0.0 Attachments: 10.1_05_05_06_failure.zip, DERBY-937.diff, DERBY-937.stat The lang/wisconsin.java test prints out query plans. These plans differ depending on your platform. When run under cygwin on xp, the plans vary from the canonized results. I am seeing this instability in my own test environment and in the tinderbox tests against cygwin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] 10.1.3.1 release
+1 for 10.1.3 RC2 1. I had run the derbyall on AIX 5.2 with both IBM JDK142 and IBM JDK1.5(With and without -Xjit:count=0 option). 2. Ran some system/stress test and the RC1 ran for more than a week without any major issues (other than the known IBM1.5 issue, DERBY-1280) and RC2 for 3 days. 3. Also ran some preliminary tests on IPV6 machines and would like to have the comments posted for DERBY-282 and DERBY-526 to be inlcluded in the Release Notes. Thanks Manjula
upcoming 10.2 release and regression test failures.
There are currently 24 regression test failures listed in jira, I think most apply to the trunk. Only one of them has anyone working on it. I took a quick look at categorizing them. It seems like we should at least spend some time on the mainline jvm (1.4, 1.5, 1.6) issues verifying that problem is not likely a regression for the 10.2 release before going GA. I know I waste time every time I have to figure out if the test failure I encounterd is one of the growing set of expected failures or not. Fixing them now rather than during the RC vetting period would make it more likely we could make the dates Rick is aiming at. Note this is just the regression test category, has anyone done any review of the outstanding derby bugs and what would be appropriate to fix before 10.2 goes GA? mailine jvm DERBY-1430 Test parameterMapping.java often fails DerbyNetClient on Solarisx86 DERBY-1404 i18nTest/iepnegativetests_ES and derbytools/iepnegativetests fails with ibm142 on linux DERBY-1403 importExport.java fails with ibm142 on linux DERBY-1320 Test lang/procedure.java fails with ibm1.5 jvm DERBY-1108 The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5 DERBY-1022 syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128) DERBY-988 jdbcapi/parameterMapping.java fails on Win2003 with 'P3=SQLSTATE(22007): SQL Exception: The syntax of the string representation of a datetime value is incorrect.' DERBY-980 derbynet/testSecMec.java fails with InterruptedException DERBY-957 Long passed into an exception gets displayed using locale specific formatting. i18n/locale issue DERBY-952 DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin compat testing: DERBY-1084 jdbcapi/xaStateTran test fails with 10.1 client and derbyTesting.jar with 10.2 server. DERBY-1083 jdbcapi/xaSimplePositive fails with 10.1 derbyTesting.jar and 10.1 c lient with 10.2 server. intermittent (anyone have a spare machine they can run test repeatedly over a weekend to give us an idea how intermittent?) DERBY-1248 Assert failure in BasePage.shiftUp() when running store/onlineBackup Test4.sql DERBY-1237 unit/daemonService fails intermittently with Shutting down due to unit test failure. DERBY-989 unit/daemonService.unit fails intermittently: 'ran out of time' DERBY-973 Restore fails in OnlineBackupTest1 DERBY-967 lang/autoincrement.sql intermittently fails on SunOS-5.10_i86 DERBY-803 derbynet/DerbyNetAutoStart.java test fails intermittently with org.a pache.derby.iapi.services.context.ShutdownException DERBY-1418 derbyall/storeall/storemore/OnlineBackupTest3 failed, unable to reproduce DERBY-1419 MessageBundleTest.diff test failed in nightly run, jdk15 o i think should be taken off regression test list, was removed from suite old jvm: DERBY-1407 encryptionAll.fail:store/access.sql hangs on ibm1.3.1 while running the blowfish test run DERBY-1153 derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3 not mainline jvm: DERBY-1457 lang/triggerGeneral.sql fails intermittently with wsdd 5.6 DERBY-1179 demo/RunClassPathTester.java fails against IBM wsdd5.6
Re: [VOTE] 10.1.3.1 release
Andrew McIntyre wrote: Hello derby-dev, I have posted a new release candidate for 10.1.3 here: http://people.apache.org/~fuzzylogic/10.1.3.1/ +1 Ran with the Derby tut at http://db.apache.org/derby/papers/DerbyTut as well as the old ApacheCon 2004 tutorial at http://db.apache.org/derby/papers/fortune_tut.html (ran the SQL test that verifies the SQL functions still work that call the Jakarta math and regexp libs). -jean
[jira] Updated: (DERBY-1017) locking issue with a select statement using an order by clause
[ http://issues.apache.org/jira/browse/DERBY-1017?page=all ]
Mike Matrigali updated DERBY-1017:
--
Component: SQL
(was: Network Server)
The most recent comment says this reproduces in embedded, so not a network
server issue. Setting to SQL as that is the next most likely area (though
behavior may be expected - need to look at test).
locking issue with a select statement using an order by clause
--
Key: DERBY-1017
URL: http://issues.apache.org/jira/browse/DERBY-1017
Project: Derby
Type: Bug
Components: SQL
Versions: 10.0.2.0
Environment: Windows XP Professional operating system and Java2 platform
using JDK 5.0
Reporter: Mark H. Kaplan
Attachments: derbyLocking.zip
I am using the network version of Derby (version 10 - the network version). I
am running two threads. The first thread is doing an insert into a table but
not committing. The second table is doing a select statement. When the select
statement has an order by clause, it will not complete but when it does not
have the order by clause, it completes while the first thread is sleeping.
The database contains one table with five columns. I have tried having an
index on the order by column but that does not seem to make a difference. I
have not set any isolation level on the database so it is using the default
of TRANSACTION_READ_COMMITTED.
The insert statement in the first thread looks like:
INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract) VALUES
('999-99-', 'last', 'first', 'xxx-', 0)
The select statement in the second thread looks like:
SELECT au_id, au_lname, au_fname, phone, contract FROM authors where au_lname
= 'xxx' ORDER BY au_fname
MORE INFORMATION --
My order by select statement does timeout with the error 40XL1. I tried
putting an index on the au_fname but that did not make a difference
I have included locking data which I retrieved by running a SELECT * FROM
NEW org.apache.derby.diag.LockTable() AS LT while the second thread was
doing its SELECT statement. I do not understand the data but I thought that
it might give you a better idea of what is going on. I have also included the
database sql script that creates the database table and the two sql
statements that I am running in separate threads to give you a better idea of
what I am doing. Let me know if you need any other information:
(Locking Data)
XID |TYPE |MODE |TAB |LOCK |STATE |TABLETYPE |LOCK |INDEXNAME
===
302 |ROW |X |AUTHORS |(2,18) |GRANT |T |1 |null
302 |ROW |X |AUTHORS |(1,7) |GRANT |T |1 |null
304 |ROW |S |AUTHORS |(1,7) |WAIT |T |0 |null
302 |TABLE |IX |AUTHORS |Tablelock |GRANT |T |3 |null
304 |TABLE |IS |AUTHORS |Tablelock |GRANT |T |1 |null
(SQL Script)
DROP TABLE authors;
CREATE TABLE authors (
au_id VARCHAR(32) NOT NULL,
au_lname VARCHAR(40) ,
au_fname VARCHAR(20) ,
phone VARCHAR(12) ,
contract INT NOT NULL,
PRIMARY KEY (au_id)
);
CREATE INDEX firstnameindex ON authors (au_fname);
(SQL Statements)
Thread 1 - INSERT INTO Authors (au_id, au_lname, au_fname, phone, contract)
VALUES ('999-99-', 'last', 'first', 'xxx-', 0)
Thread2 - SELECT au_id, au_lname, au_fname, phone, contract FROM authors
where au_lname = 'xxx' ORDER BY au_fname
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1453) jdbcapi/blobclob4BLOB.java fails with 10.1 client and 10.2 server
[ http://issues.apache.org/jira/browse/DERBY-1453?page=all ] Mike Matrigali updated DERBY-1453: -- Component: Network Client Network Server jdbcapi/blobclob4BLOB.java fails with 10.1 client and 10.2 server - Key: DERBY-1453 URL: http://issues.apache.org/jira/browse/DERBY-1453 Project: Derby Type: Test Components: Network Client, Network Server Versions: 10.1.3.0, 10.2.0.0 Environment: derbyclient.jar and derbyTesting.jar from 10.1 all other jars from 10.2 Reporter: Deepa Remesh Priority: Critical Fix For: 10.2.0.0 Diff is: *** Start: blobclob4BLOB jdk1.5.0_02 DerbyNetClient derbynetmats:jdbcapi 2006-06-23 02:09:39 *** 510a511,513 FAIL -- unexpected exception SQLSTATE(40XL1): A lock could not be obtained within the time requested START: clobTest93 512,513d514 START: clobTest93 clobTest92 finished 766 del EXPECTED SQLSTATE(XCL30): An IOException was thrown when reading a 'java.sql.String' from an InputStream. SQLSTATE: XJ001: Java exception: 'ERROR 40XD0: Container has been closed: java.io.IOException'. 766a767 EXPECTED SQLSTATE(XJ073): The data in this BLOB or CLOB is no longer available. The BLOB or CLOBs transaction may be committed, or its connection is closed. 769 del EXPECTED SQLSTATE(XCL30): An IOException was thrown when reading a 'BLOB' from an InputStream. SQLSTATE: XJ001: Java exception: 'ERROR 40XD0: Container has been closed: java.io.IOException'. 769a770 EXPECTED SQLSTATE(XJ073): The data in this BLOB or CLOB is no longer available. The BLOB or CLOBs transaction may be committed, or its connection is closed. Test Failed. *** End: blobclob4BLOB jdk1.5.0_02 DerbyNetClient derbynetmats:jdbcapi 2006-06-23 02:10:20 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Synchronization on the connection in JDBC calls
Kristian Waagan wrote:
Hello,
When working on EmbedPreparedStatement.java, I noticed that a few
methods synchronize on the connection object, for instance addBatch. The
code typically looks like this:
synchronized (getConnectionSynchronization()) {
// Do stuff
}
The getConnectionSynchronization-method returns a reference to the root
connection. I also saw that EmbedResultSet uses this more.
The rest of the JDBC methods in EmbedPreparedStatement don't synchronize
on this object.
I think a single connection is not expected to be shared between
multiple threads simultaneously. Maybe the necessary synchronization is
done at a lower level in the system.
Would anyone care to share their thoughts/knowledge on this issue?
In addition to what Bryan's correct reply, I'd add that the Derby
embedded engine requires this high level synchronization. The internals
depend on the fact that only a single thread can be active in a context
manager/language connection context at any time. A thread becomes active
in a context manager/language connection context when it enters the JDBC
api and inactive when it leaves the JDBC thread. This is shown in slides
18,19,20 33,34 of
http://db.apache.org/derby/binaries/ApacheDerbyInternals_1_1.pdf
There are some unsynchronized calls through the JDBC layer,where one can
demonstrate that:
- no unxpected exceptions (E.g. NPE, IndexOfOutBounds) will be thrown
due to potential concurrent access of any JDBC objects owned by the same
connection.
- no incorrect behaviour will occur (e.g. wrong results) due to
potential concurrent access of objects owned by the same connection.
Dan.
Dan.
[jira] Updated: (DERBY-1450) jdbcapi/parameterMetaDataJdbc30.java fails with 10.1 client and 10.2 server
[ http://issues.apache.org/jira/browse/DERBY-1450?page=all ] Mike Matrigali updated DERBY-1450: -- Component: Test jdbcapi/parameterMetaDataJdbc30.java fails with 10.1 client and 10.2 server --- Key: DERBY-1450 URL: http://issues.apache.org/jira/browse/DERBY-1450 Project: Derby Type: Test Components: Test Versions: 10.1.3.0, 10.2.0.0 Environment: derbyclient.jar and derbyTesting.jar from 10.1 all other jars from 10.2 Reporter: Deepa Remesh Test fails with following exception: SQLSTATE(22019):org.apache.derby.client.am.SqlException: Invalid escape sequence, ''. The escape string must be exactly one character. It cannot be a null or more than one character. at org.apache.derby.client.am.Statement.completeSqlca(Statement.java:1371) at org.apache.derby.client.net.NetStatementReply.parseOpenQueryError(NetStatementReply.java:605) at org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply(NetStatementReply.java:229) at org.apache.derby.client.net.NetStatementReply.readOpenQuery(NetStatementReply.java:56) at org.apache.derby.client.net.StatementReply.readOpenQuery(StatementReply.java:49) at org.apache.derby.client.net.NetStatement.readOpenQuery_(NetStatement.java:151) at org.apache.derby.client.am.Statement.readOpenQuery(Statement.java:1038) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:1396) at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:893) at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:884) at org.apache.derbyTesting.functionTests.tests.jdbcapi.parameterMetaDataJdbc30.main(parameterMetaDataJdbc30.java:146) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1387) Add JMX extensions to Derby
[ http://issues.apache.org/jira/browse/DERBY-1387?page=all ] Mike Matrigali updated DERBY-1387: -- Component: Services for lack of a better component made it services. Add JMX extensions to Derby --- Key: DERBY-1387 URL: http://issues.apache.org/jira/browse/DERBY-1387 Project: Derby Type: New Feature Components: Services Reporter: Sanket Sharma Assignee: Sanket Sharma Attachments: Requirements for JMX Updated.html, Requirements for JMX.html, Requirements for JMX.zip This is a draft requirement specification for adding monitoring and management extensions to Apache Derby using JMX. The requirements document has been uploaded on JIRA as well as the Derby Wiki page at http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX Developers and Users are requested to please look at the document (feature list in particular) and add their own rating to features by adding a coloumn to the table. Comments are welcome. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1452) jdbcapi/resultset.java fails with 10.1 client and 10.2 server
[ http://issues.apache.org/jira/browse/DERBY-1452?page=all ] Mike Matrigali updated DERBY-1452: -- Component: Test jdbcapi/resultset.java fails with 10.1 client and 10.2 server - Key: DERBY-1452 URL: http://issues.apache.org/jira/browse/DERBY-1452 Project: Derby Type: Test Components: Test Versions: 10.2.0.0, 10.1.3.0 Environment: derbyclient.jar and derbyTesting.jar from 10.1 all other jars from 10.2 Reporter: Deepa Remesh Priority: Minor Attachments: resultset.out Diff is: *** Start: resultset jdk1.5.0_02 DerbyNetClient derbynetmats:jdbcapi 2006-06-23 02:07:01 *** 1467,1468d1466 COL1(datatype : CHAR, precision : 60, scale : 0) 1471,1472d1468 COL1(datatype : CHAR, precision : 60, scale : 0) 1475,1476d1470 COL1(datatype : CHAR, precision : 60, scale : 0) 1517,1518d1510 COL1(datatype : VARCHAR, precision : 60, scale : 0) --- 1521,1522d1512 COL1(datatype : VARCHAR, precision : 60, scale : 0) --- 1525,1526d1514 COL1(datatype : VARCHAR, precision : 60, scale : 0) --- 1732a1721,1734 Data Conversion SQLException SELECT NULLIF(DATECOL,VARCHARCOL) from AllDataTypesTable Data Conversion SQLException SELECT NULLIF(DATECOL,LONGVARCHARCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'LONG VARCHAR' are not supported. SELECT NULLIF(DATECOL,CHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'CHAR () FOR BIT DATA' are not supported. SELECT NULLIF(DATECOL,VARCHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'VARCHAR () FOR BIT DATA' are not supported. SELECT NULLIF(DATECOL,LVARCHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'LONG VARCHAR FOR BIT DATA' are not supported. SELECT NULLIF(DATECOL,CLOBCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'CLOB' are not supported. SELECT NULLIF(DATECOL,DATECOL) from AllDataTypesTable 1735,1752d1736 Data Conversion SQLException SELECT NULLIF(DATECOL,VARCHARCOL) from AllDataTypesTable COL1(datatype : DATE, precision : 10, scale : 0) Data Conversion SQLException SELECT NULLIF(DATECOL,LONGVARCHARCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'LONG VARCHAR' are not supported. SELECT NULLIF(DATECOL,CHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'CHAR () FOR BIT DATA' are not supported. SELECT NULLIF(DATECOL,VARCHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'VARCHAR () FOR BIT DATA' are not supported. SELECT NULLIF(DATECOL,LVARCHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'LONG VARCHAR FOR BIT DATA' are not supported. SELECT NULLIF(DATECOL,CLOBCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'DATE' and 'CLOB' are not supported. SELECT NULLIF(DATECOL,DATECOL) from AllDataTypesTable COL1(datatype : DATE, precision : 10, scale : 0) 1775a1760,1775 Data Conversion SQLException SELECT NULLIF(TIMECOL,VARCHARCOL) from AllDataTypesTable Data Conversion SQLException SELECT NULLIF(TIMECOL,LONGVARCHARCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'TIME' and 'LONG VARCHAR' are not supported. SELECT NULLIF(TIMECOL,CHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'TIME' and 'CHAR () FOR BIT DATA' are not supported. SELECT NULLIF(TIMECOL,VARCHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'TIME' and 'VARCHAR () FOR BIT DATA' are not supported. SELECT NULLIF(TIMECOL,LVARCHARFORBITCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'TIME' and 'LONG VARCHAR FOR BIT DATA' are not supported. SELECT NULLIF(TIMECOL,CLOBCOL) from AllDataTypesTable ERROR 42818: Comparisons between 'TIME' and 'CLOB' are not supported. SELECT NULLIF(TIMECOL,DATECOL) from AllDataTypesTable ERROR 42818: Comparisons between 'TIME' and 'DATE' are not supported. SELECT NULLIF(TIMECOL,TIMECOL) from AllDataTypesTable 1778 del Data Conversion SQLException 1779,1797d1777 SELECT NULLIF(TIMECOL,VARCHARCOL) from AllDataTypesTable COL1(datatype : TIME, precision : 8, scale : 0) --- Data Conversion SQLException SELECT NULLIF(TIMECOL,LONGVARCHARCOL)
Code coverage results for 10.1.3 (417277) release candidate
HiAll, I ran code coverage for10.1.3 - svn revision no417277 with sun jdk131, sun jdk142, sun jdk15 on Windows 2000, and results are as following:- OVERALL COVERAGE SUMMARY Classes: 92% (1071/1167) Methods: 74% (14839/20030) Blocks: 71% (445925/630514) Lines: 71% (92693.9/130494) OVERALL STATS SUMMARY total packages: 75 total executable files: 1118 total classes: 1167 total methods: 20030 total executable lines: 130494 -- Ramandeep Kaur [EMAIL PROTECTED]
[jira] Updated: (DERBY-1458) Add MessageBundleTest to build script to verify that there are no orphaned message ids
[ http://issues.apache.org/jira/browse/DERBY-1458?page=all ] Mike Matrigali updated DERBY-1458: -- Component: Build tools Add MessageBundleTest to build script to verify that there are no orphaned message ids -- Key: DERBY-1458 URL: http://issues.apache.org/jira/browse/DERBY-1458 Project: Derby Type: Test Components: Build tools Versions: 10.2.0.0 Reporter: David Van Couvering Assignee: David Van Couvering Fix For: 10.2.0.0 MessageBundleTest can't be run with the regular tests because it relies on SQLState.java and MessageId.java, which are not in the jar files. But it actually makes more sense to run it as part of the build, as we are verifying the consistency of code references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: upcoming 10.2 release and regression test failures.
Hi Mike, +1 to cleaning these up for 10.2. I would also add the following bugs: 830 - lang/dcl.sql failures on solaris 1352 - sysinfo locale-specific noise Regards, -Rick Mike Matrigali wrote: There are currently 24 regression test failures listed in jira, I think most apply to the trunk. Only one of them has anyone working on it. I took a quick look at categorizing them. It seems like we should at least spend some time on the mainline jvm (1.4, 1.5, 1.6) issues verifying that problem is not likely a regression for the 10.2 release before going GA. I know I waste time every time I have to figure out if the test failure I encounterd is one of the growing set of expected failures or not. Fixing them now rather than during the RC vetting period would make it more likely we could make the dates Rick is aiming at. Note this is just the regression test category, has anyone done any review of the outstanding derby bugs and what would be appropriate to fix before 10.2 goes GA? mailine jvm DERBY-1430 Test parameterMapping.java often fails DerbyNetClient on Solarisx86 DERBY-1404 i18nTest/iepnegativetests_ES and derbytools/iepnegativetests fails with ibm142 on linux DERBY-1403 importExport.java fails with ibm142 on linux DERBY-1320 Test lang/procedure.java fails with ibm1.5 jvm DERBY-1108 The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5 DERBY-1022 syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128) DERBY-988 jdbcapi/parameterMapping.java fails on Win2003 with 'P3=SQLSTATE(22007): SQL Exception: The syntax of the string representation of a datetime value is incorrect.' DERBY-980 derbynet/testSecMec.java fails with InterruptedException DERBY-957 Long passed into an exception gets displayed using locale specific formatting. i18n/locale issue DERBY-952 DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin compat testing: DERBY-1084 jdbcapi/xaStateTran test fails with 10.1 client and derbyTesting.jar with 10.2 server. DERBY-1083 jdbcapi/xaSimplePositive fails with 10.1 derbyTesting.jar and 10.1 c lient with 10.2 server. intermittent (anyone have a spare machine they can run test repeatedly over a weekend to give us an idea how intermittent?) DERBY-1248 Assert failure in BasePage.shiftUp() when running store/onlineBackup Test4.sql DERBY-1237 unit/daemonService fails intermittently with Shutting down due to unit test failure. DERBY-989 unit/daemonService.unit fails intermittently: 'ran out of time' DERBY-973 Restore fails in OnlineBackupTest1 DERBY-967 lang/autoincrement.sql intermittently fails on SunOS-5.10_i86 DERBY-803 derbynet/DerbyNetAutoStart.java test fails intermittently with org.a pache.derby.iapi.services.context.ShutdownException DERBY-1418 derbyall/storeall/storemore/OnlineBackupTest3 failed, unable to reproduce DERBY-1419 MessageBundleTest.diff test failed in nightly run, jdk15 o i think should be taken off regression test list, was removed from suite old jvm: DERBY-1407 encryptionAll.fail:store/access.sql hangs on ibm1.3.1 while running the blowfish test run DERBY-1153 derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3 not mainline jvm: DERBY-1457 lang/triggerGeneral.sql fails intermittently with wsdd 5.6 DERBY-1179 demo/RunClassPathTester.java fails against IBM wsdd5.6
Regression Test Failure! - TinderBox_Derby 418098 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 418098/2006-06-29 19:53:05 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1675674 2 122.93% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-418098.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/418098.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/418098.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: upcoming 10.2 release and regression test failures.
+++1, we need to fix these Rick Hillegas wrote: Hi Mike, +1 to cleaning these up for 10.2. I would also add the following bugs: 830 - lang/dcl.sql failures on solaris 1352 - sysinfo locale-specific noise Regards, -Rick Mike Matrigali wrote: There are currently 24 regression test failures listed in jira, I think most apply to the trunk. Only one of them has anyone working on it. I took a quick look at categorizing them. It seems like we should at least spend some time on the mainline jvm (1.4, 1.5, 1.6) issues verifying that problem is not likely a regression for the 10.2 release before going GA. I know I waste time every time I have to figure out if the test failure I encounterd is one of the growing set of expected failures or not. Fixing them now rather than during the RC vetting period would make it more likely we could make the dates Rick is aiming at. Note this is just the regression test category, has anyone done any review of the outstanding derby bugs and what would be appropriate to fix before 10.2 goes GA? mailine jvm DERBY-1430 Test parameterMapping.java often fails DerbyNetClient on Solarisx86 DERBY-1404 i18nTest/iepnegativetests_ES and derbytools/iepnegativetests fails with ibm142 on linux DERBY-1403 importExport.java fails with ibm142 on linux DERBY-1320 Test lang/procedure.java fails with ibm1.5 jvm DERBY-1108 The test jdbcapi/setTransactionIsolation.java fails with ibm jvm1.5 DERBY-1022 syscat.sql test failing due to change in size of a system table's column from VARCHAR(30) to VARCHAR(128) DERBY-988 jdbcapi/parameterMapping.java fails on Win2003 with 'P3=SQLSTATE(22007): SQL Exception: The syntax of the string representation of a datetime value is incorrect.' DERBY-980 derbynet/testSecMec.java fails with InterruptedException DERBY-957 Long passed into an exception gets displayed using locale specific formatting. i18n/locale issue DERBY-952 DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin compat testing: DERBY-1084 jdbcapi/xaStateTran test fails with 10.1 client and derbyTesting.jar with 10.2 server. DERBY-1083 jdbcapi/xaSimplePositive fails with 10.1 derbyTesting.jar and 10.1 c lient with 10.2 server. intermittent (anyone have a spare machine they can run test repeatedly over a weekend to give us an idea how intermittent?) DERBY-1248 Assert failure in BasePage.shiftUp() when running store/onlineBackup Test4.sql DERBY-1237 unit/daemonService fails intermittently with Shutting down due to unit test failure. DERBY-989 unit/daemonService.unit fails intermittently: 'ran out of time' DERBY-973 Restore fails in OnlineBackupTest1 DERBY-967 lang/autoincrement.sql intermittently fails on SunOS-5.10_i86 DERBY-803 derbynet/DerbyNetAutoStart.java test fails intermittently with org.a pache.derby.iapi.services.context.ShutdownException DERBY-1418 derbyall/storeall/storemore/OnlineBackupTest3 failed, unable to reproduce DERBY-1419 MessageBundleTest.diff test failed in nightly run, jdk15 o i think should be taken off regression test list, was removed from suite old jvm: DERBY-1407 encryptionAll.fail:store/access.sql hangs on ibm1.3.1 while running the blowfish test run DERBY-1153 derbynet/SqlExceptionTest.junit fails with Sun JDK 1.3 not mainline jvm: DERBY-1457 lang/triggerGeneral.sql fails intermittently with wsdd 5.6 DERBY-1179 demo/RunClassPathTester.java fails against IBM wsdd5.6
[jira] Assigned: (DERBY-1419) derbyall/i18nTest/MessageBundleTest.diff test failed in nightly run, jdk15
[ http://issues.apache.org/jira/browse/DERBY-1419?page=all ] David Van Couvering reassigned DERBY-1419: -- Assign To: David Van Couvering derbyall/i18nTest/MessageBundleTest.diff test failed in nightly run, jdk15 -- Key: DERBY-1419 URL: http://issues.apache.org/jira/browse/DERBY-1419 Project: Derby Type: Bug Components: Regression Test Failure Environment: Generating report for RunSuite derbyall null null null true -- Java Information -- Java Version:1.5.0_02 Java Vendor: Sun Microsystems Inc. Java home: c:\cloudtst\jartest\jdk15\jre Java classpath: c:/cloudtst/jartest/classes/derby.jar;c:/cloudtst/jartest/classes/derbyLocale_zh_TW.jar;c:/cloudtst/jartest/classes/derbyLocale_zh_CN.jar;c:/cloudtst/jartest/classes/derbyLocale_pt_BR.jar;c:/cloudtst/jartest/classes/derbyLocale_ko_KR.jar;c:/cloudtst/jartest/classes/derbyLocale_ja_JP.jar;c:/cloudtst/jartest/classes/derbyLocale_it.jar;c:/cloudtst/jartest/classes/derbyLocale_fr.jar;c:/cloudtst/jartest/classes/derbyLocale_es.jar;c:/cloudtst/jartest/classes/derbyLocale_de_DE.jar;c:/cloudtst/jartest/classes/derbytools.jar;c:/cloudtst/jartest/classes/derbynet.jar;c:/cloudtst/jartest/classes/derbyclient.jar;;c:/cloudtst/jartest/classes/derbyrun.jar;c:/cloudtst/jartest/classes/derbyTesting.jar;c:/cloudtst/jartest/classes/maps.jar;c:/cloudtst/jartest/classes/functionTests.jar;c:/cloudtst/jartest/classes/csext.jar;c:/cloudtst/jartest/tools/java/junit.jar;c:/cloudtst/jartest/tools/java/jndi/fscontext.jar;c:/cloudtst/jartest/tools/java/RmiJdbc.jar;c:/cloudtst/jartest/drda/jcc/2.6/db2jcc.jar;c:/cloudtst/jartest/drda/jcc/2.6/db2jcc_license_c.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\cloudtst\jartest\JarResults.2006-06-14\jdk15_derbyall java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [C:\cloudtst\jartest\classes\derby.jar] 10.2.0.4 alpha - (414425) [C:\cloudtst\jartest\classes\derbytools.jar] 10.2.0.4 alpha - (414425) [C:\cloudtst\jartest\classes\derbynet.jar] 10.2.0.4 alpha - (414425) [C:\cloudtst\jartest\classes\derbyclient.jar] 10.2.0.4 alpha - (414425) [C:\cloudtst\jartest\drda\jcc\2.6\db2jcc.jar] 2.6 - (90) [C:\cloudtst\jartest\drda\jcc\2.6\db2jcc_license_c.jar] 2.6 - (90) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.0.4 alpha - (414425) Found support for locale: [es] version: 10.2.0.4 alpha - (414425) Found support for locale: [fr] version: 10.2.0.4 alpha - (414425) Found support for locale: [it] version: 10.2.0.4 alpha - (414425) Found support for locale: [ja_JP] version: 10.2.0.4 alpha - (414425) Found support for locale: [ko_KR] version: 10.2.0.4 alpha - (414425) Found support for locale: [pt_BR] version: 10.2.0.4 alpha - (414425) Found support for locale: [zh_CN] version: 10.2.0.4 alpha - (414425) Found support for locale: [zh_TW] version: 10.2.0.4 alpha - (414425) -- Reporter: Mike Matrigali Assignee: David Van Couvering Fix For: 10.2.0.0 here is the diff: * Diff file derbyall/i18nTest/MessageBundleTest.diff *** Start: MessageBundleTest jdk1.5.0_02 derbyall:i18nTest 2006-06-14 22:43:27 *** 1 del ERROR: Message id XSDAN.S in SQLState.java was not found in messages_en.properties 2 del ERROR: Message id X0RQ3.C in SQLState.java was not found in messages_en.properties 3 del ERROR: Message id XSAX1 in SQLState.java was not found in messages_en.properties 4 del ERROR: Message id XCL32.S in SQLState.java was not found in messages_en.properties 5 del ERROR: Message id J030 in MessageId.java was not found in messages_en.properties 6 del ERROR: Message id J029 in MessageId.java was not found in messages_en.properties 6 add Exception in thread main java.lang.NoClassDefFoundError: org.apache.derby.shared.common.reference.SQLState Test Failed. *** End: MessageBundleTest jdk1.5.0_02 derbyall:i18nTest 2006-06-14 22:43:30 *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1419) derbyall/i18nTest/MessageBundleTest.diff test failed in nightly run, jdk15
[ http://issues.apache.org/jira/browse/DERBY-1419?page=all ] David Van Couvering updated DERBY-1419: --- Component: Services (was: Regression Test Failure) Priority: Minor (was: Major) No longer a regression test failure, I removed it from derbyall. Will likely be resolved by DERBY-1458 derbyall/i18nTest/MessageBundleTest.diff test failed in nightly run, jdk15 -- Key: DERBY-1419 URL: http://issues.apache.org/jira/browse/DERBY-1419 Project: Derby Type: Bug Components: Services Environment: Generating report for RunSuite derbyall null null null true -- Java Information -- Java Version:1.5.0_02 Java Vendor: Sun Microsystems Inc. Java home: c:\cloudtst\jartest\jdk15\jre Java classpath: c:/cloudtst/jartest/classes/derby.jar;c:/cloudtst/jartest/classes/derbyLocale_zh_TW.jar;c:/cloudtst/jartest/classes/derbyLocale_zh_CN.jar;c:/cloudtst/jartest/classes/derbyLocale_pt_BR.jar;c:/cloudtst/jartest/classes/derbyLocale_ko_KR.jar;c:/cloudtst/jartest/classes/derbyLocale_ja_JP.jar;c:/cloudtst/jartest/classes/derbyLocale_it.jar;c:/cloudtst/jartest/classes/derbyLocale_fr.jar;c:/cloudtst/jartest/classes/derbyLocale_es.jar;c:/cloudtst/jartest/classes/derbyLocale_de_DE.jar;c:/cloudtst/jartest/classes/derbytools.jar;c:/cloudtst/jartest/classes/derbynet.jar;c:/cloudtst/jartest/classes/derbyclient.jar;;c:/cloudtst/jartest/classes/derbyrun.jar;c:/cloudtst/jartest/classes/derbyTesting.jar;c:/cloudtst/jartest/classes/maps.jar;c:/cloudtst/jartest/classes/functionTests.jar;c:/cloudtst/jartest/classes/csext.jar;c:/cloudtst/jartest/tools/java/junit.jar;c:/cloudtst/jartest/tools/java/jndi/fscontext.jar;c:/cloudtst/jartest/tools/java/RmiJdbc.jar;c:/cloudtst/jartest/drda/jcc/2.6/db2jcc.jar;c:/cloudtst/jartest/drda/jcc/2.6/db2jcc_license_c.jar OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: cloudtest Java user home: C:\Documents and Settings\cloudtest Java user dir: C:\cloudtst\jartest\JarResults.2006-06-14\jdk15_derbyall java.specification.name: Java Platform API Specification java.specification.version: 1.5 - Derby Information JRE - JDBC: J2SE 5.0 - JDBC 3.0 [C:\cloudtst\jartest\classes\derby.jar] 10.2.0.4 alpha - (414425) [C:\cloudtst\jartest\classes\derbytools.jar] 10.2.0.4 alpha - (414425) [C:\cloudtst\jartest\classes\derbynet.jar] 10.2.0.4 alpha - (414425) [C:\cloudtst\jartest\classes\derbyclient.jar] 10.2.0.4 alpha - (414425) [C:\cloudtst\jartest\drda\jcc\2.6\db2jcc.jar] 2.6 - (90) [C:\cloudtst\jartest\drda\jcc\2.6\db2jcc_license_c.jar] 2.6 - (90) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.0.4 alpha - (414425) Found support for locale: [es] version: 10.2.0.4 alpha - (414425) Found support for locale: [fr] version: 10.2.0.4 alpha - (414425) Found support for locale: [it] version: 10.2.0.4 alpha - (414425) Found support for locale: [ja_JP] version: 10.2.0.4 alpha - (414425) Found support for locale: [ko_KR] version: 10.2.0.4 alpha - (414425) Found support for locale: [pt_BR] version: 10.2.0.4 alpha - (414425) Found support for locale: [zh_CN] version: 10.2.0.4 alpha - (414425) Found support for locale: [zh_TW] version: 10.2.0.4 alpha - (414425) -- Reporter: Mike Matrigali Assignee: David Van Couvering Priority: Minor Fix For: 10.2.0.0 here is the diff: * Diff file derbyall/i18nTest/MessageBundleTest.diff *** Start: MessageBundleTest jdk1.5.0_02 derbyall:i18nTest 2006-06-14 22:43:27 *** 1 del ERROR: Message id XSDAN.S in SQLState.java was not found in messages_en.properties 2 del ERROR: Message id X0RQ3.C in SQLState.java was not found in messages_en.properties 3 del ERROR: Message id XSAX1 in SQLState.java was not found in messages_en.properties 4 del ERROR: Message id XCL32.S in SQLState.java was not found in messages_en.properties 5 del ERROR: Message id J030 in MessageId.java was not found in messages_en.properties 6 del ERROR: Message id J029 in MessageId.java was not found in messages_en.properties 6 add Exception in thread main java.lang.NoClassDefFoundError: org.apache.derby.shared.common.reference.SQLState Test Failed. *** End: MessageBundleTest jdk1.5.0_02 derbyall:i18nTest 2006-06-14 22:43:30 *** -- 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:
[jira] Updated: (DERBY-551) Allow invoking java stored procedures from inside a trigger. Make CALL a valid statement in the trigger body.
[ http://issues.apache.org/jira/browse/DERBY-551?page=all ] Deepa Remesh updated DERBY-551: --- Attachment: derby-551-draft1.diff derby-551-draft1.status ProcedureInTrigger_Tests_v1.html Attaching a draft patch 'derby-551-draft1.diff' (not for commit) which enables procedures to be called from triggers. This patch is not complete. I am posting it as I would like to get some feedback. Changes made by the patch are: * Modify the parsing to allow call statement inside trigger. * Check that procedures that modify SQL data are not allowed in BEFORE triggers. To check this, I used AliasDescriptor in DataDictionary to get the alias info. I have placed this check currently in routineInvocation(). I think this is causing a diff in lang/releaseCompileLocks.sql. There is an entry in the lock_table when there should be none: TABLE|IS |SYSALIASES |Tablelock |GRANT Earlier, I had tried to use the RoutineAliasInfo in the MethodCallNode but this had not worked as this object was null at trigger creation time. Any suggestions to do this in a better way? * A new message is added to indicate the above error. It maps to the same SQL state as that for unsupported statements in triggers. * Added a new test. I have to add some more test cases to this. I am adding tests based on the scenarios identified in ProcedureInTrigger_Tests_v1.html. Please go through this and let me know if there are scenarios that need to be added/removed. * Modified two tests by removing statements that were testing that call statements are not allowed in triggers. I would appreciate feedback on the patch and the test scenarios. Allow invoking java stored procedures from inside a trigger. Make CALL a valid statement in the trigger body. - Key: DERBY-551 URL: http://issues.apache.org/jira/browse/DERBY-551 Project: Derby Type: New Feature Components: SQL Versions: 10.1.1.0 Environment: All platforms Reporter: Satheesh Bandaram Assignee: Deepa Remesh Fix For: 10.2.0.0 Attachments: ProcedureInTrigger_Tests_v1.html, derby-551-draft1.diff, derby-551-draft1.status Derby currently doesn't allow CALL statement to be used in a trigger body. It would be great to allow java stored procedure invocation inside a trigger. Since Derby doesn't have SQL procedure language, triggers can only execute a single SQL statement. If we allow stored procedures in triggers, it would be possible to write a trigger that involves more than just one SQL statement. Functions are currently allowed, but they are read-only. I believe it is fairly easy to support this enhancement. Need good amount of testing though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1032) Create new scripts which follow common practice at Apache
[ http://issues.apache.org/jira/browse/DERBY-1032?page=all ] Andrew McIntyre updated DERBY-1032: --- Attachment: derby-1032-bin-sh.tgz Attaching draft versions of new scripts for the bin directory. Batch files based on the current batch files are next. Create new scripts which follow common practice at Apache - Key: DERBY-1032 URL: http://issues.apache.org/jira/browse/DERBY-1032 Project: Derby Type: Improvement Components: Demos/Scripts Versions: 10.2.0.0 Reporter: Andrew McIntyre Assignee: Andrew McIntyre Priority: Minor Attachments: derby-1032-bin-sh.tgz Scripts for Derby should be written to follow common practice at Apache. This means locating them in a bin directory, and self configuring from the minimum amount of information necessary: installation location and in our case, the location of Java, from the variables DERBY_HOME and JAVA_HOME respectively. If these variables are not set, we should report this to the user. Good examples are available in Ant, Forrest, and Maven, and much of the same setup code can be reused from those projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] 10.1.3.1 release
Andrew McIntyre wrote === SNIP === I will close this vote on Thursday, June 29 at 3:15 pm PDT. Please let me know if you need more time to inspect/test the release candidate and cast your vote. Thanks again to everyone who has helped out with the release. andrew +1 I have run derbyall with 10.1.3.0 on Linux SLES 9 (dual processor) using the SUN 1.5 JRE and the IBM 1.3.1 sp10 JRE - no failures (one test harness issue was filed) I ran derbyall with 10.1.3.1 (RC2) on Linux SLES 9 (dual processor) using the SUN 1.5 JRE - no failures
[jira] Updated: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger
[ http://issues.apache.org/jira/browse/DERBY-1435?page=all ] Deepa Remesh updated DERBY-1435: Attachment: repro1435_for_functions.sql A similar case occurs when function/procedure referenced in triggered SQL statement is dropped and a previously executed statement is re-executed to fire the trigger. In this case, no exception is thrown; the trigger firing is successful (executes the function/procedure as if it had not been dropped). The new repro 'repro1435_for_functions.sql' shows this. Also, I see a different behaviour in the execution of a statement when it is preceded with a comment. This is also included in the repro. I am adding this to the same issue as the problems look similar. Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger Key: DERBY-1435 URL: http://issues.apache.org/jira/browse/DERBY-1435 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Reporter: Deepa Remesh Attachments: repro1435.sql, repro1435_for_functions.sql This exception occurs in the following case: 1. Create tables t1 and t2. Create a trigger on t2 whose triggering action is to insert a row into t1 2. Insert a value v1 into t2. Verify the trigger was fired by looking at contents of t1. 3. Drop table t1. 4. Insert a value v2 into t2. This will give an exception to indicate that table t1 does not exist. 5. Insert the same value v1 into t2. Instead of the exception in Step 4, this gives ERROR XSAI2: The conglomerate (896) requested does not exist. 6. Re-create table t1. 7. Insert v2 into t2. This succeeds. 8. Try to insert the problem value v1 into t2. This still gives ERROR XSAI2: The conglomerate (896) requested does not exist. 9. Shutdown and reconnect to the database. Try to insert the problem value v1 into t2. Now this succeeds. So the exception occurs only in the specific case where we try to insert the same value that we had inserted before dropping the table referenced by the trigger. I'll attach a sql script to repro this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1449) checkDataSource tests fail with 10.1 client and 10.2 server
[ http://issues.apache.org/jira/browse/DERBY-1449?page=comments#action_12418530 ] Sunitha Kambhampati commented on DERBY-1449: I tried this test out checkDataSource.java with 10.1 derbyclient.jar and derbyTesting.jar, and rest are 10.2 jars and followed instructions to run with new server/old client from our wiki. The exceptionInitializer error is actually a security permission exception on the property 'framework' as seen in the exception trace and as Kathey mentioned in one of her mails to the list. I was wondering why the test harness was not able to read this property. I noticed that the security policy file grants permissions to read all property for derbytesting.jar in both 10.1 and 10.2, so ideally it should work. Then it hit me, that my classpath had 10.1 jars in one location and 10.2 jars in another location and that wont work in our harness. In my classpath, the derby.jar and derbynet.jar were before any of the other jars. When you run the test, it sets the 'csinfo.codejar' as the location for the jar files and the derby_tests.policy file expects that the derbyTesting.jar and derbytools.jar etc are all in that directory as derbynet.jar. But it picked up the csinfo.codejar as the location where the derbynet.jar was and thus , the policy file was not granting permission to my 10.1 jars that were in the classpath and hence the exception. To fix this, all that was needed is to place the 10.1 derbyclient.jar and 10.1 derbyTesting.jar in the same directory location where the other derbynet.jar and derby.jar are and then permissions will be granted correctly and test passes. java -Dderby.system.home=C:\workghm\svnclient\trunk2\test\DerbyNetClient\checkDataSource -Djava.security.manager -Djava.security.policy=C:\workghm\svnclient\trunk2\test/derby_tests.policy -Dcsinfo.codejar=file:/C:/workghm/svnclient/trunk2/jars/sane/ -Dcsinfo.codedir=C:\workghm\svnclient\trunk2\jars\sane -Dcsinfo.serverhost=localhost -Dcsinfo.trustedhost=localhost -Dcsinfo.codeclasses=file://unused/ org.apache.derby.drda.NetworkServerControl start java -Dderby.system.home=C:\workghm\svnclient\trunk2\test\DerbyNetClient\checkDataSource -Dderby.infolog.append=true -Duser.dir=C:\workghm\svnclient\trunk2\test\DerbyNetClient -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource -p C:\workghm\svnclient\trunk2\test\DerbyNetClient\checkDataSource\checkDataSource_app.properties So both these tests (checkDataSource and checkDataSource30) works on my machine. If I am missing some step or such, please let me know. I think , in the environment where this diff was reported maybe there is a test setup issue (?) If someone else can try and confirm what I see, that would be great!. Thanks. checkDataSource tests fail with 10.1 client and 10.2 server --- Key: DERBY-1449 URL: http://issues.apache.org/jira/browse/DERBY-1449 Project: Derby Type: Test Versions: 10.2.0.0, 10.1.3.0 Environment: derbyclient.jar and derbyTesting.jar from 10.1 all other jars from 10.2 Reporter: Deepa Remesh jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java fail with exception like this: org.apache.derby.client.am.SqlException: The exception 'java.lang.ExceptionInInitializerError' was thrown while evaluating an expression. SQLSTATE: XJ001: Java exception: ': java.lang.ExceptionInInitializerError'. SQLSTATE: XJ001: Java exception: 'access denied (java.util.PropertyPermission framework read): java.security.AccessControlException'. at org.apache.derby.client.am.Statement.completeExecute(Statement.java:1156) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:296) at org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:97) at org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:74) at org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:174) at org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1122) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:1414) at org.apache.derby.client.am.CallableStatement.executeX(CallableStatement.java:124) at org.apache.derby.client.am.CallableStatement.execute(CallableStatement.java:114) at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.runTest(checkDataSource.java:123) at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.main(checkDataSource.java:92) -- 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
question about jira derby browse project page.
I have a question about the following page in jira: http://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:openissues-panel Is the info here a standard we inherit from JIRA, or is it possible to customize this view. Specifically what I would like is to have a Open bugs view in addition to the open issues view.
Re: [VOTE] 10.1.3.1 release
On 6/26/06, Andrew McIntyre [EMAIL PROTECTED] wrote: Hello derby-dev, I have posted a new release candidate for 10.1.3 here: http://people.apache.org/~fuzzylogic/10.1.3.1/ I almost forgot. +1 from me, too! andrew
[jira] Closed: (DERBY-1449) checkDataSource tests fail with 10.1 client and 10.2 server
[ http://issues.apache.org/jira/browse/DERBY-1449?page=all ] Deepa Remesh closed DERBY-1449: --- Resolution: Invalid Thanks for looking at this Sunitha and finding the cause. I agree this is a test setup issue. The environment where this was run used 10.1 jars from one location and 10.2 jars from another location and had 10.2 derby.jar and derbynet.jar before any of the other jars. I am closing this issue as invalid. checkDataSource tests fail with 10.1 client and 10.2 server --- Key: DERBY-1449 URL: http://issues.apache.org/jira/browse/DERBY-1449 Project: Derby Type: Test Versions: 10.1.3.0, 10.2.0.0 Environment: derbyclient.jar and derbyTesting.jar from 10.1 all other jars from 10.2 Reporter: Deepa Remesh jdbcapi/checkDataSource.java and jdbcapi/checkDataSource30.java fail with exception like this: org.apache.derby.client.am.SqlException: The exception 'java.lang.ExceptionInInitializerError' was thrown while evaluating an expression. SQLSTATE: XJ001: Java exception: ': java.lang.ExceptionInInitializerError'. SQLSTATE: XJ001: Java exception: 'access denied (java.util.PropertyPermission framework read): java.security.AccessControlException'. at org.apache.derby.client.am.Statement.completeExecute(Statement.java:1156) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:296) at org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:97) at org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:74) at org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:174) at org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1122) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:1414) at org.apache.derby.client.am.CallableStatement.executeX(CallableStatement.java:124) at org.apache.derby.client.am.CallableStatement.execute(CallableStatement.java:114) at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.runTest(checkDataSource.java:123) at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.main(checkDataSource.java:92) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Failure! - TinderBox_Derby 418131 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 418131/2006-06-29 22:33:00 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1675674 2 122.33% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-418131.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/418131.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/418131.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: question about jira derby browse project page.
On 6/29/06, Mike Matrigali [EMAIL PROTECTED] wrote: I have a question about the following page in jira: http://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:openissues-panel Is the info here a standard we inherit from JIRA, or is it possible to customize this view. Specifically what I would like is to have a Open bugs view in addition to the open issues view. The front page layout if from the standard project template inherited from JIRA. It is possible to write a plugin that would support a different report, but that would mean you'd have to a) write the plugin and b) convince the jira admins to install it. :-) andrew
Re: [jira] Commented: (DERBY-1449) checkDataSource tests fail with 10.1 client and 10.2 server
Bryan Pendleton wrote: Sunitha Kambhampati commented on DERBY-1449: I tried this test out checkDataSource.java with 10.1 derbyclient.jar and derbyTesting.jar, and rest are 10.2 jars and followed instructions to run with new server/old client from our wiki. ... To fix this, all that was needed is to place the 10.1 derbyclient.jar and 10.1 derbyTesting.jar in the same directory location where the other derbynet.jar and derby.jar are and then permissions will be granted correctly and test passes. I think I should change http://wiki.apache.org/db-derby/TestingOldClientNewServer so that it suggests this technique. Do you agree? Yes. If someone else can confirm this behavior on their machine, that would be nice. Thanks Bryan, for offering to update the instructions on the wiki. Sunitha.
Jira mail problems???
It seems that some comments to Jira entries are again not making it to the derby-dev list. For example Rick's comment on DERBY-1459 at 28/Jun/06 09:52 PM doesn't seem to be in the archives or my in-folder. http://issues.apache.org/jira/browse/DERBY-1459?page=all It's a big concern if people are entering comments and no-one is seeing them. Dan.
Re: Jira mail problems???
On 6/29/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: It seems that some comments to Jira entries are again not making it to the derby-dev list. For example Rick's comment on DERBY-1459 at 28/Jun/06 09:52 PM doesn't seem to be in the archives or my in-folder. http://issues.apache.org/jira/browse/DERBY-1459?page=all It's a big concern if people are entering comments and no-one is seeing them. I got it. Found it here: http://www.nabble.com/-jira--Updated%3A-%28DERBY-1459%29-Early-load-of-Derby-driver-with-JDBC-4.0-autoloading-can-lead-to-derby-properties-not-being-processed-or-derby-boot-time-actions-consuming-resources-when-a-connection-is-made-with-another-driver-p5093556.html and here, too: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200606.mbox/[EMAIL PROTECTED] Mail client / ISP problem? andrew
Re: Jira mail problems???
Andrew McIntyre wrote: I got it. Found it here: Mail client / ISP problem? Dan problem I think, maybe the shakes from the lack of world cup soccer the last two days. :-) Thanks for checking, sorry for the disturbance. Dan.
Re: [RESULT] [VOTE] 10.1.3.1 release
Andrew McIntyre wrote: I am now closing this vote to release 10.1.3. The vote passes with fifteen +1s and no zero or negative votes. Darn, missed the boat, +1 from me. Dan.
Re: question about jira derby browse project page.
Andrew McIntyre wrote: On 6/29/06, Mike Matrigali [EMAIL PROTECTED] wrote: I have a question about the following page in jira: http://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:openissues-panel I am in the process of making a Wiki page for Jira reports and the best I could come up with is to take a single level group report on the preset open code bugs filter. http://issues.apache.org/jira/secure/ConfigureReport.jspa?filterid=12310220mapper=componentsselectedProjectId=10594reportKey=com.atlassian.jira.plugin.system.reports%3AsinglelevelgroupbyNext=Next
10.1.3.1 release notes draft page
The release notes draft page is here: http://people.apache.org/~fuzzylogic/releases/release-10.1.3.1.html Ignore the formatting, it's missing one of the CSS files. I still need to fill in the test results and the link to the 'list of fixed issues'. Let me know if I've missed anything else. Thanks, andrew
(DERBY-822 followup) Server prefetch when QRYROWSET is 0 (zero)?
I have some tests that I run against the Derby Server using the IBM DB2 ODBC client and I've noticed that, for scrollable cursors, the client returns the first row *twice* now that the Derby Server supports pre-fetching (DERBY-822). Long story short someone who works with the client pointed out that the client is sending a QRYROWSET of size 0 when it sends the OPNQRY for selects, which is (meant to be) an indication to the server that it should not return any rows. The person admitted that he wasn't sure if DRDA specifies that a QRYROWSET of 0 should disable pre-fetching or not--but that's what the client code seems to expect. He also admitted that it's possible to fix this on the ODBC client side by discarding rows after the OPNQRY--but a) it seems silly (to me) to perform prefetching and then spend extra logic trying to discard the data, and b) an ODBC client change won't happen in the Derby 10.2 timeframe. I verified that with the ODBC client the server does indeed receive a qryrowset value of 0. My question, then, is this: should the server perform pre-fetching if the client sends a qryrowset of 0 on an OPNQRY? And what does DRDA say about it? There's a quote from the DRDA manual that is actually pasted in the DERBY-822 description, and which I've confirmed in my own copy of the manual. Note in particular the third sentence (highlighted): begin quote The qryrowset parameter specifies whether a rowset of rows is to be returned with the command. This is only honored for non-dynamic scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming to the limited block query protocol. The target server fetches no more than the requested number of rows. It may fetch fewer rows if it is restricted by extra query block limits, or if a fetch operation results in a negative SQLSTATE or an SQLSTATE of 02000. end quote Based on that quote, it seems like the server should not be returning rows if qryrowset is 0. On the other hand, when I lookup QRYROWSET in the DDM manual, there are a bunch of very involved definitions of what the value means in different situations--and to be quite frank, I have no idea what any of it means. So if anyone out there knows the answer to this question, or else can make some sense of the QRYROWSET definitions in the DDM manual, I would appreciate some feedback/direction. If this isn't something that we can resolve on the server side, this could result in *regressed* behavior for users who currently use IBM DB2 ODBC driver against Apache Derby 10.1--i.e. when they upgrade to 10.2 their apps might start returning extra rows. I think the server-side change to not pre-fetch for qryrowset should be fairly straightforward (based on what little knowledge I have of this area :), but the question remains: what does DRDA protocol say about it? Any comments/suggestions/answers out there? Thanks much, Army
Re: Some more (expected?) failures in tests with 10.1 client/10.2 server
Deepa Remesh wrote: Seeing these additional failures in the client/server compat tests. These seem to be expected but just wanted to get feedback from others in case we need to do something extra: * derbynet/testProtocol.java (after DERBY-959) The max query blocksize that is allowed in the server has changed with derby-959 from 32k to 10M. The 10.1 protocol.tests file has tests for invalid query block size and sends a value of 4 and checks for the syntax error. But after 959 changes, the server will not throw an exception for 4 value and thus the test fails. The diffs related to invalid query block size and too large value for qryblksz are expected. There is no compatibility issue with this particular change. - Even without the 959 changes, I patched the 10.2 server with Knut's patch for DERBY-1425 and there are diffs with the testProtocol.java test. I found Knut's comments on DERBY-1425 interesting with respect to testProtocol.java compatibility testing http://issues.apache.org/jira/browse/DERBY-1425#action_12417731 Thanks, Sunitha.
Re: (DERBY-822 followup) Server prefetch when QRYROWSET is 0 (zero)?
Long story short someone who works with the client pointed out that the client is sending a QRYROWSET of size 0 when it sends the OPNQRY Hi Army, Page 698 of V.3 says: A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs the server to return no rows with the OPNQRYRM for the cursor or result set. A QRYROWSET value of zero on the CNTQRY command is invalid for non-rowset cursors and results in the application server generating a SYNTAXRM with a SYNERRCD value of '15'x (reserved value not allowed). I'd say that our current behavior, as you describe it, seems wrong; we should not be returning any rows when the client has set QRYROWSET to 0 on OPNQRY. I think that we should modify the server code for 10.2 so that: - on OPNQRY and EXCSQLSTT, we only return rows if QRYROWSET is 0. - on CNTQRY, we throw a syntax exception if QRYROWSET is 0 I'm quite interested to hear what others think about this. thanks, bryan
[jira] Resolved: (DERBY-655) getImportedKeys returns duplicate rows in some cases
[ http://issues.apache.org/jira/browse/DERBY-655?page=all ] Mamta A. Satoor resolved DERBY-655: --- Fix Version: 10.2.0.0 Resolution: Fixed Resolving this issue since the patch ensures the uniqueness of conglomerateid for new conglomerates in SYSCONGLOMERATES table. For existing duplicate conglomeratid, work needs to be done at the database upgrade time. DERBY-1343 is open to track upgrade work. As per my knowledge, nobody is working on DERBY-1343 at this point. getImportedKeys returns duplicate rows in some cases Key: DERBY-655 URL: http://issues.apache.org/jira/browse/DERBY-655 Project: Derby Type: Bug Components: SQL Versions: 10.2.0.0 Environment: Sun JDK 1.4.2, Windows XP Reporter: Deepa Remesh Assignee: Mamta A. Satoor Fix For: 10.2.0.0 Attachments: Derby655GetImportedKeysPatch1.txt, Derby655GetImportedKeysPatch1Codeline101.txt, Derby655GetImportedKeysPatch1CodelineTrunk.txt, Derby655GetImportedKeysPatch1CodelineTrunkUpgradeTest.txt, Derby655GetImportedKeysPatch2Codeline101.txt, Derby655GetImportedKeysStat1.txt, bigdb.sql, keys.java, keys_test.zip, smalldb.sql I have a database with a large number of tables. I get duplicate rows when I call DatabaseMetaData.getImportedKeys for a particular table. However, if I create the same table with same number of foreign keys in another database (which has fewer number of tables), then getImportedKeys returns me the correct number of rows. This error seems to happen only when the database has a large number of tables. I will attach a repro for this shortly. -- 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
