db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Mogley" <mmog...@adelphia.net>
Subject oracle lob changes, reprinted
Date Thu, 30 Jan 2003 00:29:27 GMT
All,

As requested, I'm resubmitting these changes from December.  I realize the codebase has changed
in significant ways since then - perhaps making it now possible to accomplish this a better
way.

Please, anyone, I'm open to ideas.  Whatever we decide, I would like oracle lobs to working
in ojb as soon as possible.

Michael

----- Original Message ----- 
From: Michael Mogley 
To: OJB Developers List 
Sent: Monday, December 16, 2002 5:19 PM
Subject: changes and additions to support oracle lobs


All,

Attached are the modified and new files needed to retrofit Ojb's support for Oracle Lobs.
 I have tested both Blobs and Clobs for data exceeding 300K.  I have also rerun the junit
tests and received the same failures and errors for Oracle that I did from the original downloaded
build (downloaded some two weeks ago).  So these changes should be safe.  I am not sure how
to bundle these as patches and I don't have direct access to the repository (firewall issues).
 Which is the reason for the zip file.  If anyone can help me submit in a better way in the
future, I'm open to suggestions.

One general comment I must make on the code.  There does not seem to be any consistency in
the conventions used.  And in many cases, Java conventions are downright ignored (such as
capitalizing the first letter of the first word in member instances).  Since Ojb is a project
in the public eye and representative of Java technology, this is probably not a good thing.
 I have taken the liberty to format the source code for the files I touched according to the
rules posted in the guidelines for Jakarta projects.  I used a tool called Jalopy which seems
to be to source-code formatting what Log4j is to logging.  It offers fine-grained control
over the formatting and allows use of external format configuration files.  It also offers
an Ant task wrapper and plugins for major IDEs.  Something to consider.

The changes are detailed below.  I don't mean to impose any of these on the project.  I know
I'm a newcomer and unfamiliar with substantial parts of the code.  I've tried to respect the
existing design as much as possible and, in the interests of not deluging people on the list
with many questions dealing with miniscule issues, I've made a lot of assumptions about the
intent.  

The importance of getting Ojb to support Lobs in Oracle cannot be understated.  The place
I work for develops applications for the Fortune 500 and the ability to manage large documents
as fields in the database is critical.  We use Oracle exclusively, as have the last three
companies on my resume.  

Please read with this in mind.

Humbly submitted,

Michael

New
---
* org.apache.ojb.broker.accesslayer.FieldValue
    Allows a FieldDescriptor to be paired with its value in the context of a specific object.
 This is required by the new methods introduced into ClassDescriptor that allow an arbitrary
subset of fields to be retrieved.

* org.apache.ojb.broker.accesslayer.filters.FieldFilter
    Represents a Strategy for selecting fields from a ClassDescriptor.

* org.apache.ojb.broker.accesslayer.filters.JdbcTypeFieldFilter
    Provides an easy way to select fields based on whether or not they belong to a set of
Jdbc types.

* org.apache.ojb.broker.accesslayer.filters.NotFieldFilter
    Reverses the logic of the FieldFilter it contains.  Used in conjunction with JdbcTypeFieldFilter
to select the complement set of types.

* org.apache.ojb.broker.accesslayer.modifiers.SqlModifier
    Represents a Strategy for modifying Sql generated by SqlGenerator implementations.  Used
by PlatformOracle as an unobtrusive way to create a SELECT FOR UPDATE from generated SELECTs.

Changed
-------
* org.apache.ojb.broker.accesslayer.JdbcAccess
    Added getRawObjectFromColumn method to get the Jdbc lob directly for manipulation.
    Changed executeInsert/executeUpdate methods to delegate to Platform.

* org.apache.ojb.broker.accesslayer.StatementManagerIF
* org.apache.ojb.broker.accesslayer.StatementManager
    Added getSelectByPKStatement(ClassDescriptor, FieldFilter, SqlModifier).  The FieldFilter
determines what fields are selected. The SqlModifier is able to manipulate the generated sql
in ways that would otherwise require an explosion of the SqlGenerator and associated interfaces.
 In my case, I use it to append the "FOR UPDATE" necessary to lock the Lobs in the db.  These
two classes allow me to take advantage of the existing Sql generation/caching infrastructure
without fundamentally changing the design.

* org.apache.ojb.broker.accesslayer.sql.SqlDeleteByPkStatement
    Changed constructor to take into account new FieldFilter parameter.

* org.apache.ojb.broker.accesslayer.sql.SqlGenerator
* org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
    Added getPreparedSelectByPkStatement(ClassDescriptor, FieldFilter).  The FieldFilter determines
what fields are selected.

* org.apache.ojb.broker.accesslayer.sql.SqlInsertStatement
    Changed appendListOfValues method to use Platform to determine Sql value string for each
respective field.  This is necessary because certain field types on certain platforms -- namely
Oracle Lobs -- must be passed an initialization string for insert/update operations. Parametrizing
such fields is incorrect. In the future, this could be used as a way to improve support for
custom user-defined db types, not to mention additional complex built-in types.

* org.apache.ojb.broker.accesslayer.sql.SqlSelectByPkStatement
    Changed appendListOfColumnsForSelect method to use FieldFilter to determine columns to
generate in output.

* org.apache.ojb.broker.accesslayer.sql.SqlUpdateStatement
    Changed appendSetClause method to use Platform to determine Sql value string for each
respective field. 
    
* org.apache.ojb.broker.metadata.ClassDescriptor
    Added getFieldDescriptors(FieldFilter).  Uses FieldFilter to determine descriptors to
return.  Used by PlatformOracle to extract Lob and nonLob FieldDescriptors in order to generate
correct SELECT statements.
    Added getValues(Object, FieldFilter).  Returns descriptor-value pairs representing the
object's values for the fields selected by the filter.
    Added getNonKeyValues(Object, FieldFilter).  Returns descriptor-value pairs representing
the object's values for the nonkey fields selected by the filter.
    Added getFieldDescriptors(FieldFilter).  Returns the descriptors selected by the filter.
    Added getNonPkFields(FieldFilter).  Returns the non-primarykey descriptors selected by
the filter.

* org.apache.ojb.broker.metadata.FieldDescriptor
    Formatted source with Jalopy

* org.apache.ojb.broker.platforms.Platform
* org.apache.ojb.broker.platforms.PlatformDefaultImpl
* org.apache.ojb.broker.platforms.PlatformOracle
    Added getFieldInitValue(FieldDescriptor).  Returns the correct Sql initialization string
to use for the given field in insert/update operations.
    Added bindInsert(PreparedStatement, ClassDescriptor, Object).
    Added bindUpdate(PreparedStatement, ClassDescriptor, Object).
    Added executeInsert(ClassDescriptor, Object, PersistenceBroker).
    Added executeUpdate(ClassDescriptor, Object, PersistenceBroker).
    The implementation for these methods has been moved from JdbcAccess to PlatformDefaultImpl.
 PlatformOracle is now able to override the default insert/update behavior to handle Lobs
correctly.  Although this change was prompted by the Oracle issue, it was probably a weakness
in the design to begin with.  Generally speaking, it's better to have logical operations delegate
to physical ones, and this change is forward-looking in that regard.



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message