[jira] Updated: (DERBY-23) just booting jdbc driver and shutting down seem to leak memory
[ http://issues.apache.org/jira/browse/DERBY-23?page=all ] Knut Anders Hatlen updated DERBY-23: Attachment: DERBY-23-with_comments.diff Attached patch with comments where appropriate. just booting jdbc driver and shutting down seem to leak memory -- Key: DERBY-23 URL: http://issues.apache.org/jira/browse/DERBY-23 Project: Derby Type: Bug Components: Services Versions: 10.0.2.0 Reporter: Tulika Agrawal Assignee: Knut Anders Hatlen Priority: Minor Attachments: DERBY-23-with_comments.diff, DERBY-23.diff, DERBY-23.stat Reporting for Daniel John Debrunner. Doing simple boot and shutdown of the driver in a loop seem to grow the heap forever: new org.apache.derby.jdbc.EmbeddedDriver(); //boot the driver DriverManager.getConnection(jdbc:derby:;shutdown=true); //shutdown the cloudscape instance completely after booting and shutting down 1516 times, memory used is ~~41931056 bytes. Sample GC Output: 1931.93: [Full GC 43484K-43243K(65088K), 0.1779751 secs] 1933.13: [Full GC 43511K-43270K(65088K), 0.1914383 secs] 1934.47: [Full GC 43538K-43297K(65088K), 0.1808878 secs] 1935.68: [Full GC 43564K-43324K(65088K), 0.4461623 secs] 1937.43: [Full GC 43591K-43350K(65088K), 0.1842980 secs] 1938.63: [Full GC 43617K-43377K(65088K), 0.1873431 secs] 1939.85: [Full GC 43644K-43404K(65088K), 0.1948505 secs] 1941.07: [Full GC 43671K-43430K(65088K), 0.1790895 secs] -- 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] Reopened: (DERBY-504) SELECT DISTINCT returns duplicates when selecting from subselects
[ http://issues.apache.org/jira/browse/DERBY-504?page=all ] Knut Anders Hatlen reopened DERBY-504: -- Reopen the bug so the fix can be included in 10.1.2. Since the bug was reported on derby-user before 10.1.1 was released, I think it should be fixed in 10.1.2. SELECT DISTINCT returns duplicates when selecting from subselects - Key: DERBY-504 URL: http://issues.apache.org/jira/browse/DERBY-504 Project: Derby Type: Bug Components: SQL Versions: 10.1.2.0 Environment: Latest development sources (SVN revision 232227), Sun JDK 1.5, Solaris/x86 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.1.2.0 Attachments: DERBY-504-10.1-unix.diff, DERBY-504-10.1-windows.diff, DERBY-504-10.1.stat, DERBY-504-cleanup.diff, DERBY-504-cleanup.stat, DERBY-504.diff, DERBY-504.stat, DERBY-504_b.diff, DERBY-504_b.stat, DERBY-504_c-CRLF.diff, DERBY-504_c-CRLF.diff, DERBY-504_c.diff, DERBY-504_c.stat When one performs a select distinct on a table generated by a subselect, there sometimes are duplicates in the result. The following example shows the problem: ij CREATE TABLE names (id INT PRIMARY KEY, name VARCHAR(10)); 0 rows inserted/updated/deleted ij INSERT INTO names (id, name) VALUES (1, 'Anna'), (2, 'Ben'), (3, 'Carl'), (4, 'Carl'), (5, 'Ben'), (6, 'Anna'); 6 rows inserted/updated/deleted ij SELECT DISTINCT(name) FROM (SELECT name, id FROM names) AS n; NAME -- Anna Ben Carl Carl Ben Anna Six names are returned, although only three names should have been returned. When the result is explicitly sorted (using ORDER BY) or the id column is removed from the subselect, the query returns three names as expected: ij SELECT DISTINCT(name) FROM (SELECT name, id FROM names) AS n ORDER BY name; NAME -- Anna Ben Carl 3 rows selected ij SELECT DISTINCT(name) FROM (SELECT name FROM names) AS n; NAME -- Anna Ben Carl 3 rows selected -- 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-504) SELECT DISTINCT returns duplicates when selecting from subselects
[ http://issues.apache.org/jira/browse/DERBY-504?page=all ] Knut Anders Hatlen updated DERBY-504: - Fix Version: 10.1.2.0 (was: 10.2.0.0) Version: 10.1.2.0 (was: 10.2.0.0) Changed fix version. SELECT DISTINCT returns duplicates when selecting from subselects - Key: DERBY-504 URL: http://issues.apache.org/jira/browse/DERBY-504 Project: Derby Type: Bug Components: SQL Versions: 10.1.2.0 Environment: Latest development sources (SVN revision 232227), Sun JDK 1.5, Solaris/x86 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.1.2.0 Attachments: DERBY-504-10.1-unix.diff, DERBY-504-10.1-windows.diff, DERBY-504-10.1.stat, DERBY-504-cleanup.diff, DERBY-504-cleanup.stat, DERBY-504.diff, DERBY-504.stat, DERBY-504_b.diff, DERBY-504_b.stat, DERBY-504_c-CRLF.diff, DERBY-504_c-CRLF.diff, DERBY-504_c.diff, DERBY-504_c.stat When one performs a select distinct on a table generated by a subselect, there sometimes are duplicates in the result. The following example shows the problem: ij CREATE TABLE names (id INT PRIMARY KEY, name VARCHAR(10)); 0 rows inserted/updated/deleted ij INSERT INTO names (id, name) VALUES (1, 'Anna'), (2, 'Ben'), (3, 'Carl'), (4, 'Carl'), (5, 'Ben'), (6, 'Anna'); 6 rows inserted/updated/deleted ij SELECT DISTINCT(name) FROM (SELECT name, id FROM names) AS n; NAME -- Anna Ben Carl Carl Ben Anna Six names are returned, although only three names should have been returned. When the result is explicitly sorted (using ORDER BY) or the id column is removed from the subselect, the query returns three names as expected: ij SELECT DISTINCT(name) FROM (SELECT name, id FROM names) AS n ORDER BY name; NAME -- Anna Ben Carl 3 rows selected ij SELECT DISTINCT(name) FROM (SELECT name FROM names) AS n; NAME -- Anna Ben Carl 3 rows selected -- 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: 10.1.2 Release status page
Daniel John Debrunner wrote: Francois Orsini wrote: Nightly builds should only be posted if regression tests have passed IMHO. I disagree, a nightly build is use at your own risk. Even if one test fails the jar may still work and allow anyone to test other areas. I think the nightly build should be the build used in the testing reported at http://www.multinet.no/~solberg/public/Apache/Derby/index.html/ That way, people can download and use a nightly build at their own risk, but they can also see what tests the build has passed/failed. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43419 / +47 73842119, Fax: +47 73842101
[jira] Commented: (DERBY-577) Test harness should not change the user.dir property , it is meant for infomative purpose only.
[ http://issues.apache.org/jira/browse/DERBY-577?page=comments#action_12329982 ] Thomas Lecavelier commented on DERBY-577: - Hi Suresh, I follow the references about userDirName, it appears it's build from System.getProperties() and I see nowhere userDirName is modified. If you see an occurence, could you specify where, please? Anyway, it seems user.dir is only use to create a tree of nested directories in order to perform tests. Maybe it could be remove safely from the jvm argLine used for the tests. Test harness should not change the user.dir property , it is meant for infomative purpose only. Key: DERBY-577 URL: http://issues.apache.org/jira/browse/DERBY-577 Project: Derby Type: Improvement Components: Test Reporter: Suresh Thalamati Priority: Minor If the user.dir property is changed , you wil find IO calls are working on different directory than what is returned by File.getAbsolutePath() if the file handle is created with a relative path because of JVM issue: 4117557 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4117557 I think it is not good idea for test harness to change the user.dir property.It makes hard to debug tests , because files are not created at diferent location than what is returned by getAbsolutePath().Atleast, I had fun time figuring out this :-) user.dir is being changed at the following code segment : org.apache.derbyTesting.functionTests.harness. RunTest.java testJvmProps.addElement(user.dir=+userDirName); -- 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-579) Query timeout set for one statement may affect other statements with the same SQL string
Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assigned to: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- 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-504) SELECT DISTINCT returns duplicates when selecting from subselects
Knut Anders Hatlen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-504?page=all ] Knut Anders Hatlen updated DERBY-504: - Fix Version: 10.1.2.0 (was: 10.2.0.0) Version: 10.1.2.0 (was: 10.2.0.0) Changed fix version. Jira allows multiple fix versions, so if this bug was already fixed in 10.2.0.0 that fix version should remain, and 10.1.2.0 added. Dan.
[jira] Updated: (DERBY-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo updated DERBY-579: - Attachment: DERBY-579.svn.status Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- 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-579) Query timeout set for one statement may affect other statements with the same SQL string
[ http://issues.apache.org/jira/browse/DERBY-579?page=all ] Oyvind Bakksjo updated DERBY-579: - Attachment: DERBY-579.svn.diff This patch fixes the bug as proposed by Dan Debrunner (pass the timeout into the execute method of org.apache.derby.iapi.sql.PreparedStatement, not store it as a field in GenericPreparedStatement.). jdbcapi test has been run without errors. Currently running derbyall. svn diff executed on revision 290453. Query timeout set for one statement may affect other statements with the same SQL string Key: DERBY-579 URL: http://issues.apache.org/jira/browse/DERBY-579 Project: Derby Type: Bug Components: SQL Reporter: Oyvind Bakksjo Assignee: Oyvind Bakksjo Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-579.svn.diff, DERBY-579.svn.status The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-574) Per JDBC connection timeouts are incorrectly set on org.apache.derby.iapi.sql.PreparedStatement which represents a shared plan.
[ http://issues.apache.org/jira/browse/DERBY-574?page=all ] Oyvind Bakksjo closed DERBY-574: Fix Version: (was: 10.2.0.0) Resolution: Duplicate Per JDBC connection timeouts are incorrectly set on org.apache.derby.iapi.sql.PreparedStatement which represents a shared plan. --- Key: DERBY-574 URL: http://issues.apache.org/jira/browse/DERBY-574 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Reporter: Daniel John Debrunner The timeout is being set on the class GenericPreparedStatement, but this represents a statement plan and can be shared across multiple connections (through the statement cache). Thus if two connections execute the same statement with different timeouts, they will interfere with each other with the timeout values. I think the solution is to pass the timeout into the execute method of org.apache.derby.iapi.sql.PreparedStatement, not store it as a field in GenericPreparedStatement. [from http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL PROTECTED] ] -- 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-504) SELECT DISTINCT returns duplicates when selecting from subselects
[ http://issues.apache.org/jira/browse/DERBY-504?page=all ] Knut Anders Hatlen updated DERBY-504: - Fix Version: 10.2.0.0 SELECT DISTINCT returns duplicates when selecting from subselects - Key: DERBY-504 URL: http://issues.apache.org/jira/browse/DERBY-504 Project: Derby Type: Bug Components: SQL Versions: 10.1.2.0 Environment: Latest development sources (SVN revision 232227), Sun JDK 1.5, Solaris/x86 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0, 10.1.2.0 Attachments: DERBY-504-10.1-unix.diff, DERBY-504-10.1-windows.diff, DERBY-504-10.1.stat, DERBY-504-cleanup.diff, DERBY-504-cleanup.stat, DERBY-504.diff, DERBY-504.stat, DERBY-504_b.diff, DERBY-504_b.stat, DERBY-504_c-CRLF.diff, DERBY-504_c-CRLF.diff, DERBY-504_c.diff, DERBY-504_c.stat When one performs a select distinct on a table generated by a subselect, there sometimes are duplicates in the result. The following example shows the problem: ij CREATE TABLE names (id INT PRIMARY KEY, name VARCHAR(10)); 0 rows inserted/updated/deleted ij INSERT INTO names (id, name) VALUES (1, 'Anna'), (2, 'Ben'), (3, 'Carl'), (4, 'Carl'), (5, 'Ben'), (6, 'Anna'); 6 rows inserted/updated/deleted ij SELECT DISTINCT(name) FROM (SELECT name, id FROM names) AS n; NAME -- Anna Ben Carl Carl Ben Anna Six names are returned, although only three names should have been returned. When the result is explicitly sorted (using ORDER BY) or the id column is removed from the subselect, the query returns three names as expected: ij SELECT DISTINCT(name) FROM (SELECT name, id FROM names) AS n ORDER BY name; NAME -- Anna Ben Carl 3 rows selected ij SELECT DISTINCT(name) FROM (SELECT name FROM names) AS n; NAME -- Anna Ben Carl 3 rows selected -- 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-428) NetworkClient PreparedStatement.executeBatch() hangs if batch is too large (ArrayIndexOutOfBoundsException in Network Server)
[
http://issues.apache.org/jira/browse/DERBY-428?page=comments#action_12330002 ]
Gregory W. Inns commented on DERBY-428:
---
We're getting one similar to this one, but only sporadically.
Does anyone know a workaround for it?
NetworkClient PreparedStatement.executeBatch() hangs if batch is too large
(ArrayIndexOutOfBoundsException in Network Server)
-
Key: DERBY-428
URL: http://issues.apache.org/jira/browse/DERBY-428
Project: Derby
Type: Bug
Components: Network Client
Environment: Linux atum01 2.4.20-31.9 #1 Tue Apr 13 18:04:23 EDT 2004 i686
i686 i386 GNU/Linux
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode, sharing)
Reporter: Bernt M. Johnsen
When running
s.executeUpdate(create table t (i integer));
PreparedStatement p = c.prepareStatement(insert into t values(?));
for (int i=0; iN; i++) {
p.setInt(1,i);
p.addBatch();
}
System.out.println(Ok);
p.executeBatch();
If N is 9000
The server reports:
524272
java.lang.ArrayIndexOutOfBoundsException: 524272
at org.apache.derby.impl.drda.DDMWriter.startDdm(DDMWriter.java:315)
at
org.apache.derby.impl.drda.DRDAConnThread.writeSQLCARD(DRDAConnThread.java:4937)
at
org.apache.derby.impl.drda.DRDAConnThread.writeSQLCARDs(DRDAConnThread.java:4898)
at
org.apache.derby.impl.drda.DRDAConnThread.writeSQLCARDs(DRDAConnThread.java:4888)
at
org.apache.derby.impl.drda.DRDAConnThread.checkWarning(DRDAConnThread.java:7239)
at
org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(DRDAConnThread.java:3605)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:859)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:214)
agentThread[DRDAConnThread_3,5,main]
While the client hangs in executeBatch().
If N is 8000, the client gets the following Exception:
Exception in thread main org.apache.derby.client.am.BatchUpdateException:
Non-atomic batch failure. The batch was submitted, but at least one
exception occurred on an individual member of the batch. Use
getNextException() to retrieve the exceptions for specific batched elements.
at
org.apache.derby.client.am.Agent.endBatchedReadChain(Agent.java:267)
at
org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(PreparedStatement.java:1596)
at
org.apache.derby.client.am.PreparedStatement.executeBatchX(PreparedStatement.java:1467)
at
org.apache.derby.client.am.PreparedStatement.executeBatch(PreparedStatement.java:945)
at AOIB.main(AOIB.java:24)
--
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-374) Invalid URL with Derby Client when connecting to Network Server causes protocol exception.
Kathey, I checked with network server trace on and for the URLs below, the server does not reach till ACCRDB response to send a RDBAFLRM. * 'jdbc:derby://localhost:1527/sample:create=true' * 'jdbc:derby://localhost:1527/C:/myDBs/sample;create=true' These URLs cause a NullPointerException in the server. The NPE is caused in Database.makeConnection method at the second line below: Connection conn = NetworkServerControlImpl.getDriver().connect(Attribute.PROTOCOL + dbName + attrString, p); conn.setAutoCommit(false); InternalDriver connect method returns null for these URLs because it does not find a suitable driver. No exception is thrown by InternalDriver. At the server, Database.makeConnection proceeds to the next statement conn.SetAutoCommit(false) and it gets a NPE. The root cause of the problem is in network server. So I will remove my patch which added checks for malformed URLs in ClientDriver. I am changing the server to handle such URLs. Army, the problem you mentioned about use of single quotes will also be handled by the server after this change. I am using RDBAFLRM for failure to find a suitable driver. Is this okay or is there any specific message type that must be used in such a case? When looking at this, I found another problem in the translation of the network URL. The network URL 'jdbc:derby://localhost:1527/C:/myDBs/sample;create=true' gets translated to the internal URL 'jdbc:derby:C:/myDBs/sample;create=true;create=true'. The create attribute gets repeated and the database name used at server is C:/myDBs/sample;create=true. I have not yet looked at this problem. Thanks, Deepa
[jira] Commented: (DERBY-573) Provider support for optimizer overrides in Derby.
[ http://issues.apache.org/jira/browse/DERBY-573?page=comments#action_12330020 ] Satheesh Bandaram commented on DERBY-573: - It should be possible to enhance current Derby RunTimeStatistics mechanism to display user specified optimizer directives being used if specified. Since optimizer directives are typically used by application developer, not the end users, it should be easy for them to confirm the directives are taking effect. Derby provides several ways to get execution plans... including RunTimeStatistics or derby.language.logQueryPlan. These mechanisms can specify when optimizer directives are being used. Provider support for optimizer overrides in Derby. -- Key: DERBY-573 URL: http://issues.apache.org/jira/browse/DERBY-573 Project: Derby Type: New Feature Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Attachments: optimizeroverrides.html Derby's query optimizer usually makes the best choice of join order and access path. The default join strategy ususally works the best too. However, there are some cases in which user may want to override the optimizer or the default values. Providing support for optimizer overrides will allow users to hand-tune the optimizer for queries. -- 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-374) Invalid URL with Derby Client when connecting to Network Server causes protocol exception.
Deepa Remesh wrote: I am using RDBAFLRM for failure to find a suitable driver. Is this okay or is there any specific message type that must be used in such a case? I think that is the best we can do from the server side as we cannot send a full SQLCARD in this case. I am not sure what message the client reports when this is returned by the server. If it does not seem informative enough, we could always add additional checking to the client to have it made clear and make the message match the embedded driver. But I think you are right in taking the first step of fixing the NPE in the server and returning RDBAFLRM when the server cannot make a connection. Kathey
[jira] Commented: (DERBY-573) Provider support for optimizer overrides in Derby.
[ http://issues.apache.org/jira/browse/DERBY-573?page=comments#action_12330031 ] Mamta A. Satoor commented on DERBY-573: --- I can look into modifying the RunTimeStatistics to indicate that user overrides are being used. Also, I will see how parser can be modified to look for --DERBY-HINTS rather than just --PROPERTIES. If people prefer DERBY-PROPERTIES over DERBY-HINTS, please put comment stating so to this JIRA entry. Provider support for optimizer overrides in Derby. -- Key: DERBY-573 URL: http://issues.apache.org/jira/browse/DERBY-573 Project: Derby Type: New Feature Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Attachments: optimizeroverrides.html Derby's query optimizer usually makes the best choice of join order and access path. The default join strategy ususally works the best too. However, there are some cases in which user may want to override the optimizer or the default values. Providing support for optimizer overrides will allow users to hand-tune the optimizer for queries. -- 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: Modular build, was: VOTE: Approach for sharing code
There are now three cloning proposals for handling shared code: 1) Hand cloning by the developer as is done today. 2) Build-time cloning. 3) Release-time cloning (David's latest proposal). All of these cloning approaches address Dan's problem case: a client and server at diffferent rev levels in the same classpath. It's worth pointing out that none of these proposals addresses the other mixed usage scenario: wiring into the classpath two applications each of which embeds a different version of the server. In that scenario we can still expect Heisenbugs. We've never tested this scenario and so we have no idea what our current exposure is. I agree with Jeremy that this scenario is a systemic defect in Java and that we are not responsible for solving it. The best we can do is point our users at best-of-breed techniques for containing the problem. Here's what I think about the cloning proposals: (1) + Requires no changes. - Brittle, bug-prone. - Can't cut clone bloat by refactoring jar files. (2) + Simple for bug porting. - Can't cut clone bloat by refactoring jar files. - Awkward to code and debug. (3) + Easy to code and debug. + Clone bloat not necessary if client and server at same rev level. - Awkward for bug porting. In and of themselves, none of these approaches presents the naive customer any additional complexity out-of-the-box. Additional complexity would vex the customer if, for option (3) we refactored the jar files to cut clone bloat. I dislike (3) the least. Cheers, -Rick
[jira] Created: (DERBY-581) Modify SQL to skip N rows of the result and return the next M rows
Modify SQL to skip N rows of the result and return the next M rows
--
Key: DERBY-581
URL: http://issues.apache.org/jira/browse/DERBY-581
Project: Derby
Type: New Feature
Components: Unknown
Environment: All
Reporter: Craig Russell
Priority: Minor
I agree that the information should be expressed in SQL so that the query
optimized and execution strategy can know what the user needs in terms of
cardinality.
I'd also like to ask that when we consider extending the SQL in this manner we
consider skipping the first N rows and returning the next M rows.
Craig
On Sep 20, 2005, at 10:19 AM, Suavi Ali Demir wrote:
Another little detail about optimization is that Statement.setMaxRows() kind of
functions on the JDBC side may not be sufficient since it is called after SQL
statement is prepared and returned as an object (after query plan is built).
Therefore, it may be necessary to have language syntax to indicate the
intention to fetch first 1000 rows only, so that when the query is prepared,
this intention can be taken into account.
Regards,
Ali
Mike Matrigali [EMAIL PROTECTED] wrote:
As craig points out it is important in performance testing to say
exactly what you are measuring. In general Derby will try to
stream rows to the user before it has finished looking at all rows.
So often looking at the first row will and stopping will mean that
many rows have not been processed. BUT when an order by is involved
and the query plan either has no appropriate matching index, or decides
to use a different index then all the rows are processed, then they are
sent to the sorter and finally after all rows are processed they are
streamed to the client.
So as you have seen reading the first 1000 rows of a much larger data
set can happen very quickly.
As subsequent mail threads have pointed out, returning the top 1000
sorted rows is an interesting problem which could be costed and executed
differently if that information was pushed into the optimizer and the
sorter (and medium level projects were done in those areas).
On Sep 16, 2005, at 4:42 PM, Scott Ogden wrote:
I have observed some interesting query performance behavior and am
hoping someone here can explain.
In my scenario, it appears that an existing index is not being used for
the 'order by' part of the operation and as a result the perfo rmance of
certain queries is suffering. Can someone explain if this is supposed
to be what is happening and why? Please see below for the specific
queries and their performance characteristics.
Here are the particulars:
-
create table orders(
order_id varchar(50) NOT NULL
CONSTRAINT ORDERS_PK PRIMARY KEY,
amount numeric(31,2),
time date,
inv_num varchar(50),
line_num varchar(50),
phone varchar(50),
prod_num varchar(50));
--Load a large amount of data (720,000 records) into the 'orders' table
--Create an index on the time column as that will be used i n the 'where'
clause.
create index IX_ORDERS_TIME on orders(time);
--When I run a query against this table returning top 1,000 records,
this query returns very quickly, consistently less than .010 seconds.
select * from orders
where time '10/01/2002' and time '11/30/2002'
order by time;
--Now run a similarly query against same table, returning the top
1,000 records.
--The difference is that the results are now sorted by the primary key
('order_id') rather than 'time'.
--This query returns slowly, approximately 15 seconds. Why??
select * from orders
where time '10/01/2002' and time '11/30/2002'
order by order_id;
--Now run a third query against the same 'orders' table, removing the
where clause
--This query returns quickly, around .010 seconds.
select * from orders
order by order_id;
--
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
[Fwd: Re: additional drda datatypes]
This issue is moving forward on a geologic time scale. Far enough forward that I have been asked: who can champion this issue in other (that is, not Sun) companies? Can one of the IBM folks find an IBM champion for this issue? Thanks, -Rick ---BeginMessage--- Rick, Rick the working group for the DRDA standard is only operating in maintenance mode at present and we have no plans to initiate new Open Group development work on it. Therefore, while we appreciate your desire to have support for these new datatypes added to the DRDA standard, the Open Group is not currently resourced to do the necessary specification update work. However, if you can gather support within Sun and maybe other organizations sufficient to generate a draft DRDA Addendum Specification for adding support for these 5 ANSI SQL Datatypes, then we would could submit it through our Open Group approval process to approve it as an extension to the DRDA standard. Regards, Jim Pickel Manager, DB2 Connectivity through DRDA Phone: (408) 463-2332 T/L 543-2332 Internet address: pickel @us.ibm.com Notes address: James Pickel/Santa Teresa/IBM VM address: [EMAIL PROTECTED] Rick Hillegas [EMAIL PROTECTED] Rick Hillegas [EMAIL PROTECTED] 08/15/2005 01:53 PM To [EMAIL PROTECTED] cc Subject additional drda datatypes Hello, The DRDA spec seems to not support a number of ANSI SQL Datatypes, including the following: BOOLEAN NCHAR NCLOB NVARCHAR XML How can we go about adding these datatypes to a future revision of the DRDA spec? Thanks, -Rick ---End Message---
[PATCH] jdk15 canons for 3 tests for 10.0 branch (ref commit # 149488)
Hi, Attached is a patch that adds 3 jdk15 canons to the DerbyNet dir for the 10.0 branch. The change is in essence the same as for commit 149488 to the main branch, but 2of the3 tests are a little different, so a backport will be a little awkward. If someone can add this to the 10.0 branch? Thx, Myrna A java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk15 A java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk15\prepStmt.out A java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk15\callable.out A java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk15\csPrepStmt.out Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk15/prepStmt.out === --- java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk15/prepStmt.out (revision 0) +++ java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk15/prepStmt.out (revision 0) @@ -0,0 +1,65 @@ +prepStmt Test Starts +executeUpdate() without parameters +Update count is: 0 +executeUpdate() with parameters +Update count is: 1 +execute() with parameters, no result set returned +Update count is: 2 +executQuery() without parameters +got row: 99 5 9 +got row: 2 6 10 +got row: 7 5 8 +end of rows +executQuery() with parameters +got row: 99 5 9 +got row: 7 5 8 +end of rows +execute() with parameters with result set returned +got row: 99 5 9 +got row: 7 5 8 +end of rows +test different data types for input parameters of a Prepared Statement +Update count is: 0 +Update count is: 1 +test setObject on different data types for input parameters of a Prepared Statement +Update count is: 1 +test setNull on different data types for input parameters of a Prepared Statement +Update count is: 1 +got row: 1 2 3 4.0 5.0 6.0 77.77 8.100 column9stringcolumn10vcstring column11lvcstring 0123456789abcdef10111213202020 0123456789abcdef10111213 0123456789abcdef10111213 xxFILTERED-TIMESTAMPx-04-12 11:44:30.0 +Timestamp match! +got row: 1 2 3 4.0 5.0 6.0 77.77 8.100 column11string column10vcstring column11lvcstring 0123456789abcdef10111213202020 0123456789abcdef10111213 0123456789abcdef10111213 xxFILTERED-TIMESTAMPx-04-12 11:44:30.0 +Timestamp match! +got row: 0 0 0 0.0 0.0 0.0 null null null null null null null null null null xxFILTERED-TIMESTAMPx +After first Timestamp! +end of rows +SQLState: 07000 message: At least one parameter to the current statement is uninitialized. +SQLState: 07000 message: At least one parameter to the current statement is uninitialized. +insertTab ( bigtab,50) +insertTab ( bigtab,200) +insertTab ( bigtab,300) +insertTab ( bigtab,500) +insertTab ( bigtab,1000) +select * from bigtab +Col # 500 = null Col 1000 = null +Col # 500 = null Col 1000 = null +Col # 500 = null Col 1000 = null +Col # 500 = 500 Col 1000 = null +Col # 500 = 500 Col 1000 = 1000 +Insert wrong column name +insertTab ( bigtab,1001) +SQLState: 42X14 message: 'C1001' is not a column in table or VTI 'CS.BIGTAB'. +Expected Syntax error +insertTab ( bigtab,0) +SQLState: 42X01 message: Syntax error: Encountered EOF at line 1, column 29. +Expected Table does not exist +insertTab ( wrongtab,1000) +SQLState: 42X05 message: Table 'WRONGTAB' does not exist. +Minimum BigDecimal Value: 1E-15 +Prepared Statement String: update Numeric_Tab set NULL_VAL=? +Select NULL_VAL from Numeric_Tab +Returned BigDecimal Value after Updation: 1E-15 +Value returned from ctssql.stmt: 1E-15 +setObject Method sets the designated parameter with the Object +Negative test setString with Invalid Timestamp:20 +SQLState: 22007 message: The syntax of the string representation of a datetime value is incorrect. +prepStmt Test Ends Property changes on: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk15/prepStmt.out ___ Name: svn:eol-style + native Index: java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk15/callable.out === --- java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk15/callable.out (revision 0) +++ java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk15/callable.out (revision 0) @@ -0,0 +1,37 @@ +CallableStatement Test Starts +Sum of 6 and 9 is: 15 +return value: Square of 6 then plus 6 is: 42 +return value is: 55 +return short: 3 +return int: 4 +return long: 5 +return float: 6.0 +return double: 7.0 +return decimal: 88.880 +return date: 2002-05-12 +return time: 10:05:02 +return time stamp: xxFILTERED-TIMESTAMPx +return byte[0]: 1 +return byte[1]: 2 +method 5 return decimal: 33.3330 +method 5 return decimal: -2.9966 +method 5 return decimal: -966.6669 +method 5 return decimal: 0. +method 5 return decimal:
Re: [PATCH] jdk15 canons for 3 tests for 10.0 branch (ref commit # 149488)
On 9/20/05, Myrna van Lunteren [EMAIL PROTECTED] wrote: Attached is a patch that adds 3 jdk15 canons to the DerbyNet dir for the 10.0 branch. Committed revision 290576. andrew
[jira] Updated: (DERBY-566) Doc bug for saving ij output to a file
[ http://issues.apache.org/jira/browse/DERBY-566?page=all ] Andrew McIntyre updated DERBY-566: -- Fix Version: 10.1.1.1 (was: 10.1.2.0) (was: 10.1.1.0) Version: 10.1.1.0 Doc bug for saving ij output to a file -- Key: DERBY-566 URL: http://issues.apache.org/jira/browse/DERBY-566 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0, 10.1.2.0, 10.1.1.1 Tracking issue as discussed in: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL PROTECTED] On the following page: http://db.apache.org/derby/docs/dev/tools/ttoolsij98878.html this is what needs to change on that page: - 2nd bullet on page, 'Redirect standard input to come from a file', the example should be: java -Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver org.apache.derby.tools.ij *myscript.sql* - 5th bullet on page, 'By redirecting to a file', the example should be: java -Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver org.apache.derby.tools.ij *myscript.sql* *myoutput.txt* -- 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-566) Doc bug for saving ij output to a file
[ http://issues.apache.org/jira/browse/DERBY-566?page=all ] Andrew McIntyre updated DERBY-566: -- Fix Version: 10.2.0.0 10.1.2.0 Doc bug for saving ij output to a file -- Key: DERBY-566 URL: http://issues.apache.org/jira/browse/DERBY-566 Project: Derby Type: Bug Components: Documentation Versions: 10.1.1.0 Reporter: Jeff Levitt Priority: Minor Fix For: 10.2.0.0, 10.1.2.0, 10.1.1.1 Tracking issue as discussed in: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL PROTECTED] On the following page: http://db.apache.org/derby/docs/dev/tools/ttoolsij98878.html this is what needs to change on that page: - 2nd bullet on page, 'Redirect standard input to come from a file', the example should be: java -Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver org.apache.derby.tools.ij *myscript.sql* - 5th bullet on page, 'By redirecting to a file', the example should be: java -Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver org.apache.derby.tools.ij *myscript.sql* *myoutput.txt* -- 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-149) Server hang when invalid string is bound to datetime columns.
[
http://issues.apache.org/jira/browse/DERBY-149?page=comments#action_12330055 ]
Kathey Marsden commented on DERBY-149:
--
Looking at this problem, I see that other types of errors, such as insert of a
null value into a not null column seem to work ok. Looking at two types of
errors in the trace, I see the following.
SUCCESSFUL ERROR PROCESSING (invalid insert of null value. handled ok)
[derby]SEND BUFFER: EXCSQLSTT
[derby]SEND BUFFER: SQLDTA
[derby]SEND BUFFER: RDBCMM
[derby]RECEIVE BUFFER: SQLCARD (With error 23502)
[derby]RECEIVE BUFFER: ENDUOWRM
[derby]RECEIVE BUFFER: SQLCARD (null SQLCARD)
PROBLEM ERROR PROCESSING (invalid conversion)
[derby]SEND BUFFER: EXCSQLSTT
[derby]SEND BUFFER: SQLDTA
[derby]SEND BUFFER: RDBCMM
[derby]RECEIVE BUFFER: SQLCARD (Exception 22007)
In the problem case, the server never sends the ENDUOWRM and SQLCARD that it
should. The client blocks waiting for a response to its chained RDBCMM which
the server never sent.
In the server, in parseSQLDTA on exception, we call skipRemainder(false) to
skip the rest of the DSS. The false parameter means it will skip DSS's even if
they have a different correlation id, which means in this case it gets a little
too skippy and skips the RDBCMM Command.
Changing the line to skipRemainder(true) fixes the problem and makes sense to
me because the DRDA manual seems to indicate that you should only get a new
correlation identifier for a new command (page 76).
My specific question (at last) is this:
Are there any situations where we might need to skip a DSS with a different
correlation ID when parsing the parameters in parseSQLDTA?
Server hang when invalid string is bound to datetime columns.
-
Key: DERBY-149
URL: http://issues.apache.org/jira/browse/DERBY-149
Project: Derby
Type: Bug
Components: Network Server
Environment: Derby running with Network Server via JDBC universal driver.
Reporter: A B
Assignee: Kathey Marsden
When running against Derby Network Server with the JCC driver, attempts to
bind an invalid date/time string to a date/time/timestamp parameter lead to a
hang in either the JCC client or in the Network Server (not sure which).
The problem does NOT occur if the same thing is run against a DB2 server,
which suggests the bug is in Network Server, not in the JCC driver. That
said, though, the problem also does NOT happen if one uses an ODBC client to
connect to Network Server, instead of a JDBC client--so perhaps it's a
problem with JCC, after all...hard to say one way or the other...
Here's a simple program to reproduce the problem:
import java.sql.*;
public class go {
public static void main (String[] args) throws Exception {
Class.forName(com.ibm.db2.jcc.DB2Driver);
Connection c = DriverManager.getConnection(
jdbc:derby:net://localhost:1527/ugh;create=true,
bah, humbug);
Statement s = c.createStatement();
try {
s.execute(drop table dt);
} catch (SQLException se) {}
s.execute(create table dt (d date));
PreparedStatement pSt = c.prepareStatement(insert into dt
values (?));
try {
pSt.setString(1, oops); // invalid date value.
pSt.execute();
} catch (SQLException se) {
System.out.println(Got + se.getSQLState() + : +
se.getMessage());
}
}
}
Of course, in order for the program to run, one must start the Network Server
on port 1527 first.
--
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: 10.1.2 Release status page
Andrew McIntyre wrote: Hmm, this would be my fault. The version should have been bumped after each release and I neglected to do that immediately after the last release. Also, I merged the issues with 10.1.1.1 FixIns to 10.1.2.0. While that was a probably a good idea, in order to target more bugs at the 10.1.2.0, it looks like removing the 10.1.1.1 release from JIRA might have been a mistake as well, since we can't mark bugs as fixed in 10.1.1.1. I'll bump the branch to 10.1.1.1, in preparation for posting the snapshot, after which I'll bump it to 10.1.1.2. If we get to 10.1.2.0 without posting another snapshot, we can merge anything with a 10.1.1.2 FixIn to 10.1.2.0. Sound good? What do you mean by merge in this case? I would say that if the version of the 10.1 branch is 10.1.1.1 then a fix should result in the bug being marked as fixed in '10.1.1.1 (unreleased version)'. Ie. correctly represent the version of when the bug was fixed. Once 10.1.2 is released (or maybe a release candidate) then any bugs fixed in 10.1 since the last release could *also* be marked fixed in '10.1.2 (released version)', not replace the fixin of 10.1.1.1. This additional fixin is to link the bugs with the release and helps the release notes generation. Changing history of a bug tracking system is generally a thing to avoid. Dan.
[jira] Updated: (DERBY-562) Derby incorrectly throws Exception when streaming to BLOB field
[ http://issues.apache.org/jira/browse/DERBY-562?page=all ] Sunitha Kambhampati updated DERBY-562: -- Attachment: Derby562.stat.txt Derby incorrectly throws Exception when streaming to BLOB field --- Key: DERBY-562 URL: http://issues.apache.org/jira/browse/DERBY-562 Project: Derby Type: Bug Versions: 10.1.1.0 Reporter: Holger Rehn Attachments: Derby562.diff.txt, Derby562.stat.txt Derby incorrectly throws an Exception when streaming to a BLOB in case the used InputStream actually could provide more data than I want to write to the BLOB field. PreparedStatement statement = connection.prepareStatement( insert into FOO(ID,DATA) values(?, ?) ); statement.setLong( 1, someValue ); statement.setBinaryStream( 2, someInputStream, amountOfData ); // amountOfData amount of data readable from someInputStream statement.executeUpdate(); executeUpdate() throws an SQLException with detail message: Input stream held less data than requested length.: java.io.IOException In my case this was first caused by writing an internal buffer (byte[]) to the data base through a ByteArrayInputStream while not limiting the ByteArrayInputStream to the useful data within the buffer but setting amountOfData to the number of useful bytes. So the 2 problems are: 1. the error text is definitly incorrect since I provide more data than neccessary, not less 2. in my opinion this shouldn't throw an exception at all (I checked against 4 other DBMS, all of them worked as intended) -- 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: Modular build, was: VOTE: Approach for sharing code
David W. Van Couvering wrote: This proposal was based on the assumption that our common code would *never* be exposed to the outside world. I also never claimed that we should apply this solution to third-party components. That's a fish I don't think we need to fry right now. Although I do want to remind us all that, based on Dan's email a while back, the JDK itself encountered the mixed version problem and solved/is solving it through package renaming... http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL PROTECTED] The future plan is to rename the org.apache.** packages to be something like com.sun.org.apache.** to fix this problem. begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
Re: Modular build, was: VOTE: Approach for sharing code
Daniel John Debrunner wrote: Jeremy Boynes wrote: Think of the carnage if it was java_14208_b13.sql_300.Connection It's actually instructive to look how Java solves this: - The interface is kept upwards compatible, by following rules such as only new methods/fields etc. Then to look at how a consumer, Derby, deals with the fact of multiple versions of the interface: - Derby only provides and uses the functionality to match the version of the interface (java.sql.Connection) loaded, determined at runtime. I'd thought this was a workable direction being proposed about six thousand message ago, upwards compatible apis and the ability for a consumer to handle a lower version. Not sure what derailed it. Kathey asked if I would be willing to write something up and I started thinking about it but haven't had the bandwidth to write anything. As a quick braindump: * there are rules that restrict changes to the interface going forward * Sun (et al) stick to those rules even when it is painful * no class/method is removed without being deprecated first * the JVM supports version skew a little by not requiring an implementation to implement all methods in a interface (at runtime) * the interfaces often provide a mechanism to determine what features of an API the implementation implements * frameworks can utilize multiple classloaders to load multiple versions of a class into the VM - tools have developed to simplify this I think we can support a scenario where: * a comsumer expecting version X.Y will work with any implementation X.Y' when Y' = Y * a consumer expecting X.Y will work with X.Y' when Y' Y by version detection and degraded functionality (Y' level). If Y level function is required then it will gracefully die (able to detect rather than AbstractMethodError) * X.Y defines the interface version, i.e. X.Y.Z works with X.Y.Z' for all Z' * X defines the compatibility level i.e. X and X' are not guaranteed to work together (although we will try to ensure they do) Basic rules: * at the Z level, no API change is allowed, just implementation changes * at the Y level, additive API changes are allowed but must be accompanied by support in the versioning mechanism so that they can be detected. Things can be deprecated * at the Z level, incompatible changes are allowed. Items deprecated in version X can be removed in version X+2 (implicitly (X+2).0.0). This all applies to operation in a single classloader. Where multiple classloaders are involved (inside one VM or in multiple VMs) a different set of versioning behaviours applies to the wire protocol. -- Jeremy
Re: Modular build, was: VOTE: Approach for sharing code
Thanks for writing up a proposed solution, I was getting a little tired of putting up targets for others to shoot down. I agree with this wholeheartedly this was what I have wanted to do (although perhaps not as well communicated and there are some details here that are new and which seem really good/interesting). You say Java does this -- is this documented somewhere? I'd love to have that as a reference. First of all, Kathey was concerned we wouldn't be able to follow this kind of discipline. http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL PROTECTED] But I'll also show where I saw this get tripped up: * a consumer expecting X.Y will work with X.Y' when Y' Y by version detection and degraded functionality (Y' level). If Y level function is required then it will gracefully die (able to detect rather than AbstractMethodError) In my original proposal: * compatibility will be strongly encouraged but not guaranteed against previous minor versions (e.g. a 10.2 consumer works with 10.1 common classes, but a 10.3 consumer has a hard dependency on new methods, it can not work with 10.2 common classes). Perhaps I remember incorrectly, but I remember us (or enough of us) generally agreeing that gracefully dying when Y level function was required was not acceptable, as this was a regression of existing behavior. This was the nail in the coffin for my original proposal. http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/db-derby-dev/200509.mbox/[EMAIL PROTECTED] Unless you can address these issues I think we're back at square one... David Further asides below: As a quick braindump: * there are rules that restrict changes to the interface going forward * Sun (et al) stick to those rules even when it is painful * no class/method is removed without being deprecated first * the JVM supports version skew a little by not requiring an implementation to implement all methods in a interface (at runtime) That's nice to know, I didn't know that * the interfaces often provide a mechanism to determine what features of an API the implementation implements * frameworks can utilize multiple classloaders to load multiple versions of a class into the VM - tools have developed to simplify this I don't know much about such frameworks and tools, but I don't think this solves Dan's problem of accidentally loading multiple versions. I think we can support a scenario where: * a comsumer expecting version X.Y will work with any implementation X.Y' when Y' = Y * X.Y defines the interface version, i.e. X.Y.Z works with X.Y.Z' for all Z' * X defines the compatibility level i.e. X and X' are not guaranteed to work together (although we will try to ensure they do) Basic rules: * at the Z level, no API change is allowed, just implementation changes * at the Y level, additive API changes are allowed but must be accompanied by support in the versioning mechanism so that they can be detected. Things can be deprecated * at the Z level, incompatible changes are allowed. Items deprecated in version X can be removed in version X+2 (implicitly (X+2).0.0). This all applies to operation in a single classloader. Where multiple classloaders are involved (inside one VM or in multiple VMs) a different set of versioning behaviours applies to the wire protocol. -- Jeremy begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
