db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <t...@apache.org>
Subject Re: working on Oracle LOBs
Date Thu, 28 Nov 2002 21:55:14 GMT
Hi Michael,

Michael Mogley wrote:
 > Before I attempt major surgery, could someone explain why the flow of
 > control for the store operation isn't as follows?
 >
 > PersistenceBroker -> Platform -> JdbcAccess
 >
 > Shouldn't the platform dictate what type of access is being used and
 > HOW that access is used?

We did introduce the Platform interface at a late stage of OJB design. 
In the early days I tried to remain as db indepented as possible.

That's why Platform is a simple callback interface that is only called 
at specific spots, where it can be avoided to do something db specific.

Thus the flow of control may seem a bit strange at first sight.

 > In order to store an object where one or
 > more fields map to an Oracle LOB, I have to perform two separate Sql
 > operations: an INSERT and a SELECT FOR UPDATE.

Why is it so difficult to store a LOB with oracle?

I recently commited the following stuff to PlatformDefaultImpl:
     public void setObjectForStatement(PreparedStatement ps, int index, 
Object value, int sqlType)
             throws SQLException
     {
         if ((value instanceof String) && (sqlType == Types.LONGVARCHAR))
         {
             String s = (String) value;
             ps.setCharacterStream(index, new StringReader(s), s.length());
         }
         else
         {
             ps.setObject(index, value, sqlType);
         }
     }

IMO something similar should be sufficient for a CLOB or BLOB too?


If we flip around the
 > existing dependency order to the above, it would help me a great
 > deal.  In this case, we would have something like:
 >
 > PersistenceBroker.store(classDescriptor, object)
 >
 > -> Platform.executeInsert(classDescriptor, object)
 > [PlatformOracleImpl]
 >
 > -> JdbcAccess.executeInsert(fieldDescriptors, object) [INSERT INTO
 > MyTable IntegerCol1, IntegerCol2, ClobCol VALUES (1, 2,
 > EMPTY_CLOB())]
 >
 > -> JdbcAccess.executeUpdate(lobDescriptors, object) [SELECT ClobCol
 > FROM MyTable FOR UPDATE]
 >
 > Here, JdbcAccess is modified to take an arbitrary array of field
 > descriptors to insert/update.  This would make it easier for the
 > particular Platform implementation to manipulate JdbcAccess to its
 > ends.
 >
 > In addition, we would need a FunctionFieldDescriptor class that would
 > allow modelling of "EMPTY_CLOB()" as a valid field descriptor used
 > during the sql generation.
 >
 > Is anyone adamantly against changing the design in this way?  Any
 > better suggestions on how to approach the problem?
 >

I'm not against changes. But the current design has been stable for some 
time for a variety of DB platforms! Before performing such a "major 
surgery" I'd like to understand if it is unavoidable.

What do the Oracle experts say?

cheers,
Thomas

 > Michael



Mime
View raw message