db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <ar...@code-au-lait.de>
Subject Re: [VOTE] Design bug fixed - check in?
Date Fri, 28 Nov 2003 13:26:16 GMT
Hi all,

seems there are no negative votes, some neutral and
a few positive.
Thus I will start today with the check in of the "design bug fix".

I think 95% of the users will not note the change of the three internal 
kernel interface method signatures. But I also put a note to the 
release-notes. I asked Thomas to label the current CVS before I start 
with my check in.
The label is
OJB_1_0_RC4_20031128

regards,
Armin

Armin Waibel wrote:
> Hi Olli,
> 
> oliver.matz@ppi.de wrote:
> 
>> Hello,
>>
>> I have not quite understood all consequences of
>> the proposed changes, so I would like to ask some
>> questions.
>>
> I expected that ;-)
> 
>> 1. Are  you going to introduce
>> one instance of class ValueContainer for every
>> field of each persistent object in memory?
> 
> yep
> 
>> Or one such instance for every field of
>> each persistence-capable class in repository.xml?
>> If the first is true, could this be a performance issue?
> 
> I run the 'perf-test' task with old and changed
> version. There is no different.
> 
>> How long are these ValueContainers going to exist until they are 
>> garbage collected?
>>
> ValueContainer is only a "transport class" for the value
> and the associated jdbc type. When you store an object
> PB obtain e.g. a ValueContainer array for each field of
> the object and pass this array to JdbcAccess. After the
> executeInsert/Update... method call the ValueContainer
> is free for garbage collection.
> 
>> 2. Can you explain a specific scenario that currently
>> fails?  Otherwise, this is not a bug but another feature.
>>
> Take one of the 'VARCHAR' field in the test cases
> and change to 'LONGVARCHAR' (e.g. say you want to store
> a huge text file). Then create in the test a very
> long string
> for (int i = 1000 - 1; i >= 0; i--)
> {
>   projectName = projectName + "############";
> }
> I made this test with sapdb and get an error:
> 
> SAP DBTech JDBC: Parameter 2: value too large.
> com.sap.dbtech.jdbc.exceptions.ValueOverflow: SAP DBTech JDBC: Parameter 
> 2: value too large.
>     at 
> com.sap.dbtech.jdbc.translators.DBTechTranslator.checkFieldLimits(DBTechTranslator.java:1261)

> 
> 
> when using the current CVS version. This test pass with my local
> version.
> 
> OK, you can argue this only a missing feature like below
> for support of BOOLEAN ... ;-)
> 
>>
>>> else if (value instanceof Boolean)
>>>         {
>>>             return Types.BIT;
>>>         }
>>
>>
>>
>> Another reason why that code is bad is
>> the costly cascading 'instanceof'.
>>
> yes, but as you said above in return we generate
> many ValueContainer objects
> 
>>
>>> If the field value is a boolean always BIT
>>> is returned. But jdbc type BIT and BOOLEAN
>>> can be mapped to a java boolean
>>
>>
>>
>> I had run into this annyoing issue, too.
>> Nevertheless, IMO the fact that OJB maps java boolean to JDBC BIT is 
>> not a bug but a missing feature.
>>
> If it would be an "exotic" datatype then I agree
> with you, but BOOLEAN??
> 
>>> Are they really significant?
>>
>>
>>
>> The application code might not compile against
>> the next OJB.  That is significant, isn't it?
>>
> you are right. If user direct use JdbcAccess (2 changed methods) or 
> StatementManager (1 changed methods) or implemented his own
> version of these two classes.
> The curse of a flexible, pluggable api ;-)
> 
>> I do agree that your changes are tempting.
>> Besides, I do agree that the best time for drastic source code 
>> refactoring changes with little or no impact on the behaviour is 
>> BEFORE rather than after the branch.
>>
>> But I have the feeling that these changes send the wrong message to 
>> our users.  I feel very
>> uncomfortable with another API change.
>> We have just received valueable and serious
>> feedback (from Chris et al) about the frequent API changes in the 
>> release candidates.  Have we learned that lesson?!
>>
> hmm, we all do our best, but I think OJB has an
> exceptional position because we have more than 20
> pluggable interfaces (many of them in the kernel).
> So for us it's more difficult to fix bugs without
> do any changes of internal but pluggable interfaces.
> 
>> Typical users who use OJB now do get along with missing features, 
>> sometimes even with minor bugs!  They will not and do not want to 
>> benefit from added features.
>>
>> Future users of OJB can start with OJB 1.x (or
>> whatever post-1.0 will be called) as soon
>> as the first release from that branch is made.
>>
>> Sooner or later, the branch will develop
>> away from each other.  Yes, this will make
>> merges more difficult, but that is inevitable.
>>
>> If we should nevertheless agree to accept this,
>> we should at least write a comprehensive
>> documentation with example code snippets
>> how to port an application. 
>> Maybe we could provide an
>>
>> abstract class DefaultStatementManager    implements StatementManagerIF
>>
>> that delegates the fresh method, e.g.
>>   bindValues( ... , ValueContainer[], ...)
>> to the abstract old ones, e.g.,
>>   bindValues(... , Object[] values, ... ) and imitates the new behaviour.
>>
>> Then the user's changes amount to
>> changing "implements StatementManagerIF" to
>> "extends DefaultStatementManager" in their code.
> 
> I think this is not necessary. We change only three
> methods and in your code you only have to do "obj.getValue()"
> instead use the "obj" direct.
> 
>> A note about that should be added
>> to the javadoc of StatementManagerIF and to
>> the release notes.
>>
> anyway
> 
> regards,
> Armin
> 
> 
>> Olli
>>  
>> ---------------------------------------------------------------------
>> 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
> 
> 
> 



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


Mime
View raw message