Tuesday, December 17, 2013
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
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
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.