Tuesday, December 17, 2013

JDBCWizard now supports Oracle 12.1

The latest build of JDBCWizard adds support for Java code generation for Oracle 12.1. From our viewpoint there were a few small but unavoidable changes we had to make to get JDBCWizard to work with 12.1. We will be listing some of the things we noticed in upcoming blog posts as they are of interest to the broader Oracle community.

The most visible change is that  oracle.sql.CLOB and  oracle.sql.BLOB are deprecated and replaced with oracle.jdbc.OracleBlob and oracle.jdbc.OracleClob. We will look at changing and regression testing our generated code when 12.(>1) comes out.

Thursday, May 9, 2013

JDBCWizard adds support for JSON and JSON RPC 2.0 Services for Oracle and PL/SQL

Recently we've been looking at the increasing adoption of JSON and how JDBCWizard can make life easier for people who want to create JSON web services for Oracle. We have just released our first build with JSON support. It creates service classes for either JSON or JSON RPC 2.0.



We will go into the details of how to use our JSON functionality in future posts, but if you want to 'try and see' you need to:



Download a demo of JDBCWizard



Download Google Gson, which we use for JSON serialization and deserialization

Select either 'JSON' or 'JSON RPC' in the 'Service Options' screen below:



Generate the code and compile it with the Gson library in your classpath

Thursday, February 21, 2013

The real reason people use separate disks for indexes and tables

One thing we keep hearing is that some users continue to insist on separate tablespaces for indexes and tables. When asked "Why?" the answer is "for performance reasons". When asked how exactly this will make things faster the response is that an index scan on the index disk leads to random IO against the table disk.

This answer is flawed for multiple reasons. Firstly it assumes IO capabilities that are positively medieval compared to people actually have today. Also: How likely is it the the only load on your system will consist of a single indexed lookup? More importantly - while indexes and tables were indeed separated it had nothing to do with performance. I know. I was there.

The real reason indexes and tables were separated was that the available disks were so small that it was impossible to fit all the data onto only one. If you lost a disk you also lost all the tables in any tablespaces that were in it, even if they were mostly stored on other drives. This meant it was time to do a recovery from backup, which was not for the faint hearted.

So as a consequence we'd put the indexes on a separate set of disks in dedicated index tablespaces. If we lost an index disk we'd shut down the database, drop the Index tablespace, install a new drive, build a new index tablespace and then rebuild the indices, without losing any data or having to chance our arm with backup tapes.

Monday, November 5, 2012

JDBCWizard now supports Java 1.7

As above - JDBCWizard now supports Java 1.7.  As part of  our certification process we reviewed the new features and didn't see anything that would justify changing our generated  code.