Database development with Apache Derby

Discussions

News: Database development with Apache Derby

  1. Database development with Apache Derby (9 messages)

    An article entitled "Database Development with Apache Derby" has been published at IBM Developerworks. Derby is an Apache sub-project sanctioned to build an all Java relational database. The code for the project has its origins in CloudScape. This article written by Robert Brunner is an introduction to Derby. The article starts with a sound introduction in to basics of relational databases. That introduction includes SQL, schemas, tables, etc. The explanations are very concise. For example, the following quote clearly spells out the differences between exact precision and floating point data types and why this distinction is important.
    If you've never encountered an exact precision data type, the distinction between a decimal and floating-point type may be confusing. The difference lies in the fact that floating-point data types used in computers can't hold every real number. This may seem odd, but recall that there are an infinite number of distinct real values. Most real numbers can't be stored in just a few bytes of memory. For some applications, this loss of precision is acceptable. In many cases, however, it isn't. For example, a financial application can't afford to lose money just because a particular number can't be stored in the computer.
    By the end of the article, the reader should have a full appreciation for how to use Derby. And in true Developerworks fashion, the end of the article contains a number of links to other resources that the reader may find helpful in answering any further questions.
  2. why bother[ Go to top ]

    As usual there is no “Why bother?” link that would explain why should someone bother with this engine rather than HSQL? And the article is a joke: SQL data types, Create a table in Derby – give me a brake, it is either SQL standard compliant and the entire article needs to be shortened to one sentence, or not and then it should explain at length why the hell not.
  3. HSQL is a great little database. However, it does not support multiple threads in a way that can guarantee avoiding of data corruption. It also does not come with support from large, stable companies like IBM and Sun. These things may not matter to you, but it matters to a lot of people, and when I talk to folks this resonates with them.
  4. I was a great fan of HSQL until we found out we couldn't use it in an enterprise-class application we were developing for a customer that required connection-pooling and multiple access from a thread pool in embedded mode. And we really tried to stick with it! But luckily IBM had just released Cloudscape as Derby under an Apache-led project. And that's when we turned to Derby. Derby is great to say the least! We've used it for nearly two years on a fairly large database and we haven't had any data corruption. You can even do online backups and restoration even in embedded mode! Anyone who is writing an application for a small/medium-scale enterprise and doesn't want to blow a lot of cash on the DB, would find Derby useful. I still like HSQL, but really we use it simply for testing and the like. Simply put, HSQL is no match for Derby.
  5. Re: why bother[ Go to top ]

    - Derby is an Apache project backed up by 2 major companies ou there, with lots of developers working on it. - Derby is a mature product - its first release was in 97' - Derby supports all database ACID properties - Support at least 50GB+ of data - Fully multi-threaded engine - Free (there is no subscription fee) - License is Apache 2.0 Not saying HSQLDB is a bad product, but like everything, you need to know what you're dealing with and in which application context/purpose... http://hsqldb.sourceforge.net/doc/guide/ch02.html#N104FC
  6. Re: why bother[ Go to top ]

    Francois, why do not you write an article, I think it will be more informative then the one from "NCSA Research Scientist, Assistant Professor of Astronomy, University of Illinois, Urbana-Champaign"
  7. Developing with Derby configured for embedded mode is painful. In embedded mode you can only have one connection to the database at any time. So if you are running a web application with an embedded database you need to shut it down, so you can use another tool to access the database. Also Ant scripting Derby in embedded mode is tricky. Its a bit of a trial an error process to find something that work. See the IBM article for some pointers: http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0412snell/index.html If you are finding you cant establish a new Connection with sequential Ant targets, you may need to resort to forking off Java processes run them. For example: Beside these issues I have found that Derby works well. Derby also provides you a clean upgrade path to DB2. If you are using Derby in a DB2 shop make sure you use the DerbyDialect in your hibernate configuration, rather than the DB2Dialect. regards Malcolm Edgar http://click.sourceforge.net
  8. I think it's important to clarify that you can have multiple JDBC connections to an embedded database, on one or many threads. What you can't have is a separate VM (or classloader) trying to access the same embedded database at the same time. However, by setting the property derby.drda.startNetworkServer the Derby network server is started in the same VM as your embedded database, and clients from other processes (such as the ij tool or other tools) can access the embedded database. This is a very common scenario.
  9. Hi David, thank for that tip, works well. Time to revisit my build scripts. regards Malcolm Edgar http://click.sourceforge.net
  10. If you are finding you cant establish a new Connection with sequential Ant targets, you may need to resort to forking off Java processes run them.
    Why not run derby in embedded 'server' mode (see David's email above for the property to set) and have ANT connections to the database be done using the network driver? In this case, you can have several instances accessing derby and there is no need to shutdown the engine in-between instances needing to access Derby concurrently. Is there any other reason, for not being able to do do? Cheers.