db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Mogley" <michael.mog...@verizon.net>
Subject Re: changes and additions to support oracle lobs
Date Tue, 17 Dec 2002 17:29:21 GMT
Thanks.  If there is any problem with what I've done, feel free to email me


----- Original Message -----
From: "Mahler Thomas" <thomas.mahler@itellium.com>
To: "'OJB Developers List'" <ojb-dev@jakarta.apache.org>
Sent: Tuesday, December 17, 2002 12:12 AM
Subject: AW: changes and additions to support oracle lobs

Hi Michael,

thanks for your contribution!
I will review it and integrate it into the code base!


-----Urspr√ľngliche Nachricht-----
Von: Michael Mogley [mailto:michael.mogley@verizon.net]
Gesendet: Dienstag, 17. Dezember 2002 02:20
An: OJB Developers List
Betreff: changes and additions to support oracle lobs


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

Please read with this in mind.

Humbly submitted,


* 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

* org.apache.ojb.broker.accesslayer.JdbcAccess
    Added getRawObjectFromColumn method to get the Jdbc lob directly for
    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
    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
    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

View raw message