-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate Derby into embedded database support [SPR-5738] #10408
Comments
Oliver Drotbohm commented Added request to get Derby 10.5.1.1 integrated into SpringSource bundle repository. See https://issuetracker.springsource.com/browse/EBR-373 |
Joris Kuipers commented Please substitute all occurrences of hsql with derby (applying proper casing) in the new Derby configurer ;) |
Keith Donald commented Oliver, I committed the initial support. I had to comment out the EmbeddedDatabaeBuilder test case as when the full spring-jdbc test suite ran, the Derby db initialization in the jdbc.config integration test was causing a side-effect. Specifically, it seems even after a shutdown the schema still exists. Can you confirm this? Does this mean we need to add a destroy-script capability so the schema can be dropped? |
Oliver Drotbohm commented Are you sure you had version 10.5.1.1 in the classpath for the tests? The issues you describe pretty much matches the behaviour you face when having an older version of Derby in the classpath. With later versions it does not recognize the "memory" part of the JDBC URL and creates the database in files which in turn does not drop the schema when being shut down. With pure in memory Derby this should work. At least I could run the testcases repeatedly on my machine. |
Keith Donald commented Yes, I'm sure. Here's the exception
Running the test standalone doesn't produce this exception. |
Keith Donald commented Also, a derby.log is created in the root org.springframework.jdbc dir: 2009-05-16 15:46:12.457 GMT: Database Class Loader started - derby.database.classpath='' 2009-05-16 15:46:13.574 GMT: 2009-05-16 15:46:18.413 GMT: Database Class Loader started - derby.database.classpath='' |
Keith Donald commented Just a little more info here: I see the doc page for Derby's embedded DB support talks about a Sample app that does indeed drop the schema before shutting down the database. I'mgetting the feeling we're going to have to do this, otherwise the DB itself is left around in memory even after shutdown. Oliver, can you confirm? |
Joris Kuipers commented Here's a patch that fixes the issue (and also fixes the JavaDoc to refer to Derby). Index: DerbyEmbeddedDatabaseConfigurer.java --- DerbyEmbeddedDatabaseConfigurer.java (revision 1199) +import java.io.File; import javax.sql.DataSource; import org.apache.commons.logging.Log;
}
} } |
Joris Kuipers commented Including patch in comment looked like it might be broken b/o the markup applied: here's the patch as an attachment instead |
Keith Donald commented Patch applied; all tests now pass. Thanks Joris! Do either of you guys know how to prevent Derby from writing derby.log to the root org.springframework.jdbc project directory? |
Joris Kuipers commented This post might be of interest here: |
Joris Kuipers commented That posting offered a solution indeed: here's a small patch against trunk that prevents the log file from being created and written to. I verified that the static method that returns the OutputStream does not have to be public (nor the class itself, as you changed it to a final class with default visibility). |
Björn Michael commented What about a DerbyEmbeddedDatabaseConfigurer that support connection URL without "memory" as subsubprotocol like "jdbc:derby:testDB;create=true". Therefore the database content is still present in filesystem after e.g. tests and can be investigated with other database tools and is quite useful for strange outcomes during development of tests. |
Oliver Drotbohm opened SPR-5738 and commented
Suppiled patch works with version 10.5.1.1 of Apache Derby that introduces real in-memory databases.
Affects: 3.0 M3
Attachments:
The text was updated successfully, but these errors were encountered: