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 Mon, 24 Nov 2003 22:08:33 GMT
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


Mime
View raw message