[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085571#comment-13085571 ] Kristian Waagan commented on DERBY-5363: Rick, I looks to me like you used a Java 7 early access build - these builds are ignored by the PropertySetter.isValidVersion(). If you specify -DprintCompilerProperties[Verbose]=true this should be reported. I tested the patch on OpenSUSE 11.4 and it worked when setting JAVA_HOME=jdk1.7. In this case Java 6 was also available. If run it with only Java 7 available, the build fails. Is this as intended, or do we want to set the Java 6 compile classpath using Java 7 (as we do for Java 5.0 if only Java 6 is available)? Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5271) Client may hang if the server crashes due to a java.lang.Error
[ https://issues.apache.org/jira/browse/DERBY-5271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-5271: --- Fix Version/s: 10.9.0.0 Committed patch 1a to trunk with revision 1158108. I plan to backport this fix. Regarding making the server hang, I can't guarantee that it won't happen. If it happens it would hopefully affect only the worker thread that crashed. Most of the Error subclasses are pretty serious and the JVM will come down in many cases. OOME isn't necessarily one of these - what happens depends on the nature of the shortage and in which threads an OOME is raised. Further, a single hung ClientThread may not be a problem, assuming that database resources (like locks) have been released. Client may hang if the server crashes due to a java.lang.Error -- Key: DERBY-5271 URL: https://issues.apache.org/jira/browse/DERBY-5271 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.9.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.9.0.0 Attachments: derby-5271-1a-inital_fix_proposal.diff When certain types of errors are raised while the network server is processing a client request, the server is left in a semi-degraded state. The problem this issue is concerned with, is that the client socket is kept open even though the server in a kind of degraded state (server JVM still alive). This causes the client to hang, until the server JVM is killed, in a read-call on the socket. I'm able to reproduce this with an OOME being raised on the server. In my opinion, hanging when there is no chance of progression is bad behavior. Furthermore, it causes trouble for automated testing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5179) Support ALTER DATABASE to change collation
[
https://issues.apache.org/jira/browse/DERBY-5179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085616#comment-13085616
]
Kristian Waagan commented on DERBY-5179:
Some databases support specifying collations on a per query basis. I haven't
researched this, but I assume this applies for SELECTs only? I have no idea how
this functionality work with respect to collated indexes.
I've also seen examples where you can modify collations using SQL.
Support ALTER DATABASE to change collation
--
Key: DERBY-5179
URL: https://issues.apache.org/jira/browse/DERBY-5179
Project: Derby
Issue Type: Improvement
Components: SQL, Store
Reporter: Brett Wooldridge
DERBY-1748 added the ability to control the collation of the database during
database creation, but leaves users with existing databases with no way to
upgrade their databases. In the case of my company, we have many Derby
deployments in the field in production, and dropping and recreating the
database during upgrade is not possible (or acceptable).
Similar to MySQL, Derby should support ALTER DATABASE to change the default
collation of a database. For reference, the MySQL syntax is:
ALTER {DATABASE | SCHEMA} [db_name]
alter_specification ...
alter_specification:
[DEFAULT] CHARACTER SET [=] charset_name
| [DEFAULT] COLLATE [=] collation_name
I would suggest that this syntax is perfectly acceptable, and should be
adopted by Derby.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5183) Cannot get BLOB value in the result set
[
https://issues.apache.org/jira/browse/DERBY-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-5183:
---
Affects Version/s: 10.3.3.0
10.4.1.3
Fix Version/s: 10.4.2.0
I downloaded the BIRT sample database and ran the second repro program.
This bug appears only in versions 10.3.3.0 and 10.4.1.3.
Cannot get BLOB value in the result set
---
Key: DERBY-5183
URL: https://issues.apache.org/jira/browse/DERBY-5183
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.3.0, 10.4.1.3
Reporter: dingyan
Fix For: 10.4.2.0
There is a table include BLOB and CLOB data,column 3 is CLOB and column 4 is
BLOB
when i try to get the data from this table,in some cases,SQLException is
thrown :The data in this BLOB or CLOB is no longer available. The
BLOB/CLOB's transaction may be committed, or its connection is closed
when i get the CLOB and BLOB data without the stream read,it is ok,my test
source code as below:
import java.io.InputStream;
import java.sql.Clob;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.ResultSetMetaData;
import java.sql.SQLException;
public class Test {
public static String driverClass =
org.apache.derby.jdbc.EmbeddedDriver;
public static String driverURL = jdbc:derby:d:\\BirtSample;
public static String user = ClassicModels;
public static String squery = select * from
CLASSICMODELS.PRODUCTLINES,CLASSICMODELS.PRODUCTS where
CLASSICMODELS.PRODUCTS.PRODUCTLINE = CLASSICMODELS.PRODUCTLINES.PRODUCTLINE;
private static int i = 0;
public static void main( String[] args )
{
try {
Class.forName(driverClass);
Connection c = DriverManager.getConnection(driverURL,
user, );
PreparedStatement s = c.prepareStatement(squery);
c.setAutoCommit(false);
ResultSet r = s.executeQuery();
ResultSetMetaData meta = r.getMetaData();
int count = meta.getColumnCount();
try{
while(r.next()) {
r.getString(1);
r.getString(2);
Clob clob = r.getClob(3);
// byte[] b = new byte[(int)clob.length()];
// InputStream stream = clob.getAsciiStream();
// stream.read(b);
// stream.close();
// Reader reader = clob.getCharacterStream();
// reader.read(b);
// reader.close();
System.out.println( r.getBlob(4));
System.out.println( row count= + i);
i++;
}}catch( SQLException ex)
{
ex.printStackTrace();
}
s.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
but when i read after get the CLOB,source code as below:
import java.io.InputStream;
import java.sql.Clob;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.ResultSetMetaData;
import java.sql.SQLException;
public class Test {
public static String driverClass =
org.apache.derby.jdbc.EmbeddedDriver;
public static String driverURL = jdbc:derby:d:\\BirtSample;
public static String user = ClassicModels;
public static String squery = select * from
CLASSICMODELS.PRODUCTLINES,CLASSICMODELS.PRODUCTS where
CLASSICMODELS.PRODUCTS.PRODUCTLINE = CLASSICMODELS.PRODUCTLINES.PRODUCTLINE;
private static int i = 0;
public static void main( String[] args )
{
try {
Class.forName(driverClass);
Connection c = DriverManager.getConnection(driverURL,
user, );
PreparedStatement s = c.prepareStatement(squery);
c.setAutoCommit(false);
ResultSet r = s.executeQuery();
ResultSetMetaData meta = r.getMetaData();
int count = meta.getColumnCount();
try{
while(r.next()) {
r.getString(1);
r.getString(2);
Clob clob = r.getClob(3);
byte[] b = new byte[(int)clob.length()];
InputStream stream = clob.getAsciiStream();
stream.read(b);
stream.close();
// Reader reader =
[jira] [Resolved] (DERBY-5183) Cannot get BLOB value in the result set
[
https://issues.apache.org/jira/browse/DERBY-5183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan resolved DERBY-5183.
Resolution: Fixed
Marking as fixed.
Cannot get BLOB value in the result set
---
Key: DERBY-5183
URL: https://issues.apache.org/jira/browse/DERBY-5183
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.3.3.0, 10.4.1.3
Reporter: dingyan
Fix For: 10.4.2.0
There is a table include BLOB and CLOB data,column 3 is CLOB and column 4 is
BLOB
when i try to get the data from this table,in some cases,SQLException is
thrown :The data in this BLOB or CLOB is no longer available. The
BLOB/CLOB's transaction may be committed, or its connection is closed
when i get the CLOB and BLOB data without the stream read,it is ok,my test
source code as below:
import java.io.InputStream;
import java.sql.Clob;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.ResultSetMetaData;
import java.sql.SQLException;
public class Test {
public static String driverClass =
org.apache.derby.jdbc.EmbeddedDriver;
public static String driverURL = jdbc:derby:d:\\BirtSample;
public static String user = ClassicModels;
public static String squery = select * from
CLASSICMODELS.PRODUCTLINES,CLASSICMODELS.PRODUCTS where
CLASSICMODELS.PRODUCTS.PRODUCTLINE = CLASSICMODELS.PRODUCTLINES.PRODUCTLINE;
private static int i = 0;
public static void main( String[] args )
{
try {
Class.forName(driverClass);
Connection c = DriverManager.getConnection(driverURL,
user, );
PreparedStatement s = c.prepareStatement(squery);
c.setAutoCommit(false);
ResultSet r = s.executeQuery();
ResultSetMetaData meta = r.getMetaData();
int count = meta.getColumnCount();
try{
while(r.next()) {
r.getString(1);
r.getString(2);
Clob clob = r.getClob(3);
// byte[] b = new byte[(int)clob.length()];
// InputStream stream = clob.getAsciiStream();
// stream.read(b);
// stream.close();
// Reader reader = clob.getCharacterStream();
// reader.read(b);
// reader.close();
System.out.println( r.getBlob(4));
System.out.println( row count= + i);
i++;
}}catch( SQLException ex)
{
ex.printStackTrace();
}
s.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
but when i read after get the CLOB,source code as below:
import java.io.InputStream;
import java.sql.Clob;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.ResultSetMetaData;
import java.sql.SQLException;
public class Test {
public static String driverClass =
org.apache.derby.jdbc.EmbeddedDriver;
public static String driverURL = jdbc:derby:d:\\BirtSample;
public static String user = ClassicModels;
public static String squery = select * from
CLASSICMODELS.PRODUCTLINES,CLASSICMODELS.PRODUCTS where
CLASSICMODELS.PRODUCTS.PRODUCTLINE = CLASSICMODELS.PRODUCTLINES.PRODUCTLINE;
private static int i = 0;
public static void main( String[] args )
{
try {
Class.forName(driverClass);
Connection c = DriverManager.getConnection(driverURL,
user, );
PreparedStatement s = c.prepareStatement(squery);
c.setAutoCommit(false);
ResultSet r = s.executeQuery();
ResultSetMetaData meta = r.getMetaData();
int count = meta.getColumnCount();
try{
while(r.next()) {
r.getString(1);
r.getString(2);
Clob clob = r.getClob(3);
byte[] b = new byte[(int)clob.length()];
InputStream stream = clob.getAsciiStream();
stream.read(b);
stream.close();
// Reader reader = clob.getCharacterStream();
// reader.read(b);
// reader.close();
System.out.println( r.getBlob(4));
[jira] [Commented] (DERBY-4670) ThreadDump class included in insane jars
[ https://issues.apache.org/jira/browse/DERBY-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085656#comment-13085656 ] Kristian Waagan commented on DERBY-4670: Hi Kathey, Do you still plan to backport this one? ThreadDump class included in insane jars Key: DERBY-4670 URL: https://issues.apache.org/jira/browse/DERBY-4670 Project: Derby Issue Type: Bug Components: Build tools Affects Versions: 10.6.1.0, 10.7.1.1, 10.8.1.2 Reporter: Knut Anders Hatlen Assignee: Kathey Marsden Fix For: 10.9.0.0 Attachments: skip-sanity.diff The ThreadDump class in org.apache.derby.shared.common.sanity is included in the insane versions of derby.jar and derbyclient.jar. The sanity classes should only be included in debug builds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-4637) The Developer's Guide implies that, for in-memory database names, Derby does not resolve relative and absolute paths to the same in-memory database
[ https://issues.apache.org/jira/browse/DERBY-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085661#comment-13085661 ] Kristian Waagan commented on DERBY-4637: Would it suffice to rewrite the sentence referred to above, or do we need to write a new section for in-memory database names? The Developer's Guide implies that, for in-memory database names, Derby does not resolve relative and absolute paths to the same in-memory database --- Key: DERBY-4637 URL: https://issues.apache.org/jira/browse/DERBY-4637 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.6.1.0 Reporter: Rick Hillegas The Developer's Guide says in the section titled 'Conventions for specifying the database path': When accessing databases from the file system (instead of from memory, the classpath, or a jar file), any path that is not absolute is interpreted as relative to the system directory. A casual reader might interpret this to mean that the system directory is not used to resolve paths in the names of in-memory databases. But, in fact, Derby does use the system directory to qualify relative paths in the names of in-memory databases. For instance, if the system directory is /Users/blah/derby/dummy, then Derby treats the following urls as identifiers for the same in-memory database: jdbc:derby:memory:db jdbc:derby:memory:/Users/blah/derby/dummy/db Similarly, Derby treats the following urls as names for the same in-memory database: jdbc:derby:memory:/foo/bar/db jdbc:derby:memory:/foo/bar/../bar/db The Developer's Guide could use a section on how to resolve in-memory database names. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-4634) Error Message when launching Derby (SEVERE JDBC ERROR)
[ https://issues.apache.org/jira/browse/DERBY-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085663#comment-13085663 ] Kristian Waagan commented on DERBY-4634: Any updates on this? If we hear nothing more, we should probably close the issue. Error Message when launching Derby (SEVERE JDBC ERROR) -- Key: DERBY-4634 URL: https://issues.apache.org/jira/browse/DERBY-4634 Project: Derby Issue Type: Bug Components: Eclipse Plug-in, JDBC Affects Versions: 10.5.3.0 Environment: Windows, Eclipse 3.2.2, Derby 10.5.3.0 Reporter: michael jerusalmi Priority: Minor Labels: bug, derby, derby_triage10_8, jdbc, network, oracle, server, severe, starting I've been using Derby for a few days without any problems. But when I started Eclipse this morning, everytime I try to start Derby Network Server, I got this message : 28 avr. 2010 12:06:21 oracle.jdbc.driver.OracleDriver registerMBeans SEVERE: Error while registering Oracle JDBC Diagnosability MBean. java.security.AccessControlException: access denied (javax.management.MBeanServerPermission createMBeanServer) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.management.ManagementFactory.getPlatformMBeanServer(Unknown Source) at oracle.jdbc.driver.OracleDriver.registerMBeans(OracleDriver.java:306) at oracle.jdbc.driver.OracleDriver$1.run(OracleDriver.java:197) at java.security.AccessController.doPrivileged(Native Method) at oracle.jdbc.driver.OracleDriver.clinit(OracleDriver.java:193) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at sun.misc.Service$LazyIterator.next(Unknown Source) at java.sql.DriverService.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.sql.DriverManager.loadInitialDrivers(Unknown Source) at java.sql.DriverManager.initialize(Unknown Source) at java.sql.DriverManager.registerDriver(Unknown Source) at org.apache.derby.jdbc.AutoloadedDriver.clinit(Unknown Source) at org.apache.derby.jdbc.Driver20.boot(Unknown Source) at org.apache.derby.jdbc.Driver40.boot(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source) at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.startServices(Unknown Source) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown Source) at org.apache.derby.impl.services.monitor.FileMonitor.init(Unknown Source) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown Source) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source) at org.apache.derby.jdbc.EmbeddedDriver.clinit(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.startNetworkServer(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.blockingStart(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(Unknown Source) at org.apache.derby.drda.NetworkServerControl.main(Unknown Source) And even though, Derby seems to be launched as I got the message : 2010-04-28 10:06:21.689 GMT : Apache Derby network Server - 10.5.3.0 - (802917) started and ready to accept connections on port 1527 It's not a bolcking problem, as my WebApp is still working, but I've never seen it before. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-4670) ThreadDump class included in insane jars
[ https://issues.apache.org/jira/browse/DERBY-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085666#comment-13085666 ] Kathey Marsden commented on DERBY-4670: --- Yes I will. thank you for the reminder. It slipped off my radar. ThreadDump class included in insane jars Key: DERBY-4670 URL: https://issues.apache.org/jira/browse/DERBY-4670 Project: Derby Issue Type: Bug Components: Build tools Affects Versions: 10.6.1.0, 10.7.1.1, 10.8.1.2 Reporter: Knut Anders Hatlen Assignee: Kathey Marsden Fix For: 10.9.0.0 Attachments: skip-sanity.diff The ThreadDump class in org.apache.derby.shared.common.sanity is included in the insane versions of derby.jar and derbyclient.jar. The sanity classes should only be included in debug builds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-4533) Delete old releases from http://www.apache.org/dist
[ https://issues.apache.org/jira/browse/DERBY-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan closed DERBY-4533. -- Resolution: Fixed Fix Version/s: 10.9.0.0 Assignee: Kristian Waagan The mentioned releases have already been deleted by now, but I deleted the following additional releases: o db-derby-10.6.2.1 o db-derby-10.7.1.1 Closing issue. Delete old releases from http://www.apache.org/dist --- Key: DERBY-4533 URL: https://issues.apache.org/jira/browse/DERBY-4533 Project: Derby Issue Type: Task Components: Web Site Reporter: Sebb Assignee: Kristian Waagan Fix For: 10.9.0.0 The following old releases should be deleted from the main distribution folder: db-derby-10.3.3.0/ 19-May-2008 23:36- db-derby-10.4.2.0/ 08-Sep-2008 13:18- db-derby-10.5.1.1/ 29-Apr-2009 18:03- db-derby-10.5.2.0/ 31-Jul-2009 20:18- They are all available via the archives, so should be removed to free up space on the mirrors (and the ASF mirror masters). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-4637) The Developer's Guide implies that, for in-memory database names, Derby does not resolve relative and absolute paths to the same in-memory database
[ https://issues.apache.org/jira/browse/DERBY-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085669#comment-13085669 ] Rick Hillegas commented on DERBY-4637: -- Hi Kristian, It's probably sufficient just to rewrite that sentence so that it is clear that the same name resolution rules apply regardless of whether the database is on disk or in memory. Thanks. The Developer's Guide implies that, for in-memory database names, Derby does not resolve relative and absolute paths to the same in-memory database --- Key: DERBY-4637 URL: https://issues.apache.org/jira/browse/DERBY-4637 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.6.1.0 Reporter: Rick Hillegas The Developer's Guide says in the section titled 'Conventions for specifying the database path': When accessing databases from the file system (instead of from memory, the classpath, or a jar file), any path that is not absolute is interpreted as relative to the system directory. A casual reader might interpret this to mean that the system directory is not used to resolve paths in the names of in-memory databases. But, in fact, Derby does use the system directory to qualify relative paths in the names of in-memory databases. For instance, if the system directory is /Users/blah/derby/dummy, then Derby treats the following urls as identifiers for the same in-memory database: jdbc:derby:memory:db jdbc:derby:memory:/Users/blah/derby/dummy/db Similarly, Derby treats the following urls as names for the same in-memory database: jdbc:derby:memory:/foo/bar/db jdbc:derby:memory:/foo/bar/../bar/db The Developer's Guide could use a section on how to resolve in-memory database names. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Question on unloading in an embedded environment
I am writing a database copy utility that is built upon the dblook utility and using the SYSCS_UTIL.SYSCS_EXPORT_TABLE and SYSCS_UTIL.SYSCS_IMPORT_TABLE procedures and I have this mostly working. When running this on a large database (110Gb) I am getting an OutOfMemory exception. I have the utility setup to use up to 8192Mb of memory so somewhere there is a problem. I am running this again with the -XX:+HeapDumpOnOutOfMemoryError switch to see if I can get a picture on where it is leaking but it will take about 6 hours to get to this point. In the mean time, assuming the error is not in my utility, I would like to potentially shutdown the database and restart it to try to work around the OOME. I am running the database engine in embedded mode and see the documentation to shutdown the database, but I also see the following in the Derby 10.8 Reference manual page 293: With the embedded driver, if your application shuts down Derby or calls the DriverManager.unload method, and you then want to reload the driver, call the Class.forName().newInstance() method to do so: When I look at the Javadoc for the DriverManager class, I do not find an unload method. So what is this documentation referring to? Thanks Brett
[jira] [Resolved] (DERBY-4521) Stream passed out to user does not heed close, allowing reads after next ResultSet#getXXX
[ https://issues.apache.org/jira/browse/DERBY-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan resolved DERBY-4521. Resolution: Fixed Fix Version/s: 10.9.0.0 Marking as fixed, will update issue when DERBY-5090 has been closed/finalized. Stream passed out to user does not heed close, allowing reads after next ResultSet#getXXX - Key: DERBY-4521 URL: https://issues.apache.org/jira/browse/DERBY-4521 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1 Reporter: Dag H. Wanvik Priority: Minor Labels: derby_triage10_8 Fix For: 10.9.0.0 Attachments: repro.diff This was discovered investigating DERBY-4477 using the repro for DERBY-3646, which erroneously tries to keep two streams passed out via REsultSet#getBinaryStream open at the same time. This is prohibited by JDBC [1], but Derby allows it for non-materialized streams because the close call on the passed out stream (performed by EmbedResultSet#closeCurrentStream at the time of the next getXXX) is not heed by the underlying Derby stream. [1] http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html#getBinaryStream(int) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4532) Old download pages should refer to archive.apache.org only
[ https://issues.apache.org/jira/browse/DERBY-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-4532: --- Assignee: Kristian Waagan I'll clean this up. I haven't read through the release process document for Derby, but it appears to be broken for actions that need to take place to maintain the Derby website properly. Old download pages should refer to archive.apache.org only -- Key: DERBY-4532 URL: https://issues.apache.org/jira/browse/DERBY-4532 Project: Derby Issue Type: Bug Components: Web Site Affects Versions: 10.2.2.0, 10.4.1.3, 10.4.2.0, 10.5.1.1 Reporter: Sebb Assignee: Kristian Waagan The download page still shows lots of really old releases, which is fine. However, some of their download pages http://db.apache.org/derby/releases/release-10.2.2.0.html#Distributions http://db.apache.org/derby/releases/release-10.4.1.3.html#Distributions http://db.apache.org/derby/releases/release-10.4.2.0.html#Distributions http://db.apache.org/derby/releases/release-10.3.3.0.html#Distributions http://db.apache.org/derby/releases/release-10.5.1.1.html#Distributions still point to www.apache.org for the hashes and sig files. The pages should point to archive.apache.org for both the releases and the hashes/sigs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-3676) Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far
[ https://issues.apache.org/jira/browse/DERBY-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085684#comment-13085684 ] Kathey Marsden commented on DERBY-3676: --- On The test PreparedStatementTest is in the jdbc4 directory so that means it only runs with JDK 1.6 and higher. PrepareStatementTest is in the derbynet directiory and is a conversion of a test that tested some specific corner cases for client/server. The comment says. /** * This Junit test class tests the JDBC PreparedStatement. This test * is a Junit version of the old prepStmt.java test. That test tested * prepared statements in client/server context, and many of the test * cases is specifically testing corner cases in client/server * communication. However, this Junit test is set up to run as part * of both the embedded and client/server test suites. */ Since conversion the latter also runs with embedded so I guess it would make sense to move it to jdbcapi although it is not a comprehensive test of PreparedStatement functionality. Probably the best test if you want to see the behavior with all the parameter types might be ParameterMappingTest. On the functionality, I have lost sight of the final formatting solution. It would seem to make sense to match the output for derby.language.logStatementText=true plus include identifier of the compiled plan. Also I still prefer using toString() rather than a different method because a different method will require users to either use reflection or cast to the internal Derby types. Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far Key: DERBY-3676 URL: https://issues.apache.org/jira/browse/DERBY-3676 Project: Derby Issue Type: Improvement Components: JDBC Reporter: Rick Hillegas Assignee: Siddharth Srivastava Attachments: humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, ick.txt, ick.txt, prepared.diff, statementCacheVTI.sql This topic came up in the following email thread on the user list: http://www.nabble.com/PreparedStatement.toString%28%29---nice-formatting-td17250811.html#a17250811 Here's what the thread requests: In mysql, a toString() on a PreparedStatement will do this, eg select x from foo where x.a = ? will become select x from foo where x.a = 1 with the appropriate setValue() call. At first blush, this seems like it might be a simple project for a newcomer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Question on unloading in an embedded environment
On 8/16/11 5:56 AM, Bergquist, Brett wrote: I am writing a database copy utility that is built upon the dblook utility and using the SYSCS_UTIL.SYSCS_EXPORT_TABLE and SYSCS_UTIL.SYSCS_IMPORT_TABLE procedures and I have this mostly working. When running this on a large database (110Gb) I am getting an OutOfMemory exception. I have the utility setup to use up to 8192Mb of memory so somewhere there is a problem. I am running this again with the -XX:+HeapDumpOnOutOfMemoryError switch to see if I can get a picture on where it is leaking but it will take about 6 hours to get to this point. In the mean time, assuming the error is not in my utility, I would like to potentially shutdown the database and restart it to try to work around the OOME. I am running the database engine in embedded mode and see the documentation to shutdown the database, but I also see the following in the Derby 10.8 Reference manual page 293: With the embedded driver, if your application shuts down Derby or calls the DriverManager.unload method, and you then want to reload the driver, call the Class.forName().newInstance() method to do so: When I look at the Javadoc for the DriverManager class, I do not find an unload method. So what is this documentation referring to? Hi Brett, That looks like an error in the documentation. I believe it is supposed to refer to DriverManager.deregisterDriver(). I have logged https://issues.apache.org/jira/browse/DERBY-5384 to track this. Thanks for finding this bug, -Rick Thanks Brett
[jira] [Created] (DERBY-5384) Reference Guide talks about a DriverManager method which does not exist.
Reference Guide talks about a DriverManager method which does not exist. Key: DERBY-5384 URL: https://issues.apache.org/jira/browse/DERBY-5384 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Rick Hillegas The section titled java.sql.Driver interface in the Reference Guide mentions the DriverManager.unload() method. There is no such method. I believe that DriverManager.deregisterDriver() is intended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Question on unloading in an embedded environment
I am getting an OutOfMemory exception. I have the utility setup to use up to 8192Mb of memory so somewhere there is a problem. Brett Sometimes, these errors arise externally to Java; e.g., your system runs out of pagefile or swap space, etc. It might be worth checking to ensure that you have adequate system-wide resources. thanks, bryan
[jira] [Commented] (DERBY-4249) Create a simple store recovery test in JUnit
[
https://issues.apache.org/jira/browse/DERBY-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085739#comment-13085739
]
Kathey Marsden commented on DERBY-4249:
---
On the permissions issues it might help to add to derby_tests.policy for
derbyTesting.jar and derbyTesting.codeclasses, something like
permission java.io.FilePermission ${java.home}${/}-, execute
but I am not sure why other tests that use this method don't have the same
problem.
Create a simple store recovery test in JUnit
Key: DERBY-4249
URL: https://issues.apache.org/jira/browse/DERBY-4249
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.6.1.0
Reporter: Kathey Marsden
Assignee: Siddharth Srivastava
Priority: Minor
Attachments: d4249.diff, d4249_1.diff, d4249_2.diff, d4249_3.diff,
derby4249.diff, derby4249.diff
It would be good to be able to start converting the store recovery tests or
at least be able to write new recovery tests in JUnit. We could start by
writing a simple recovery test just to establish the framework. The test
should.
- Connect, create a table, commit and shutdown the database.
- fork a jvm, add one row, commit, add another row, exit the jvm.
- Reconnect with the first jvm and verify that the first row is there and
the second is not.
I guess the main thing to decide is how to spawn the second jvm and check
results.I tend to think the second jvm should actually execute another
JUnit test, verify the exit code (assuming a failed test has a non-zero exit
code) and then put the output in the fail assertion if it fails so it shows
up in the report at the end of the Suite execution. I think we could create
a test runner that takes a class and a specific test to run instead of the
whole suite, so we could keep our methods consolidated in a single class for
the test, but all pure conjecture at this point. I'll have to give it a try,
but wanted to first see if folks thought this was a reasonable approach.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DERBY-5384) Reference Guide talks about a DriverManager method which does not exist.
[ https://issues.apache.org/jira/browse/DERBY-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase reassigned DERBY-5384: Assignee: Kim Haase Reference Guide talks about a DriverManager method which does not exist. Key: DERBY-5384 URL: https://issues.apache.org/jira/browse/DERBY-5384 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Kim Haase The section titled java.sql.Driver interface in the Reference Guide mentions the DriverManager.unload() method. There is no such method. I believe that DriverManager.deregisterDriver() is intended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Report - Daily 1157896 - Sun DBTG
[Auto-generated mail] *Daily* 1157896/2011-08-15 18:00:22 MEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 01421514215 0 1546.00% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 046.97% derbyall 022 0 279.31% compatibility 022 0 .% demoSuite sles 01421514215 0 942.64% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 038.41% derbyall 022 0 144.31% compatibility 022 0 .% demoSuite sol 01420314203 0 1140.78% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 035.72% derbyall 022 0 162.33% compatibility 022 0 .% demoSuite sol32 01420314203 0 .% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 0 .% derbyall 022 0 .% compatibility 022 0 .% demoSuite solN+1 01420314203 0 218.28% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 054.65% derbyall 022 0 167.08% compatibility 022 0 .% demoSuite sparc 01420314203 0 586.42% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 026.76% derbyall 022 0 141.29% compatibility 022 0 .% demoSuite vista 01421314213 0 185.01% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 047.94% derbyall NA NA NANA compatibility 022 0 .% demoSuite vista-64 01421314213 0 266.10% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 047.87% derbyall NA NA NANA compatibility 022 0 .% demoSuite w2003 01421314213 0 365.95% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 059.72% derbyall NA NA NANA compatibility 022 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1157896.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/1157896_bySig.html *Jvm: 1.5* lin 0182182 041.87% derbyall 01223912239 0 2617.30% suitesAll sles 0182182 037.32% derbyall F:0,E:11223912238 0 1496.52% suitesAll sol 0182182 037.46% derbyall 01222712227 0 2150.40% suitesAll sol32 0182182 0 .% derbyall 01222712227 0 .% suitesAll solN+1 0182182 049.40% derbyall 01222712227 0 2185.49% suitesAll sparc 0182182 026.43% derbyall 01222712227 0 1364.44% suitesAll vista 0182182 037.06% derbyall F:1,E:01223712236 0 1299.72% suitesAll vista-64 0182182 048.23% derbyall 01223712237 0 299.51% suitesAll w2003 0182182 046.52%
[jira] [Updated] (DERBY-5384) Reference Guide talks about a DriverManager method which does not exist.
[ https://issues.apache.org/jira/browse/DERBY-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-5384: - Issue fix info: [Patch Available] Reference Guide talks about a DriverManager method which does not exist. Key: DERBY-5384 URL: https://issues.apache.org/jira/browse/DERBY-5384 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Kim Haase Attachments: DERBY-5384.diff, DERBY-5384.stat, DERBY-5384.zip The section titled java.sql.Driver interface in the Reference Guide mentions the DriverManager.unload() method. There is no such method. I believe that DriverManager.deregisterDriver() is intended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5384) Reference Guide talks about a DriverManager method which does not exist.
[ https://issues.apache.org/jira/browse/DERBY-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-5384: - Attachment: DERBY-5384.zip DERBY-5384.stat DERBY-5384.diff Actually, two topics mention the unload method; the other is Derby JDBC driver in the Developer's Guide. Attaching DERBY-5384.diff, DERBY-5384.stat, and DERBY-5384.zip, with these changes: M src/devguide/cdevdvlp40653.dita M src/ref/rrefjdbc32052.dita Reference Guide talks about a DriverManager method which does not exist. Key: DERBY-5384 URL: https://issues.apache.org/jira/browse/DERBY-5384 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Kim Haase Attachments: DERBY-5384.diff, DERBY-5384.stat, DERBY-5384.zip The section titled java.sql.Driver interface in the Reference Guide mentions the DriverManager.unload() method. There is no such method. I believe that DriverManager.deregisterDriver() is intended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5384) Reference Guide talks about a DriverManager method which does not exist.
[ https://issues.apache.org/jira/browse/DERBY-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085803#comment-13085803 ] Rick Hillegas commented on DERBY-5384: -- Looks good to me. Thanks, Kim. +1 Reference Guide talks about a DriverManager method which does not exist. Key: DERBY-5384 URL: https://issues.apache.org/jira/browse/DERBY-5384 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Kim Haase Attachments: DERBY-5384.diff, DERBY-5384.stat, DERBY-5384.zip The section titled java.sql.Driver interface in the Reference Guide mentions the DriverManager.unload() method. There is no such method. I believe that DriverManager.deregisterDriver() is intended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-5384) Reference Guide talks about a DriverManager method which does not exist.
[ https://issues.apache.org/jira/browse/DERBY-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase resolved DERBY-5384. -- Resolution: Fixed Fix Version/s: 10.9.0.0 10.8.1.6 Issue fix info: (was: [Patch Available]) Thanks very much, Rick! Committed patch DERBY-5384.diff to documentation trunk at revision 1158368. Merged to 10.8 doc branch at revision 1158391. Reference Guide talks about a DriverManager method which does not exist. Key: DERBY-5384 URL: https://issues.apache.org/jira/browse/DERBY-5384 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Rick Hillegas Assignee: Kim Haase Fix For: 10.8.1.6, 10.9.0.0 Attachments: DERBY-5384.diff, DERBY-5384.stat, DERBY-5384.zip The section titled java.sql.Driver interface in the Reference Guide mentions the DriverManager.unload() method. There is no such method. I believe that DriverManager.deregisterDriver() is intended. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-268) Add Support for truncate table
[ https://issues.apache.org/jira/browse/DERBY-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085878#comment-13085878 ] Myrna van Lunteren commented on DERBY-268: -- Eranda, are you still working on this issue? Add Support for truncate table -- Key: DERBY-268 URL: https://issues.apache.org/jira/browse/DERBY-268 Project: Derby Issue Type: Improvement Components: SQL Reporter: Lance Andersen Assignee: Eranda Sooriyabandara Priority: Minor Attachments: Derby-268.diff, Derby-268.diff, TruncateConcurrency.java, TruncateConcurrency.java, TruncateConcurrency.java, changes.diff, derby-268-01-ab-enableForInsaneBuilds.diff, derby-268-02-aa-permsTest.diff, derby-268-03-aa-npe.diff, tests.diff Adding support for truncate table command will aid to portability -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DERBY-268) Add Support for truncate table
[ https://issues.apache.org/jira/browse/DERBY-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085878#comment-13085878 ] Myrna van Lunteren edited comment on DERBY-268 at 8/16/11 6:30 PM: --- Eranda, are you still working on this issue? If not, we should unassign you, and probably close this issue and split off a separate issue to support the identityBehavior functionality. was (Author: myrna): Eranda, are you still working on this issue? Add Support for truncate table -- Key: DERBY-268 URL: https://issues.apache.org/jira/browse/DERBY-268 Project: Derby Issue Type: Improvement Components: SQL Reporter: Lance Andersen Assignee: Eranda Sooriyabandara Priority: Minor Attachments: Derby-268.diff, Derby-268.diff, TruncateConcurrency.java, TruncateConcurrency.java, TruncateConcurrency.java, changes.diff, derby-268-01-ab-enableForInsaneBuilds.diff, derby-268-02-aa-permsTest.diff, derby-268-03-aa-npe.diff, tests.diff Adding support for truncate table command will aid to portability -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-4962) Create a table function which efficiently migrates data out of foreign databases and which can be used for ongoing data integration
[ https://issues.apache.org/jira/browse/DERBY-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas closed DERBY-4962. Resolution: Fixed Create a table function which efficiently migrates data out of foreign databases and which can be used for ongoing data integration --- Key: DERBY-4962 URL: https://issues.apache.org/jira/browse/DERBY-4962 Project: Derby Issue Type: Improvement Components: Tools Reporter: Rick Hillegas Attachments: ForeignTableVTI.java DDLUtils and other tools are good at copying the shape of foreign schemas into Derby. It would be good to have a tool which efficiently bulk-copies the foreign data into Derby. This would be faster than having to dump the foreign data into flat files and then import those files into Derby. In addition, many data integration applications need to siphon new data out of foreign database on an ongoing basis. A tool based around a RestrictedVTI would be able to push the column projection and WHERE clause into the foreign database in order to speed up the siphoning. I will attach a Restricted VTI which can be used for the following tasks: 1) Initial bulk-loading of Derby from a foreign database. 2) Efficient on-going data integration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-4518) Document ORDER BY and OFFSET/FETCH in subqueries
[ https://issues.apache.org/jira/browse/DERBY-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik resolved DERBY-4518. -- Resolution: Fixed Document ORDER BY and OFFSET/FETCH in subqueries Key: DERBY-4518 URL: https://issues.apache.org/jira/browse/DERBY-4518 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Dag H. Wanvik Fix For: 10.6.1.0 Attachments: DERBY-4518-2.diff, DERBY-4518-2.zip, DERBY-4518-3.diff, DERBY-4518-3.zip, DERBY-4518.diff, DERBY-4518.stat, DERBY-4518.zip DERBY-4397 and DERBY-4398 extends the usability of ORDER BY and OFFSET/FETCH to subqueries and view. This should be documented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-4518) Document ORDER BY and OFFSET/FETCH in subqueries
[ https://issues.apache.org/jira/browse/DERBY-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik closed DERBY-4518. Closing this as suggested, opening a new JIRA for the improvement, cf. link. Document ORDER BY and OFFSET/FETCH in subqueries Key: DERBY-4518 URL: https://issues.apache.org/jira/browse/DERBY-4518 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Dag H. Wanvik Fix For: 10.6.1.0 Attachments: DERBY-4518-2.diff, DERBY-4518-2.zip, DERBY-4518-3.diff, DERBY-4518-3.zip, DERBY-4518.diff, DERBY-4518.stat, DERBY-4518.zip DERBY-4397 and DERBY-4398 extends the usability of ORDER BY and OFFSET/FETCH to subqueries and view. This should be documented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5385) Improve documentation for OFFSET/FETCH NEXT
Improve documentation for OFFSET/FETCH NEXT --- Key: DERBY-5385 URL: https://issues.apache.org/jira/browse/DERBY-5385 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.8.1.2 Reporter: Dag H. Wanvik cf the suggestion in DERBY-4518. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-4518) Document ORDER BY and OFFSET/FETCH in subqueries
[ https://issues.apache.org/jira/browse/DERBY-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik resolved DERBY-4518. -- Resolution: Fixed Document ORDER BY and OFFSET/FETCH in subqueries Key: DERBY-4518 URL: https://issues.apache.org/jira/browse/DERBY-4518 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Dag H. Wanvik Assignee: Kim Haase Fix For: 10.6.1.0 Attachments: DERBY-4518-2.diff, DERBY-4518-2.zip, DERBY-4518-3.diff, DERBY-4518-3.zip, DERBY-4518.diff, DERBY-4518.stat, DERBY-4518.zip DERBY-4397 and DERBY-4398 extends the usability of ORDER BY and OFFSET/FETCH to subqueries and view. This should be documented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-4518) Document ORDER BY and OFFSET/FETCH in subqueries
[ https://issues.apache.org/jira/browse/DERBY-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik closed DERBY-4518. Document ORDER BY and OFFSET/FETCH in subqueries Key: DERBY-4518 URL: https://issues.apache.org/jira/browse/DERBY-4518 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Dag H. Wanvik Assignee: Kim Haase Fix For: 10.6.1.0 Attachments: DERBY-4518-2.diff, DERBY-4518-2.zip, DERBY-4518-3.diff, DERBY-4518-3.zip, DERBY-4518.diff, DERBY-4518.stat, DERBY-4518.zip DERBY-4397 and DERBY-4398 extends the usability of ORDER BY and OFFSET/FETCH to subqueries and view. This should be documented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (DERBY-4518) Document ORDER BY and OFFSET/FETCH in subqueries
[ https://issues.apache.org/jira/browse/DERBY-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik reopened DERBY-4518: -- Assignee: Kim Haase Document ORDER BY and OFFSET/FETCH in subqueries Key: DERBY-4518 URL: https://issues.apache.org/jira/browse/DERBY-4518 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Dag H. Wanvik Assignee: Kim Haase Fix For: 10.6.1.0 Attachments: DERBY-4518-2.diff, DERBY-4518-2.zip, DERBY-4518-3.diff, DERBY-4518-3.zip, DERBY-4518.diff, DERBY-4518.stat, DERBY-4518.zip DERBY-4397 and DERBY-4398 extends the usability of ORDER BY and OFFSET/FETCH to subqueries and view. This should be documented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5385) Improve documentation for OFFSET/FETCH NEXT
[ https://issues.apache.org/jira/browse/DERBY-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-5385: - Affects Version/s: 10.6.1.0 10.6.2.1 10.7.1.1 Improve documentation for OFFSET/FETCH NEXT --- Key: DERBY-5385 URL: https://issues.apache.org/jira/browse/DERBY-5385 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2 Reporter: Dag H. Wanvik cf the suggestion in DERBY-4518. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085945#comment-13085945 ] Dag H. Wanvik commented on DERBY-5363: -- Thanks for finding this , Kristian. I would think we could set the Java 6 compile classpath using Java 7. I'll add that unless somebody has misgivings. If we omit this extension of the property setter for this issue (as seems likely), I'll make a new issue and attach the preliminary patch of the Java 7 enabling to that so we can save it for later. Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085981#comment-13085981 ] Kathey Marsden commented on DERBY-5363: --- I am just back from vacation and looking at this issue, so my apologies for not speaking up sooner, but I am quite concerned about having a new more restrictive default. I can recall conversations with quite a few different development groups around the requirement that multiple users be able to access the database. I have always told them that as long as the users are in the same group and umask is set appropriately this should work fine. I am concerned about breaking those applications with this change. I think with embedded it is fairly common to have multiple users accessing the database and think the default should be the old behavior and allow the more restrictive file permissions with an option. Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-4670) ThreadDump class included in insane jars
[ https://issues.apache.org/jira/browse/DERBY-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-4670. --- Resolution: Fixed Fix Version/s: 10.8.1.6 10.7.1.4 10.6.2.3 Assignee: Knut Anders Hatlen (was: Kathey Marsden) ported fix to 10.8, 10.7 and 10.6 where it first appeared. ThreadDump class included in insane jars Key: DERBY-4670 URL: https://issues.apache.org/jira/browse/DERBY-4670 Project: Derby Issue Type: Bug Components: Build tools Affects Versions: 10.6.1.0, 10.7.1.1, 10.8.1.2 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.6.2.3, 10.7.1.4, 10.8.1.6, 10.9.0.0 Attachments: skip-sanity.diff The ThreadDump class in org.apache.derby.shared.common.sanity is included in the insane versions of derby.jar and derbyclient.jar. The sanity classes should only be included in debug builds. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086073#comment-13086073 ] Dag H. Wanvik commented on DERBY-5363: -- I agree this behavior could be too restrictive for embedded usage. Do you think it is more reasonable in a server context, Kathey? I think it would be good to improve our secure by default story a bit these days... Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-3676) Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far
[ https://issues.apache.org/jira/browse/DERBY-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086074#comment-13086074 ] Siddharth Srivastava commented on DERBY-3676: - I too think toString() would be a more intuitive way. As I don' t think an explicit cast would be preferred by the users and hence wouldn't serve the purpose of the method. Moreover, as far as output format is concerned, following is what I would like to propose(Need reviews on this): For a statement as follows: PreparedStatement ps = conn.prepareStatement(INSERT INTO demo(ID,dBlob) VALUES(?,?)); ps.setInt(1,1); ps.setBlob(1,is,BYTES.length); System.out.println(ps.toString()), currently outputs:ace4c0a3-0131-d540-4992-030d5ec8 New Proposed format: (based on logStatementText) CacheId:6c44409f-0131-d546-4475-030d5ec8::INSERT INTO Orders1(ID,dBlob) VALUES(?,?)::parameter #1: 1::parameter #2: BLOB(org.apache.derby.iapi.types.RawToBinaryFormatStream@5c2a1ed) For client PreparedStatement, cacheid can be set as null. Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far Key: DERBY-3676 URL: https://issues.apache.org/jira/browse/DERBY-3676 Project: Derby Issue Type: Improvement Components: JDBC Reporter: Rick Hillegas Assignee: Siddharth Srivastava Attachments: humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, ick.txt, ick.txt, prepared.diff, statementCacheVTI.sql This topic came up in the following email thread on the user list: http://www.nabble.com/PreparedStatement.toString%28%29---nice-formatting-td17250811.html#a17250811 Here's what the thread requests: In mysql, a toString() on a PreparedStatement will do this, eg select x from foo where x.a = ? will become select x from foo where x.a = 1 with the appropriate setValue() call. At first blush, this seems like it might be a simple project for a newcomer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DERBY-3676) Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far
[ https://issues.apache.org/jira/browse/DERBY-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086074#comment-13086074 ] Siddharth Srivastava edited comment on DERBY-3676 at 8/17/11 1:12 AM: -- I too think toString() would be a more intuitive way. As I don' t think an explicit cast would be preferred by the users and hence wouldn't serve the purpose of the method. Moreover, as far as output format is concerned, following is what I would like to propose(Need reviews on this): For a statement as follows: PreparedStatement ps = conn.prepareStatement(INSERT INTO demo(ID,dBlob) VALUES(?,?)); ps.setInt(1,1); ps.setBlob(1,is,BYTES.length); System.out.println(ps.toString()), currently outputs:ace4c0a3-0131-d540-4992-030d5ec8 New Proposed format: (based on logStatementText) CacheId:ace4c0a3-0131-d540-4992-030d5ec8::INSERT INTO Orders1(ID,dBlob) VALUES(?,?)::parameter #1: 1::parameter #2: BLOB(org.apache.derby.iapi.types.RawToBinaryFormatStream@5c2a1ed) For client PreparedStatement, cacheid can be set as null. was (Author: siddharthsrivastava): I too think toString() would be a more intuitive way. As I don' t think an explicit cast would be preferred by the users and hence wouldn't serve the purpose of the method. Moreover, as far as output format is concerned, following is what I would like to propose(Need reviews on this): For a statement as follows: PreparedStatement ps = conn.prepareStatement(INSERT INTO demo(ID,dBlob) VALUES(?,?)); ps.setInt(1,1); ps.setBlob(1,is,BYTES.length); System.out.println(ps.toString()), currently outputs:ace4c0a3-0131-d540-4992-030d5ec8 New Proposed format: (based on logStatementText) CacheId:6c44409f-0131-d546-4475-030d5ec8::INSERT INTO Orders1(ID,dBlob) VALUES(?,?)::parameter #1: 1::parameter #2: BLOB(org.apache.derby.iapi.types.RawToBinaryFormatStream@5c2a1ed) For client PreparedStatement, cacheid can be set as null. Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far Key: DERBY-3676 URL: https://issues.apache.org/jira/browse/DERBY-3676 Project: Derby Issue Type: Improvement Components: JDBC Reporter: Rick Hillegas Assignee: Siddharth Srivastava Attachments: humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, ick.txt, ick.txt, prepared.diff, statementCacheVTI.sql This topic came up in the following email thread on the user list: http://www.nabble.com/PreparedStatement.toString%28%29---nice-formatting-td17250811.html#a17250811 Here's what the thread requests: In mysql, a toString() on a PreparedStatement will do this, eg select x from foo where x.a = ? will become select x from foo where x.a = 1 with the appropriate setValue() call. At first blush, this seems like it might be a simple project for a newcomer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DERBY-5385) Improve documentation for OFFSET/FETCH NEXT
[ https://issues.apache.org/jira/browse/DERBY-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase reassigned DERBY-5385: Assignee: Kim Haase Improve documentation for OFFSET/FETCH NEXT --- Key: DERBY-5385 URL: https://issues.apache.org/jira/browse/DERBY-5385 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2 Reporter: Dag H. Wanvik Assignee: Kim Haase cf the suggestion in DERBY-4518. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
