[ https://issues.apache.org/jira/browse/DERBY-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788720#action_12788720
]
Ole Solberg commented on DERBY-4461:
------------------------------------
I see a variant(?) of this in last nights regression tests with ":SQLSTATE: XJ001Java exception:
': java.nio.channels.ClosedByInterruptException'.".
See e.g.
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/testlog/lin/888874-suitesAll_diff.txt
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/testlog/lin/888874-suitesAll_diff.txt
http://dbtg.foundry.sun.com/derby/test/trunk16/jvmAll/testing/testlog/JDK16Jvm1.6Linux-2.6.17-1.2174_FC5_i686-i686/888925-org.apache.derbyTesting.functionTests.suites.All_diff.txt
http://dbtg.foundry.sun.com/derby/test/trunk16/jvmAll/testing/testlog/JDK16Jvm1.6CYGWIN_NT-5.1_i686-unknown/888925-org.apache.derbyTesting.functionTests.suites.All_diff.txt
The signature is
1) testD151(org.apache.derbyTesting.functionTests.tests.store.Derby151Test)java.sql.SQLException:
DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ040, SQLERRMC: Failed to start database 'wombat',
see the next exception for details.::SQLSTATE: XJ001Java exception: ': java.nio.channels.ClosedByInterruptException'.
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:620)
at java.sql.DriverManager.getConnection(DriverManager.java:200)
at org.apache.derbyTesting.junit.DriverManagerConnector.openConnection(DriverManagerConnector.java:76)
at org.apache.derbyTesting.junit.DriverManagerConnector.openConnection(DriverManagerConnector.java:43)
at org.apache.derbyTesting.junit.TestConfiguration.openDefaultConnection(TestConfiguration.java:1350)
at org.apache.derbyTesting.junit.BaseJDBCTestCase.openDefaultConnection(BaseJDBCTestCase.java:421)
at org.apache.derbyTesting.junit.BaseJDBCTestCase.getConnection(BaseJDBCTestCase.java:103)
at org.apache.derbyTesting.junit.BaseJDBCTestCase.createStatement(BaseJDBCTestCase.java:135)
at org.apache.derbyTesting.functionTests.tests.store.Derby151Test.tearDown(Derby151Test.java:101)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE:
XJ040, SQLERRMC: Failed to start database 'wombat', see the next exception for details.::SQLSTATE:
XJ001Java exception: ': java.nio.channels.ClosedByInterruptException'.
at org.apache.derby.client.am.Connection.completeSqlca(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown Source)
at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown Source)
at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
at org.apache.derby.client.net.NetConnection40.<init>(Unknown Source)
at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown Source)
... 43 more
> 'testD151(...Derby151Test)java.sql.SQLException: Failed to start database' (and more
...) on Suse EE S 10 Linux/IBM 1.6.0, Fedora Core 5/Sun 1.6.0-b105, Win XP/Sun 1.6.0_10
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4461
> URL: https://issues.apache.org/jira/browse/DERBY-4461
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.6.0.0
> Environment: OS:
> Microsoft Windows XP Professional - 5.1.2600 Service Pack 3 Build 2600
> CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34 Cygwin
> JVM:
> Sun Microsystems Inc.
> java version "1.6.0_10"
> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
> Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
> OS:
> Fedora Core release 5 (Bordeaux) 32bits
> Linux 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT 2006
> JVM:
> Sun Microsystems Inc.
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build 1.6.0-b105)
> Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
> OS:
> SUSE Linux Enterprise Server 10 (i586) [Version 10 / Patchlevel 2] 32bits
> Linux 2.6.16.60-0.21-bigsmp #1 SMP Tue May 6 12:41:02 UTC 2008 GNU/Linux
> JVM:
> IBM Corporation
> JIT - r9_20090518_2017
> GC - 20090417_AA)
> JCL - 20090529_01
> Reporter: Ole Solberg
> Assignee: Dag H. Wanvik
> Fix For: 10.6.0.0
>
> Attachments: derby-151-test-clear-interrupt.diff
>
>
> On e.g. SunOS 5.11 w/Sun 1.6.0-b105 and SunOS 5.10 w/Sun 1.6.0_15 I don't see the failure.
> See http://dbtg.foundry.sun.com/derby/test/trunk16/jvmAll/testing/Limited/testSummary-886880.html
> Could this be an "too old" os-problem?
> The failure occurs in a new test introduced in DERBY-151 / r886831.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Bryan Pendleton wrote: >> one of the processes publish broken docs. The cron job I have written >> has some simple sanity checks (like verifying that all the expected >> PDFs and *-single.html files are there), but it's far from foolproof. > > Thanks for working on this, Kristian. > > With the recent build problems that we had (DERBY-1194, DERBY-4153, > DERBY-3518), > it seemed, at least in my environment, that the build scripts were > successfully > producing the *-single.html files, but the build still was broken due > to the > invalid tags. > > I tried looking through the DITA-provided build scripts to see if we > could specify something on the <pipeline> task that told it to handle > errors as build-fatal, but didn't immediately find anything. > > So it seems that we may need to post-process the build output ourselves > in order to detect errors such as the ones I introduced in my recent > commits. > > Is it possible for your tool to search the output for the string > > [pipeline] [Error] > > and then treat any occurences of that as a fatal error? Hi Bryan, I have tried to implement what you suggested. It's hard to tell if it is really working yet, because the errors in the build have been corrected. In any case, I instructed ant to write the output to file instead of the console. I then grep for the string indicating an error and fail the build if one or more occurrences are found. You can see the script(s) at work here: http://hudson.zones.apache.org/hudson/view/Derby/job/Derby-docs/28/console Since I instructed ant to log to file instead of stdout, the output isn't included in the Hudson console output anymore. I have however compressed the file and made it available as an artifact. Btw, compressing it reduces the size from a little under 9 MB to around 160 KB :) PS! We could also have requested yet another plugin to be installed as well, but let's see how this works out first. Regards, -- Kristian > > thanks, > > bryan > > >
[ https://issues.apache.org/jira/browse/DERBY-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788632#action_12788632
]
Kristian Waagan commented on DERBY-4468:
----------------------------------------
Rick pointed you to private at db dot apache dot org. Isn't that working, or did you never
see his reply?
The Apache DB PMC (Project Management Committee, http://db.apache.org/whoweare.html ) will
receive mail sent to that address.
> Security weaknesses
> -------------------
>
> Key: DERBY-4468
> URL: https://issues.apache.org/jira/browse/DERBY-4468
> Project: Derby
> Issue Type: Bug
> Environment: All platform.
> Reporter: Marcell Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> There are security weaknesses in Derby password handling. I want to share the details
with Derby developers but I cannot find the suitable confidential forum/mail address for that.
Please give me an email address to send it to the correct mailbox...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Security weaknesses
-------------------
Key: DERBY-4468
URL: https://issues.apache.org/jira/browse/DERBY-4468
Project: Derby
Issue Type: Bug
Environment: All platform.
Reporter: Marcell Major
There are security weaknesses in Derby password handling. I want to share the details with
Derby developers but I cannot find the suitable confidential forum/mail address for that.
Please give me an email address to send it to the correct mailbox...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Issue Subscription
Filter: Derby: JIRA issues with patch available (12 issues)
Subscriber: derby-dev
Key Summary
DERBY-651 Re-enable the storing of java objects in the database
https://issues.apache.org/jira/browse/DERBY-651
DERBY-4405 Transformation to inner join not performed for certain three-way joins
https://issues.apache.org/jira/browse/DERBY-4405
DERBY-2282 Incorrect "transitive closure" logic leads to inconsistent behavior for binary
comparison predicates.
https://issues.apache.org/jira/browse/DERBY-2282
DERBY-4241 Improve transition from read-only to writable Clob representation
https://issues.apache.org/jira/browse/DERBY-4241
DERBY-4455 Prepared statement failure with CLOB: Stream has already been read and end-of-file
reached and cannot be re-used.
https://issues.apache.org/jira/browse/DERBY-4455
DERBY-4357 TableFunctions provide no information to limit underlying query
https://issues.apache.org/jira/browse/DERBY-4357
DERBY-4183 Our regression tests use various jar files for which we don't have build scripts.
https://issues.apache.org/jira/browse/DERBY-4183
DERBY-1191 Some SQLExceptions, for example those generated from BrokeredStatements, do not
print to derby.log even when derby.stream.error.logSeverityLevel=0
https://issues.apache.org/jira/browse/DERBY-1191
DERBY-4272 SQL Authorization Support for dblook
https://issues.apache.org/jira/browse/DERBY-4272
DERBY-873 OSGi bundle activator not JSR169 compliant
https://issues.apache.org/jira/browse/DERBY-873
DERBY-4137 OOM issue using XA with timeouts
https://issues.apache.org/jira/browse/DERBY-4137
DERBY-3788 Provide a zero-admin way of updating the statisitcs of an index
https://issues.apache.org/jira/browse/DERBY-3788
You may edit this subscription at:
https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?subId=10396&filterId=12310751
[ https://issues.apache.org/jira/browse/DERBY-4435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan closed DERBY-4435.
----------------------------------
> Emptying index fails with NPE doing replacement import of empty file
> --------------------------------------------------------------------
>
> Key: DERBY-4435
> URL: https://issues.apache.org/jira/browse/DERBY-4435
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.0.0
> Environment: Doing replacement import resulting in an empty table, where the
table has at least one index.
> Reporter: Kristian Waagan
> Assignee: Mamta A. Satoor
> Fix For: 10.4.2.1, 10.5.3.1, 10.6.0.0
>
> Attachments: Derby4435Repro.java
>
>
> When importing data from an empty file, with the replacement option enabled (non-zero
last argument in the import procedure call), Derby fails with a NullPointerException when
emptying the index(es) .
> Stack trace, insane build:
> java.sql.SQLException: Import error on line 1 of file [snip]: Java exception: ': java.lang.NullPointerException'.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
> ...
> Caused by: java.lang.NullPointerException
> at org.apache.derby.impl.sql.execute.InsertResultSet.emptyIndexes(InsertResultSet.java:2348)
> at org.apache.derby.impl.sql.execute.InsertResultSet.updateAllIndexes(InsertResultSet.java:1820)
> at org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(InsertResultSet.java:1356)
> at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:444)
> at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:436)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:317)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
> ... 44 more
> Stack trace, sane build:
> java.sql.SQLException: The exception 'java.sql.SQLException: An internal error was identified
by RawStore module.' was thrown while evaluating an expression.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
> ...
> Caused by: ERROR 40XT0: An internal error was identified by RawStore module.
> at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:276)
> at org.apache.derby.impl.store.raw.xact.Xact.abort(Xact.java:917)
> at org.apache.derby.impl.store.access.RAMTransaction.abort(RAMTransaction.java:1985)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doRollback(GenericLanguageConnectionContext.java:1496)
> at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.userRollback(GenericLanguageConnectionContext.java:1404)
> at org.apache.derby.impl.jdbc.TransactionResourceImpl.rollback(TransactionResourceImpl.java:244)
> at org.apache.derby.impl.jdbc.EmbedConnection.rollback(EmbedConnection.java:1764)
> ... 40 more
> A quick investigation suggests DERBY-2537 added the code that fails.
> Problem reported by a user on the Derby user list, see http://thread.gmane.org/gmane.comp.apache.db.derby.user/11764
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4400:
-----------------------------------
Issue & fix info: (was: [Patch Available])
Thanks, Dag!
Committed patch 2a to trunk with revision 889126.
> Document the process of producing Maven 2 artifacts for Derby
> -------------------------------------------------------------
>
> Key: DERBY-4400
> URL: https://issues.apache.org/jira/browse/DERBY-4400
> Project: Derby
> Issue Type: Task
> Components: Documentation
> Affects Versions: 10.5.4.0, 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.6.0.0
>
> Attachments: derby-4400-1a-SetDerbyVersion.diff, derby-4400-1b-SetDerbyVersion.diff,
derby-4400-1c-SetDerbyVersion.diff, derby-4400-2a.diff, derby-4400-2a.stat
>
>
> The process of producing Maven 2 artifacts for Derby should be documented.
> Good and clear documentation is important for the following reasons:
> - The process is only carried out each time a Derby release is produced.
> - A part of our users are using Maven in their projects, and they depend on the Maven
2 artifacts to upgrade Derby.
> - It is likely that it isn't the same person carrying out the process from release to
release.
> As a rough starting point, some points to cover:
> - Prerequisites, installation and environment setup.
> - The artifact build process.
> - Testing the artifacts.
> - Deploying the artifacts.
> - Verifying the deployment (with the central repository).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788485#action_12788485
]
Shazin Sadakath commented on DERBY-4467:
----------------------------------------
With current approach arguments and results can be passed in as VARCHAR.
Multiple arguments can be passed as CSV.
EXECUTE_PROCEDURE(<Procedure Name>,<Arguments>);
Or
Can you this as a built in feature and allow to create a Stored Routine like
CREATE PROCEDURE TestProc(ARG1 VARCHAR(10))
PARAMETER STYLE JAVA
SCRIPT 'function procedure(){
---
}'
> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
> Key: DERBY-4467
> URL: https://issues.apache.org/jira/browse/DERBY-4467
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Environment: Windows XP, Java 1.6
> Reporter: Shazin Sadakath
> Priority: Minor
> Attachments: DDL.sql, DerbyStoredRoutine.zip, ScreenShot.JPG
>
>
> I have been working on an idea that lets you create Stored Procedures using languages
other than Java with a perspective of Apache Derby as a Network Server. I tried this by using
Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE
1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement.
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788280#action_12788280
]
Dag H. Wanvik edited comment on DERBY-3650 at 12/9/09 8:13 PM:
---------------------------------------------------------------
Ok, bear with me if I misunderstand issues here, still trying to grok
this, but I'll weigh in just to get some discussion going.
I looked at the clone methods, and it seems to me that originally
there was getClone, and that cloneObject was introduced later to avoid
always materializing large objects into many copies. The naming is not
good, the names imply the same behavior, I think. cloneObject is
shallow in the sense that it does not clone the *value*, nor does it
clone the *stream state*, if any. (Btw, the implementation of
SQLChar#cloneObject could be simplified to look the same as
SQLBinary#cloneObject).
Now, if I understand correctly, the new method, CopyForRead is slightly
*less shallow*, in that you now also copy the stream state.
For non-stream data types, cloneObject defaults to getClone (deep
copy).
I would suggest we change the names here to clarify code and APIs, the
better to reflect the shallowness of the cloning.
cloneDeep (old getClone; clones even *value*, share nothing)
cloneHalfDeep (new CopyForRead, clones even stream state,
but not value, which is still shared)
cloneShallow (old cloneObject, clones just "holder", shares
stream/stream state)
If the code really needs cloneShallow also, after cloneHalfDeep is
added, I don't know, if not, I'd call cloneHalfDeep cloneShallow
instead ;)
Now, for modification, what to use? I guess that depends on what
semantics are desired/at what level in the code you are..? Maybe we
could just do COW semantics? I.e. use cloneHalfDeep until update is
attempted and only then do a full deep clone? (by overloading stream
class perhaps) Then the updating of the deep copy could proceed until
the column is actually updated without affecting the other aliases?
was (Author: dagw):
Ok, bear with me if I misunderstand issues here, still trying to grok
this, but I'll weigh in just to get some discussion going.
I looked at the clone methods, and it seems to me that originally
there was getClone, and that cloneObject was introduced later to avoid
always materializing large objects into many copies. The naming is not
good, the names imply the same behavior, I think. cloneObject is
shallow in the sense that it does not clone the *value*, nor does it
clone the *stream state*, if any. (Btw, the implementation of
SQLChar#cloneObject could be simplified to look the same as
SQLBinary#cloneObject).
Now, if I understand correctly, the new method, CopyForRead is slightly
*less shallow*, in that you now also copy the stream state.
For non-stream data types, cloneObject defaults to getClone (deep
copy).
I would suggest we change the names here to clarify code and APIs, the
better to reflect the shallowness of the cloning.
cloneDeep (old getClone; clones even *value*, share nothing)
cloneHalfDeep (new CopyForRead, clones even stream state,
but not value, which is still shared)
cloneShallow (old cloneObject, clones just "holder", shares
stream/stream state)
If the code really needs cloneShallow also, after cloneHalfDeep is
added, I don't know, if not, I'd call cloneHalfDeep cloneShallow
instead ;)
Now, for modification, what to use? I guess that depends on what
semantics are desired/at what level in the code you are..? If the
change should logically be reflected in other aliases (alias to same
column value), say after an update of a column, I guess we could
invalidate/close existing streams to that value if any exists so as to
avoid inconsistencies? Or maybe we could just do COW semantics?
I.e. use cloneHalfDeep until update is attempted and only then do
a full deep clone? (by overloading stream class perhaps) Then the
updating of the deep copy could proceed until the column is actually
updated without affecting the other aliases?
> internal multiple references from different rows to a single BLOB/CLOB stream leads to
various errors when second reference used.
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3650
> URL: https://issues.apache.org/jira/browse/DERBY-3650
> Project: Derby
> Issue Type: Bug
> Components: Network Client, SQL, Store
> Affects Versions: 10.3.3.0, 10.4.1.3
> Environment: Mac OSX 10.4
> JDK 1.5.0_13
> Hibernate EntityManager 3.2.1
> Reporter: Golgoth 14
> Attachments: cloning-methods.html, derby-3650-preliminary_2_diff.txt, derby-3650-preliminary_diff.txt,
derby-3650_tests_diff.txt, Derby3650EmbeddedRepro.java, Derby3650FullClientRepro.java, Derby3650FullRepro.java,
Derby3650Repro.java, DerbyHibernateTest.zip, testdb.zip, traces_on_FormatIdStream_alloc.txt,
UnionAll.java
>
>
> Derby + Hibernate JPA 3.2.1 problem on entity with Blob/Clob
> Hi,
> I'm using Derby in Client - Server mode with Hibernate JPA EJB 3.0.
> When a query on an entity containing a Clob and some joins on other entites is executed,
an exception with the following message is thrown:
> XJ073: The data in this BLOB or CLOB is no longer available. The BLOB/CLOB's transaction
may be committed, or its connection is closed.
> This problem occurs when the property "hibernate.max_fetch_depth" is greater than 0.
> When hibernate.max_fetch_depth=0, the query works.
> If Derby is configured in embedded mode, the query works independently of the value of
hibernate.max_fetch_depth.
> On the Hibernate's documentation, the advised value of hibernate.max_fetch_depth is 3.
> Could you explain me if I made something wrong ?
> Thank you.
> Stephane
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788280#action_12788280
]
Dag H. Wanvik commented on DERBY-3650:
--------------------------------------
Ok, bear with me if I misunderstand issues here, still trying to grok
this, but I'll weigh in just to get some discussion going.
I looked at the clone methods, and it seems to me that originally
there was getClone, and that cloneObject was introduced later to avoid
always materializing large objects into many copies. The naming is not
good, the names imply the same behavior, I think. cloneObject is
shallow in the sense that it does not clone the *value*, nor does it
clone the *stream state*, if any. (Btw, the implementation of
SQLChar#cloneObject could be simplified to look the same as
SQLBinary#cloneObject).
Now, if I understand correctly, the new method, CopyForRead is slightly
*less shallow*, in that you now also copy the stream state.
For non-stream data types, cloneObject defaults to getClone (deep
copy).
I would suggest we change the names here to clarify code and APIs, the
better to reflect the shallowness of the cloning.
cloneDeep (old getClone; clones even *value*, share nothing)
cloneHalfDeep (new CopyForRead, clones even stream state,
but not value, which is still shared)
cloneShallow (old cloneObject, clones just "holder", shares
stream/stream state)
If the code really needs cloneShallow also, after cloneHalfDeep is
added, I don't know, if not, I'd call cloneHalfDeep cloneShallow
instead ;)
Now, for modification, what to use? I guess that depends on what
semantics are desired/at what level in the code you are..? If the
change should logically be reflected in other aliases (alias to same
column value), say after an update of a column, I guess we could
invalidate/close existing streams to that value if any exists so as to
avoid inconsistencies? Or maybe we could just do COW semantics?
I.e. use cloneHalfDeep until update is attempted and only then do
a full deep clone? (by overloading stream class perhaps) Then the
updating of the deep copy could proceed until the column is actually
updated without affecting the other aliases?
> internal multiple references from different rows to a single BLOB/CLOB stream leads to
various errors when second reference used.
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3650
> URL: https://issues.apache.org/jira/browse/DERBY-3650
> Project: Derby
> Issue Type: Bug
> Components: Network Client, SQL, Store
> Affects Versions: 10.3.3.0, 10.4.1.3
> Environment: Mac OSX 10.4
> JDK 1.5.0_13
> Hibernate EntityManager 3.2.1
> Reporter: Golgoth 14
> Attachments: cloning-methods.html, derby-3650-preliminary_2_diff.txt, derby-3650-preliminary_diff.txt,
derby-3650_tests_diff.txt, Derby3650EmbeddedRepro.java, Derby3650FullClientRepro.java, Derby3650FullRepro.java,
Derby3650Repro.java, DerbyHibernateTest.zip, testdb.zip, traces_on_FormatIdStream_alloc.txt,
UnionAll.java
>
>
> Derby + Hibernate JPA 3.2.1 problem on entity with Blob/Clob
> Hi,
> I'm using Derby in Client - Server mode with Hibernate JPA EJB 3.0.
> When a query on an entity containing a Clob and some joins on other entites is executed,
an exception with the following message is thrown:
> XJ073: The data in this BLOB or CLOB is no longer available. The BLOB/CLOB's transaction
may be committed, or its connection is closed.
> This problem occurs when the property "hibernate.max_fetch_depth" is greater than 0.
> When hibernate.max_fetch_depth=0, the query works.
> If Derby is configured in embedded mode, the query works independently of the value of
hibernate.max_fetch_depth.
> On the Hibernate's documentation, the advised value of hibernate.max_fetch_depth is 3.
> Could you explain me if I made something wrong ?
> Thank you.
> Stephane
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788279#action_12788279
]
Dag H. Wanvik commented on DERBY-3650:
--------------------------------------
Ok, bear with me if I misunderstand issues here, still trying to grok
this, but I'll weigh in just to get some discussion going.
I looked at the clone methods, and it seems to me that originally
there was getClone, and that cloneObject was introduced later to avoid
always materializing large objects into many copies. The naming is not
good, the names imply the same behavior, I think. cloneObject is
shallow in the sense that it does not clone the *value*, nor does it
clone the *stream state*, if any. (Btw, the implementation of
SQLChar#cloneObject could be simplified to look the same as
SQLBinary#cloneObject).
Now, if I understand correctly, the new method, CopyForRead is slightly
*less shallow*, in that you now also copy the stream state.
For non-stream data types, cloneObject defaults to getClone (deep
copy).
I would suggest we change the names here to clarify code and APIs, the
better to reflect the shallowness of the cloning.
cloneDeep (old getClone; clones even *value*, share nothing)
cloneHalfDeep (new CopyForRead, clones even stream state,
but not value, which is still shared)
cloneShallow (old cloneObject, clones just "holder", shares
stream/stream state)
If the code really needs cloneShallow also, after cloneHalfDeep is
added, I don't know, if not, I'd call cloneHalfDeep cloneShallow
instead ;)
Now, for modification, what to use? I guess that depends on what
semantics are desired/at what level in the code you are..? If the
change should logically be reflected in other aliases (alias to same
column value), say after an update of a column, I guess we could
invalidate/close existing streams to that value if any exists so as to
avoid inconsistencies? Or maybe we could just do COW semantics?
I.e. use cloneHalfDeep until update is attempted and only then do
a full deep clone? (by overloading stream class perhaps) Then the
updating of the deep copy could proceed until the column is actually
updated without affecting the other aliases?
Again, sorry if I badly garbled this.. ;)
> internal multiple references from different rows to a single BLOB/CLOB stream leads to
various errors when second reference used.
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3650
> URL: https://issues.apache.org/jira/browse/DERBY-3650
> Project: Derby
> Issue Type: Bug
> Components: Network Client, SQL, Store
> Affects Versions: 10.3.3.0, 10.4.1.3
> Environment: Mac OSX 10.4
> JDK 1.5.0_13
> Hibernate EntityManager 3.2.1
> Reporter: Golgoth 14
> Attachments: cloning-methods.html, derby-3650-preliminary_2_diff.txt, derby-3650-preliminary_diff.txt,
derby-3650_tests_diff.txt, Derby3650EmbeddedRepro.java, Derby3650FullClientRepro.java, Derby3650FullRepro.java,
Derby3650Repro.java, DerbyHibernateTest.zip, testdb.zip, traces_on_FormatIdStream_alloc.txt,
UnionAll.java
>
>
> Derby + Hibernate JPA 3.2.1 problem on entity with Blob/Clob
> Hi,
> I'm using Derby in Client - Server mode with Hibernate JPA EJB 3.0.
> When a query on an entity containing a Clob and some joins on other entites is executed,
an exception with the following message is thrown:
> XJ073: The data in this BLOB or CLOB is no longer available. The BLOB/CLOB's transaction
may be committed, or its connection is closed.
> This problem occurs when the property "hibernate.max_fetch_depth" is greater than 0.
> When hibernate.max_fetch_depth=0, the query works.
> If Derby is configured in embedded mode, the query works independently of the value of
hibernate.max_fetch_depth.
> On the Hibernate's documentation, the advised value of hibernate.max_fetch_depth is 3.
> Could you explain me if I made something wrong ?
> Thank you.
> Stephane
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788233#action_12788233
]
Rick Hillegas commented on DERBY-651:
-------------------------------------
Hi Kathey,
So far the syntax is all a subset of what is defined in the SQL Standard and I don't anticipate
needing any extensions for this first increment.
Thanks,
-Rick
> Re-enable the storing of java objects in the database
> -----------------------------------------------------
>
> Key: DERBY-651
> URL: https://issues.apache.org/jira/browse/DERBY-651
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-651-01-aa-basicCreateDropType.diff, derby-651-02-af-udtColumnsRetvalsParams.diff,
derby-651-03-aa-udttestInstability.diff, derby-651-04-aa-javadoc.diff, derby-651-05-ac-dependencyTable.diff,
UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html
>
>
> Islay Symonette, in an email thread called "Storing Java Objects in a table" on October
26, 2005 requests the ability to store java objects in the database.
> Old releases of Cloudscape allow users to declare a column's type to be a Serializable
class. This feature was removed from Derby because the syntax was non-standard. However, most
of the machinery to support objects serialized to columns is still in Derby and is even used
in system tables. We need to agree on some standard syntax here and re-expose this useful
feature. Some subset of the ANSI adt syntax, cumbersome as it is, would do.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788220#action_12788220
]
Dag H. Wanvik commented on DERBY-4467:
--------------------------------------
Interesting!
Would you handle any args & results via a string (to be parsed using some convention)?
We should also consider the security implication of permanently enabling CREATE_PROCEDURE
and EXECUTE_PROCEDURE; it would allow a client to register and run arbitrary code on the server
modulo any Java security policy in effect on the server.
> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
> Key: DERBY-4467
> URL: https://issues.apache.org/jira/browse/DERBY-4467
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Environment: Windows XP, Java 1.6
> Reporter: Shazin Sadakath
> Priority: Minor
> Attachments: DDL.sql, DerbyStoredRoutine.zip, ScreenShot.JPG
>
>
> I have been working on an idea that lets you create Stored Procedures using languages
other than Java with a perspective of Apache Derby as a Network Server. I tried this by using
Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE
1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement.
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788217#action_12788217
]
Kathey Marsden commented on DERBY-651:
--------------------------------------
Hi Rick,
Thank you for tackling this feature. I am sure it will be most useful for users. I have not
been following your progress closely, but was wondering if you could confirm that all functionality
being added is part of the SQL Standard or do you plan some Derby specific syntax?
Thanks
Kathey
> Re-enable the storing of java objects in the database
> -----------------------------------------------------
>
> Key: DERBY-651
> URL: https://issues.apache.org/jira/browse/DERBY-651
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-651-01-aa-basicCreateDropType.diff, derby-651-02-af-udtColumnsRetvalsParams.diff,
derby-651-03-aa-udttestInstability.diff, derby-651-04-aa-javadoc.diff, derby-651-05-ac-dependencyTable.diff,
UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html
>
>
> Islay Symonette, in an email thread called "Storing Java Objects in a table" on October
26, 2005 requests the ability to store java objects in the database.
> Old releases of Cloudscape allow users to declare a column's type to be a Serializable
class. This feature was removed from Derby because the syntax was non-standard. However, most
of the machinery to support objects serialized to columns is still in Derby and is even used
in system tables. We need to agree on some standard syntax here and re-expose this useful
feature. Some subset of the ANSI adt syntax, cumbersome as it is, would do.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788210#action_12788210
]
Dag H. Wanvik commented on DERBY-4400:
--------------------------------------
Read through changes; look good to me (although I didn't test deployment -;). +1
> Document the process of producing Maven 2 artifacts for Derby
> -------------------------------------------------------------
>
> Key: DERBY-4400
> URL: https://issues.apache.org/jira/browse/DERBY-4400
> Project: Derby
> Issue Type: Task
> Components: Documentation
> Affects Versions: 10.5.4.0, 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.6.0.0
>
> Attachments: derby-4400-1a-SetDerbyVersion.diff, derby-4400-1b-SetDerbyVersion.diff,
derby-4400-1c-SetDerbyVersion.diff, derby-4400-2a.diff, derby-4400-2a.stat
>
>
> The process of producing Maven 2 artifacts for Derby should be documented.
> Good and clear documentation is important for the following reasons:
> - The process is only carried out each time a Derby release is produced.
> - A part of our users are using Maven in their projects, and they depend on the Maven
2 artifacts to upgrade Derby.
> - It is likely that it isn't the same person carrying out the process from release to
release.
> As a rough starting point, some points to cover:
> - Prerequisites, installation and environment setup.
> - The artifact build process.
> - Testing the artifacts.
> - Deploying the artifacts.
> - Verifying the deployment (with the central repository).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik resolved DERBY-4463.
----------------------------------
Resolution: Fixed
Fix Version/s: 10.6.0.0
Issue & fix info: [High Value Fix] (was: [Patch Available, High Value Fix])
> JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
> --------------------------------------------------------------------------------------------
>
> Key: DERBY-4463
> URL: https://issues.apache.org/jira/browse/DERBY-4463
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.6.0.0
> Environment: failed on windows with ibm15 and ibm16 jvms
> Reporter: Mike Matrigali
> Assignee: Dag H. Wanvik
> Fix For: 10.6.0.0
>
> Attachments: derby-4463.diff
>
>
> 7) JMXTest:clientjava.lang.InterruptedException:
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:137)
> at org.apache.derbyTesting.junit.NetworkServerTestSetup.tearDown(NetworkServerTestSetup.java:392)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> Started failing with build 887040. Here are links for the errors the first time it was
encountered:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887040-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887040-suites.All_diff.txt
> And it still occurred in the next main build:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887483-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887483-suites.All_diff.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788175#action_12788175
]
Dag H. Wanvik commented on DERBY-4463:
--------------------------------------
Committed the patch as svn 888881; hope this fixes the issue for the IBM VMs, although I
haven't been able to run those tests. Let me know if there is still an issue.
> JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
> --------------------------------------------------------------------------------------------
>
> Key: DERBY-4463
> URL: https://issues.apache.org/jira/browse/DERBY-4463
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.6.0.0
> Environment: failed on windows with ibm15 and ibm16 jvms
> Reporter: Mike Matrigali
> Assignee: Dag H. Wanvik
> Fix For: 10.6.0.0
>
> Attachments: derby-4463.diff
>
>
> 7) JMXTest:clientjava.lang.InterruptedException:
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:137)
> at org.apache.derbyTesting.junit.NetworkServerTestSetup.tearDown(NetworkServerTestSetup.java:392)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> Started failing with build 887040. Here are links for the errors the first time it was
encountered:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887040-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887040-suites.All_diff.txt
> And it still occurred in the next main build:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887483-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887483-suites.All_diff.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Auto-generated mail]
*Daily* 888485/2009-12-08 18:02:11 MET
Failed Tests OK Skip Duration Suite
-------------------------------------------------------
*Jvm: 1.6*
lin
0 11769 11769 0 1071.95% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 57.34% derbyall
0 2 2 0 599.75% compatibility
0 2 2 0 .% demoSuite
sles
0 11769 11769 0 680.96% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 49.53% derbyall
0 2 2 0 194.23% compatibility
0 2 2 0 .% demoSuite
sol
0 11769 11769 0 821.19% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 44.05% derbyall
0 2 2 0 316.96% compatibility
0 2 2 0 .% demoSuite
solN+1
0 11769 11769 0 141.60% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 67.10% derbyall
0 2 2 0 306.32% compatibility
0 2 2 0 .% demoSuite
sparc
0 11769 11769 0 530.39% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 47.60% derbyall
0 2 2 0 276.11% compatibility
0 2 2 0 .% demoSuite
vista
0 11763 11763 0 130.46% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 58.94% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
vista-64
0 11763 11763 0 188.48% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 57.27% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
w2003
0 11763 11763 0 231.37% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 70.28% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-888485.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/888485_bySig.html
*Jvm: 1.5*
lin
0 222 222 0 53.22% derbyall
F:0,E:1 9979 9978 0 1730.79% suitesAll
sles
1 222 221 0 48.23% derbyall
0 9979 9979 0 1109.09% suitesAll
sol
0 222 222 0 46.25% derbyall
0 9979 9979 0 1524.29% suitesAll
solN+1
0 222 222 0 60.80% derbyall
0 9979 9979 0 1423.29% suitesAll
sparc
0 222 222 0 47.94% derbyall
0 9979 9979 0 1226.75% suitesAll
vista
0 222 222 0 44.86% derbyall
0 9973 9973 0 906.03% suitesAll
vista-64
0 222 222 0 57.98% derbyall
0 9973 9973 0 214.10% suitesAll
w2003
0 222 222 0 54.93% derbyall
0 9973 9973 0 571.30% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-888485.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/FailReports/888485_bySig.html
*Jvm: 1.4*
lin
0 219 219 2 53.34% derbyall
0 9826 9826 0 1568.36% suitesAll
sles
0 219 219 2 43.52% derbyall
0 9826 9826 0 929.04% suitesAll
sol
0 219 219 2 43.27% derbyall
0 9826 9826 0 1235.75% suitesAll
solN+1
0 219 219 2 59.35% derbyall
0 9826 9826 0 1323.76% suitesAll
sparc
0 219 219 2 47.30% derbyall
0 9826 9826 0 1230.29% suitesAll
vista
0 219 219 2 44.60% derbyall
F:41,E:8 9820 9771 0 904.89% suitesAll
vista-64
0 219 219 2 56.99% derbyall
0 9820 9820 0 216.24% suitesAll
w2003
0 219 219 2 56.84% derbyall
0 9826 9826 0 570.69% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-888485.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/FailReports/888485_bySig.html
.......................................................
*Jvm: 1.7*
lin
0 11769 11769 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
0 2 2 0 .% compatibility
0 2 2 0 .% demoSuite
sol
0 11769 11769 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
0 2 2 0 .% compatibility
0 2 2 0 .% demoSuite
vista-64
0 11763 11763 0 .% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 221 221 0 .% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-888485.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/888485_bySig.html
*Jvm: phoneME*
ubuntu
0 4461 4461 0 .% suitesAll
Details in http://dbtg.foundry.sun.com/derby/test/Daily/javaME/testing/Limited/testSummary-888485.html
Attempted failure analysis in
http://dbtg.foundry.sun.com/derby/test/Daily/javaME/FailReports/888485_bySig.html
-------------------------------------------------------
Changes in http://dbtg.foundry.sun.com/derby/test/Daily/UpdateInfo/888485.txt
( All results in http://dbtg.foundry.sun.com/derby/test/ )
[ https://issues.apache.org/jira/browse/DERBY-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788104#action_12788104
]
Rick Hillegas commented on DERBY-651:
-------------------------------------
Committed derby-651-05-ac-dependencyTable.diff at subversion revision 888811.
> Re-enable the storing of java objects in the database
> -----------------------------------------------------
>
> Key: DERBY-651
> URL: https://issues.apache.org/jira/browse/DERBY-651
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-651-01-aa-basicCreateDropType.diff, derby-651-02-af-udtColumnsRetvalsParams.diff,
derby-651-03-aa-udttestInstability.diff, derby-651-04-aa-javadoc.diff, derby-651-05-ac-dependencyTable.diff,
UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html, UserDefinedTypes.html
>
>
> Islay Symonette, in an email thread called "Storing Java Objects in a table" on October
26, 2005 requests the ability to store java objects in the database.
> Old releases of Cloudscape allow users to declare a column's type to be a Serializable
class. This feature was removed from Derby because the syntax was non-standard. However, most
of the machinery to support objects serialized to columns is still in Derby and is even used
in system tables. We need to agree on some standard syntax here and re-expose this useful
feature. Some subset of the ANSI adt syntax, cumbersome as it is, would do.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4400:
-----------------------------------
Issue & fix info: [Patch Available]
> Document the process of producing Maven 2 artifacts for Derby
> -------------------------------------------------------------
>
> Key: DERBY-4400
> URL: https://issues.apache.org/jira/browse/DERBY-4400
> Project: Derby
> Issue Type: Task
> Components: Documentation
> Affects Versions: 10.5.4.0, 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.6.0.0
>
> Attachments: derby-4400-1a-SetDerbyVersion.diff, derby-4400-1b-SetDerbyVersion.diff,
derby-4400-1c-SetDerbyVersion.diff, derby-4400-2a.diff, derby-4400-2a.stat
>
>
> The process of producing Maven 2 artifacts for Derby should be documented.
> Good and clear documentation is important for the following reasons:
> - The process is only carried out each time a Derby release is produced.
> - A part of our users are using Maven in their projects, and they depend on the Maven
2 artifacts to upgrade Derby.
> - It is likely that it isn't the same person carrying out the process from release to
release.
> As a rough starting point, some points to cover:
> - Prerequisites, installation and environment setup.
> - The artifact build process.
> - Testing the artifacts.
> - Deploying the artifacts.
> - Verifying the deployment (with the central repository).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4400:
-----------------------------------
Attachment: derby-4400-2a.stat
derby-4400-2a.diff
Attaching a follow-on patch 2a:
- deletes settings.xml, since most of the settings in there didn't take effect
- changes the deploy protocol from scp to scpexe, which makes Maven use external commands
to deploy (i.e. ssh and scp)
- additions and changes to the README
Following the latest instructions in README, I'm able to deploy the artifacts using Maven.
Please do not try to deploy :) The next release manager will get the please of verifying the
instructions.
I'd like someone to sanity check the changes made to the README before I commit.
Patch ready for review.
> Document the process of producing Maven 2 artifacts for Derby
> -------------------------------------------------------------
>
> Key: DERBY-4400
> URL: https://issues.apache.org/jira/browse/DERBY-4400
> Project: Derby
> Issue Type: Task
> Components: Documentation
> Affects Versions: 10.5.4.0, 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.6.0.0
>
> Attachments: derby-4400-1a-SetDerbyVersion.diff, derby-4400-1b-SetDerbyVersion.diff,
derby-4400-1c-SetDerbyVersion.diff, derby-4400-2a.diff, derby-4400-2a.stat
>
>
> The process of producing Maven 2 artifacts for Derby should be documented.
> Good and clear documentation is important for the following reasons:
> - The process is only carried out each time a Derby release is produced.
> - A part of our users are using Maven in their projects, and they depend on the Maven
2 artifacts to upgrade Derby.
> - It is likely that it isn't the same person carrying out the process from release to
release.
> As a rough starting point, some points to cover:
> - Prerequisites, installation and environment setup.
> - The artifact build process.
> - Testing the artifacts.
> - Deploying the artifacts.
> - Verifying the deployment (with the central repository).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4466:
--------------------------------------
Component/s: Web Site
> Download page does not have link to KEYS file
> ---------------------------------------------
>
> Key: DERBY-4466
> URL: https://issues.apache.org/jira/browse/DERBY-4466
> Project: Derby
> Issue Type: Bug
> Components: Web Site
> Environment: http://db.apache.org/derby/releases/release-10.5.3.0.cgi
> Reporter: Sebb
> Priority: Critical
>
> The download page http://db.apache.org/derby/releases/release-10.5.3.0.cgi is missing
the section "Verifying releases".
> Also, the KEYS file should be linked from http://www.apache.org/dist/db/derby/KEYS ,
not http://svn.apache.org/repos/asf/db/derby/code/trunk/KEYS
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen closed DERBY-4465.
-------------------------------------
Resolution: Fixed
Fix Version/s: 10.6.0.0
Issue & fix info: (was: [Patch Available])
Thanks, Kristian. Committed revision 888754.
> Typo in error message from SQLChar
> ----------------------------------
>
> Key: DERBY-4465
> URL: https://issues.apache.org/jira/browse/DERBY-4465
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Trivial
> Fix For: 10.6.0.0
>
> Attachments: typo.diff
>
>
> An error message raised by SQLChar says java.sql.String instead of java.lang.String.
See for instance the message text for one of the nested exceptions in DERBY-4455:
> java.sql.SQLException: An IOException was thrown when reading a 'java.sql.String' from
an InputStream.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787996#action_12787996
]
Kristian Waagan commented on DERBY-4465:
----------------------------------------
+1 to commit.
> Typo in error message from SQLChar
> ----------------------------------
>
> Key: DERBY-4465
> URL: https://issues.apache.org/jira/browse/DERBY-4465
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Trivial
> Attachments: typo.diff
>
>
> An error message raised by SQLChar says java.sql.String instead of java.lang.String.
See for instance the message text for one of the nested exceptions in DERBY-4455:
> java.sql.SQLException: An IOException was thrown when reading a 'java.sql.String' from
an InputStream.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazin Sadakath updated DERBY-4467:
-----------------------------------
Comment: was deleted
(was: Screen Shot of the Demonstration)
> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
> Key: DERBY-4467
> URL: https://issues.apache.org/jira/browse/DERBY-4467
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Environment: Windows XP, Java 1.6
> Reporter: Shazin Sadakath
> Priority: Minor
> Attachments: DDL.sql, DerbyStoredRoutine.zip, ScreenShot.JPG
>
>
> I have been working on an idea that lets you create Stored Procedures using languages
other than Java with a perspective of Apache Derby as a Network Server. I tried this by using
Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE
1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement.
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazin Sadakath updated DERBY-4467:
-----------------------------------
Attachment: DerbyStoredRoutine.zip
Sources
> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
> Key: DERBY-4467
> URL: https://issues.apache.org/jira/browse/DERBY-4467
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Environment: Windows XP, Java 1.6
> Reporter: Shazin Sadakath
> Priority: Minor
> Attachments: DDL.sql, DerbyStoredRoutine.zip, ScreenShot.JPG
>
>
> I have been working on an idea that lets you create Stored Procedures using languages
other than Java with a perspective of Apache Derby as a Network Server. I tried this by using
Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE
1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement.
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazin Sadakath updated DERBY-4467:
-----------------------------------
Attachment: DDL.sql
ScreenShot.JPG
Screen Shot of the Demonstration
> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
> Key: DERBY-4467
> URL: https://issues.apache.org/jira/browse/DERBY-4467
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Environment: Windows XP, Java 1.6
> Reporter: Shazin Sadakath
> Priority: Minor
> Attachments: DDL.sql, ScreenShot.JPG
>
>
> I have been working on an idea that lets you create Stored Procedures using languages
other than Java with a perspective of Apache Derby as a Network Server. I tried this by using
Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE
1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement.
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazin Sadakath updated DERBY-4467:
-----------------------------------
Attachment: ScreenShot.JPG
Screen Shot of the Prototype with JavaScript Stored Routine
> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
> Key: DERBY-4467
> URL: https://issues.apache.org/jira/browse/DERBY-4467
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Environment: Windows XP, Java 1.6
> Reporter: Shazin Sadakath
> Priority: Minor
>
> I have been working on an idea that lets you create Stored Procedures using languages
other than Java with a perspective of Apache Derby as a Network Server. I tried this by using
Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE
1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement.
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazin Sadakath updated DERBY-4467:
-----------------------------------
Attachment: (was: ScreenShot.JPG)
> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
> Key: DERBY-4467
> URL: https://issues.apache.org/jira/browse/DERBY-4467
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Environment: Windows XP, Java 1.6
> Reporter: Shazin Sadakath
> Priority: Minor
>
> I have been working on an idea that lets you create Stored Procedures using languages
other than Java with a perspective of Apache Derby as a Network Server. I tried this by using
Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE
1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement.
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Issue Subscription
Filter: Derby: JIRA issues with patch available (14 issues)
Subscriber: derby-dev
Key Summary
DERBY-4463 JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
https://issues.apache.org/jira/browse/DERBY-4463
DERBY-4465 Typo in error message from SQLChar
https://issues.apache.org/jira/browse/DERBY-4465
DERBY-651 Re-enable the storing of java objects in the database
https://issues.apache.org/jira/browse/DERBY-651
DERBY-4405 Transformation to inner join not performed for certain three-way joins
https://issues.apache.org/jira/browse/DERBY-4405
DERBY-2282 Incorrect "transitive closure" logic leads to inconsistent behavior for binary
comparison predicates.
https://issues.apache.org/jira/browse/DERBY-2282
DERBY-4241 Improve transition from read-only to writable Clob representation
https://issues.apache.org/jira/browse/DERBY-4241
DERBY-4455 Prepared statement failure with CLOB: Stream has already been read and end-of-file
reached and cannot be re-used.
https://issues.apache.org/jira/browse/DERBY-4455
DERBY-4357 TableFunctions provide no information to limit underlying query
https://issues.apache.org/jira/browse/DERBY-4357
DERBY-4183 Our regression tests use various jar files for which we don't have build scripts.
https://issues.apache.org/jira/browse/DERBY-4183
DERBY-1191 Some SQLExceptions, for example those generated from BrokeredStatements, do not
print to derby.log even when derby.stream.error.logSeverityLevel=0
https://issues.apache.org/jira/browse/DERBY-1191
DERBY-4272 SQL Authorization Support for dblook
https://issues.apache.org/jira/browse/DERBY-4272
DERBY-873 OSGi bundle activator not JSR169 compliant
https://issues.apache.org/jira/browse/DERBY-873
DERBY-4137 OOM issue using XA with timeouts
https://issues.apache.org/jira/browse/DERBY-4137
DERBY-3788 Provide a zero-admin way of updating the statisitcs of an index
https://issues.apache.org/jira/browse/DERBY-3788
You may edit this subscription at:
https://issues.apache.org/jira/secure/FilterSubscription!default.jspa?subId=10396&filterId=12310751
[ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shazin Sadakath updated DERBY-4467:
-----------------------------------
Description:
I have been working on an idea that lets you create Stored Procedures using languages other
than Java with a perspective of Apache Derby as a Network Server. I tried this by using Sun
Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE 1.4+.
This has certain advantages when it comes to compiled java stored routines.
1. It is dynamic.
2. Requires no configuration of classpath.
3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
4. Very easy to maintain
5. Allows the use of Sun Java Runtime Library via Object Binding.
6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
There are two approaches for this enhancement.
1. Having this as an external utility component such as ij, dblooks
2. Having this as a built in feature.
I have done this in the former method for demonstration purpose.
was:
I have been working on an idea that lets you create Stored Procedures using languages other
than Java with a perspective of Apache Derby as a Network Server. I tried this by using Sun
Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE 1.4+.
This has certain advantages when it comes to compiled java stored routines.
1. It is dynamic.
2. Requires no configuration of classpath.
3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
4. Very easy to maintain
5. Allows the use of Sun Java Runtime Library via Object Binding.
6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
Just an idea in its very early stage. Would like to hear your responses.
> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
> Key: DERBY-4467
> URL: https://issues.apache.org/jira/browse/DERBY-4467
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Environment: Windows XP, Java 1.6
> Reporter: Shazin Sadakath
> Priority: Minor
>
> I have been working on an idea that lets you create Stored Procedures using languages
other than Java with a perspective of Apache Derby as a Network Server. I tried this by using
Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE
1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement.
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Non Java Stored Routines Using Java Scripting API
-------------------------------------------------
Key: DERBY-4467
URL: https://issues.apache.org/jira/browse/DERBY-4467
Project: Derby
Issue Type: Improvement
Components: Network Server
Environment: Windows XP, Java 1.6
Reporter: Shazin Sadakath
Priority: Minor
I have been working on an idea that lets you create Stored Procedures using languages other
than Java with a perspective of Apache Derby as a Network Server. I tried this by using Sun
Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE 1.4+.
This has certain advantages when it comes to compiled java stored routines.
1. It is dynamic.
2. Requires no configuration of classpath.
3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
4. Very easy to maintain
5. Allows the use of Sun Java Runtime Library via Object Binding.
6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
Just an idea in its very early stage. Would like to hear your responses.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Download page does not have link to KEYS file
---------------------------------------------
Key: DERBY-4466
URL: https://issues.apache.org/jira/browse/DERBY-4466
Project: Derby
Issue Type: Bug
Environment: http://db.apache.org/derby/releases/release-10.5.3.0.cgi
Reporter: Sebb
Priority: Critical
The download page http://db.apache.org/derby/releases/release-10.5.3.0.cgi is missing the
section "Verifying releases".
Also, the KEYS file should be linked from http://www.apache.org/dist/db/derby/KEYS , not http://svn.apache.org/repos/asf/db/derby/code/trunk/KEYS
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787623#action_12787623
]
Øyvind Harboe edited comment on DERBY-4210 at 12/8/09 6:24 PM:
---------------------------------------------------------------
We switched to Derby 10.5 from 10.1(?) and we're now seing memory consumption going through
the roof. Memory problems with Java are not easy to diagnose correctly, that in mind, here
is some information:
- We have ~100 embedded databases in a single java process. 1 database per customer. We would
have liked to use a single database for a customers, but at that point we would probably be
looking at PostgreSQL I think.
- There are lots of said threads in our system(one per database?).
- From Eclipse heap analysis some fingerpointing is done to derby:
142 instances of "org.apache.derby.impl.services.cache.ConcurrentCache", loaded by "sun.misc.Launcher$AppClassLoader
@ 0x736e14d8" occupy 86,289,208 (53.63%) bytes.
Keywords
sun.misc.Launcher$AppClassLoader @ 0x736e14d8
org.apache.derby.impl.services.cache.ConcurrentCache
(I'm learning about these profiling tools. If I figure out more I'll update this bug report.)
was (Author: oharboe):
We switched to Derby 10.5 from 10.1(?) and we're now seing memory consumption going through
the roof. Memory problems with Java are not easy to diagnose correctly, that in mind, here
is some information:
- We have ~100 embedded databases in a single java process. 1 database per client. We would
have liked to use a single database for a single client, but at that point we would probably
be looking at PostgreSQL I think.
- There are lots of said
- From Eclipse heap analysis some fingerpointing is done to derby:
142 instances of "org.apache.derby.impl.services.cache.ConcurrentCache", loaded by "sun.misc.Launcher$AppClassLoader
@ 0x736e14d8" occupy 86,289,208 (53.63%) bytes.
Keywords
sun.misc.Launcher$AppClassLoader @ 0x736e14d8
org.apache.derby.impl.services.cache.ConcurrentCache
(I'm learning about these profiling tools. If I figure out more I'll update this bug report.)
> Use a shared pool for background threads (rawStoreDaemon)
> ---------------------------------------------------------
>
> Key: DERBY-4210
> URL: https://issues.apache.org/jira/browse/DERBY-4210
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.5.1.1
> Reporter: Arnaud Masson
>
> Use a shared pool for background threads (rawStoreDaemon).
> May it could be a configuration option (pooling or not, max pool size, core pool size,
...).
> I have an application that opens several small derby databases (using EmbeddedDriver).
> Most of these instances don't handle many requests, but each instance maintains its own
thread "derby.rawStoreDaemon".
> It would more efficient to use a thread pool shared by all the instances.
> See http://osdir.com/ml/apache.db.derby.devel/2005-04/msg00093.html
> See also DERBY-206 and DERBY-696 about threading in Derby.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787623#action_12787623
]
Øyvind Harboe commented on DERBY-4210:
--------------------------------------
We switched to Derby 10.5 from 10.1(?) and we're now seing memory consumption going through
the roof. Memory problems with Java are not easy to diagnose correctly, that in mind, here
is some information:
- We have ~100 embedded databases in a single java process. 1 database per client. We would
have liked to use a single database for a single client, but at that point we would probably
be looking at PostgreSQL I think.
- There are lots of said
- From Eclipse heap analysis some fingerpointing is done to derby:
142 instances of "org.apache.derby.impl.services.cache.ConcurrentCache", loaded by "sun.misc.Launcher$AppClassLoader
@ 0x736e14d8" occupy 86,289,208 (53.63%) bytes.
Keywords
sun.misc.Launcher$AppClassLoader @ 0x736e14d8
org.apache.derby.impl.services.cache.ConcurrentCache
(I'm learning about these profiling tools. If I figure out more I'll update this bug report.)
> Use a shared pool for background threads (rawStoreDaemon)
> ---------------------------------------------------------
>
> Key: DERBY-4210
> URL: https://issues.apache.org/jira/browse/DERBY-4210
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.5.1.1
> Reporter: Arnaud Masson
>
> Use a shared pool for background threads (rawStoreDaemon).
> May it could be a configuration option (pooling or not, max pool size, core pool size,
...).
> I have an application that opens several small derby databases (using EmbeddedDriver).
> Most of these instances don't handle many requests, but each instance maintains its own
thread "derby.rawStoreDaemon".
> It would more efficient to use a thread pool shared by all the instances.
> See http://osdir.com/ml/apache.db.derby.devel/2005-04/msg00093.html
> See also DERBY-206 and DERBY-696 about threading in Derby.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-4463:
---------------------------------
Attachment: derby-4463.diff
> JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4463
> URL: https://issues.apache.org/jira/browse/DERBY-4463
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.6.0.0
> Environment: failed on windows with ibm15 and ibm16 jvms
> Reporter: Mike Matrigali
> Attachments: derby-4463.diff
>
>
> 7) JMXTest:clientjava.lang.InterruptedException:
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:137)
> at org.apache.derbyTesting.junit.NetworkServerTestSetup.tearDown(NetworkServerTestSetup.java:392)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> Started failing with build 887040. Here are links for the errors the first time it was
encountered:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887040-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887040-suites.All_diff.txt
> And it still occurred in the next main build:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887483-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887483-suites.All_diff.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-4463:
---------------------------------
Issue & fix info: [High Value Fix, Patch Available] (was: [High Value Fix])
Summary: JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
(was: JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
)
> JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
> --------------------------------------------------------------------------------------------
>
> Key: DERBY-4463
> URL: https://issues.apache.org/jira/browse/DERBY-4463
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.6.0.0
> Environment: failed on windows with ibm15 and ibm16 jvms
> Reporter: Mike Matrigali
> Assignee: Dag H. Wanvik
> Attachments: derby-4463.diff
>
>
> 7) JMXTest:clientjava.lang.InterruptedException:
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:137)
> at org.apache.derbyTesting.junit.NetworkServerTestSetup.tearDown(NetworkServerTestSetup.java:392)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> Started failing with build 887040. Here are links for the errors the first time it was
encountered:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887040-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887040-suites.All_diff.txt
> And it still occurred in the next main build:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887483-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887483-suites.All_diff.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik reassigned DERBY-4463:
------------------------------------
Assignee: Dag H. Wanvik
> JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4463
> URL: https://issues.apache.org/jira/browse/DERBY-4463
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.6.0.0
> Environment: failed on windows with ibm15 and ibm16 jvms
> Reporter: Mike Matrigali
> Assignee: Dag H. Wanvik
> Attachments: derby-4463.diff
>
>
> 7) JMXTest:clientjava.lang.InterruptedException:
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:137)
> at org.apache.derbyTesting.junit.NetworkServerTestSetup.tearDown(NetworkServerTestSetup.java:392)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> Started failing with build 887040. Here are links for the errors the first time it was
encountered:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887040-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887040-suites.All_diff.txt
> And it still occurred in the next main build:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887483-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887483-suites.All_diff.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/DERBY-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787579#action_12787579
]
Dag H. Wanvik commented on DERBY-4463:
--------------------------------------
Yes, the flag is not cleared if the the exception is not raised, I see. I guess this is the
likely cause here.
Uploading a new patch which always clears the flag on teardown,
I'll commit it as soon as my regressions pass.
> JMX test in nightly test suite failed with: JMXTest:clientjava.lang.InterruptedException:
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4463
> URL: https://issues.apache.org/jira/browse/DERBY-4463
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.6.0.0
> Environment: failed on windows with ibm15 and ibm16 jvms
> Reporter: Mike Matrigali
>
> 7) JMXTest:clientjava.lang.InterruptedException:
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:137)
> at org.apache.derbyTesting.junit.NetworkServerTestSetup.tearDown(NetworkServerTestSetup.java:392)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:23)
> Started failing with build 887040. Here are links for the errors the first time it was
encountered:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887040-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887040-suites.All_diff.txt
> And it still occurred in the next main build:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/887483-suites.All_diff.txt
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm16/887483-suites.All_diff.txt
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
> one of the processes publish broken docs. The cron job I have written
> has some simple sanity checks (like verifying that all the expected PDFs
> and *-single.html files are there), but it's far from foolproof.
Thanks for working on this, Kristian.
With the recent build problems that we had (DERBY-1194, DERBY-4153, DERBY-3518),
it seemed, at least in my environment, that the build scripts were successfully
producing the *-single.html files, but the build still was broken due to the
invalid tags.
I tried looking through the DITA-provided build scripts to see if we
could specify something on the <pipeline> task that told it to handle
errors as build-fatal, but didn't immediately find anything.
So it seems that we may need to post-process the build output ourselves
in order to detect errors such as the ones I introduced in my recent commits.
Is it possible for your tool to search the output for the string
[pipeline] [Error]
and then treat any occurences of that as a fatal error?
thanks,
bryan