Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <3FBF6F9C.1030209@gmx.ch>
Date: Sat, 22 Nov 2003 15:15:56 +0100
From: Jakob Braeuchi <jbraeuchi@gmx.ch>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: [VOTE] Design bug fixed - check in?
References: <3FBE7E9E.40307@code-au-lait.de>
In-Reply-To: <3FBE7E9E.40307@code-au-lait.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi armin,

i do not like api-changes in release-candidates. but if it's 
_absolutely_ necessary to fix a bug, i think we should nonetheless do it.

jakob

Armin Waibel wrote:

> Hi all,
> 
> approximately 10 days ago I posted a mail concerning
> a "design bug" in OJB-Kernel api
> ("Kernel api changes be necessary!?").
> The problem was the loss of persistent field
> metadata information from PB to the database operation
> classes.
> 
> For examples: When storing an object sooner or
> later an array of object field values were passed
> to StatementManager. Then the StatementManager lookup the
> jdbcTypes using SqlHelper class, because we pass the
> field value array without any metadata information.
> But we know the jdbcTypes from the metadata. Thus if
> we pass a ValueContainer class
> ValueContainer
> {
> Object value;
> int jdbcType;
> }
> 
> instead of the pure value object, we no longer need
> many of SqlHelper/SqlTypeHelper methods.
> 
> Another problem is the support of BOOLEAN datatype.
> If the given object in SqlHelper#getSqlTypeByValue(Object value)
> is instance of Boolean always Types.BIT instead of Types.Boolean
> is returned. So, there is no way to support Type.BOOLEAN
> with current implementation.
> 
> Local I made the described refactoring, running the test
> suite give me the same result as the CVS head, also
> the performance test (perf-test task).
> 
> I had to change methods of two intern kernel interfaces
> - JdbcAccess and StatementManagerIF.
> 
> StatementManagerIF:
> <     int bindValues(PreparedStatement stmt, Object[] values, int index) 
> throws SQLException;
> ---
>  >     int bindValues(PreparedStatement stmt, ValueContainer[] 
> valueContainer, int index) throws SQLException;
> 
> JdbcAccess:
> <     public ResultSetAndStatement executeSQL(String sqlStatement, 
> ClassDescriptor cld, Object[] values, boolean scrollable) throws 
> PersistenceBrokerException;
> ---
>  >     public ResultSetAndStatement executeSQL(String sqlStatement, 
> ClassDescriptor cld, ValueContainer[] values, boolean scrollable) throws 
> PersistenceBrokerException;
> 129c130
> <     public int executeUpdateSQL(String sqlStatement, ClassDescriptor 
> cld, Object[] values1, Object[] values2)
> ---
>  >     public int executeUpdateSQL(String sqlStatement, ClassDescriptor 
> cld, ValueContainer[] values1, ValueContainer[] values2)
> 
> 
> By the way, I split PBImpl class (~3000 loc! monster) into
> PBImpl (~ 1700)
> MtoNBroker(~400 loc)
> QueryReferenceBroker (~900)
> this should help us to keep track of source.
> 
> I propose to accept the "design fix" and refactoring.
> What do you think? Comments?
> 
> 
> regards,
> Armin
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org