ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: SqlSession.close() without committing
Date Wed, 07 Apr 2010 16:57:21 GMT
Unit Tests!

On Wed, Apr 7, 2010 at 9:53 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Clinton,
>
>     I'm not looking for a specification in that sense of the word :) I
> meant something along the lines of Design by Contract:
> http://en.wikipedia.org/wiki/Design_by_contract
>
>     If my code depends on iBatis and upgrading to a newer version breaks my
> code then how do we establish whether the problem is:
>
> 1. The iBatis implementation no longer conforms to its specification (i.e.
> an iBatis bug)
> 2. My code assumed something about an iBatis method that was not guaranteed
> by the specification (i.e. a bug in my application)
>
> Thanks,
> Gili
>
>
> On 07/04/2010 9:50 AM, Clinton Begin wrote:
>
> Then you might be happier with a spec like JPA.  Although I'd warn that
> such specs are rarely implemented consistently.
>
> This is what has killed J2EE vs. the alternatives.  Look at the history:
>
> * CMP - Spec.  Dead, along with all implementations.
>
> * EJB - Spec.  Dead.  Spring killed it -- not a spec.
>
> * JDO - Spec.  Dead, along with all implementations.
>
> * JSF - DOA.  Bad idea to begin with, and has failed to unify client side
> Java.  Struts, GWT, Wickett, Stripes, ZK, Tapestry, etc.  all still exist --
> and are more popular than JSF -- all without a spec.
>
> Some specs have succeeded, due to their simplicity and natural interface
> boundary (usually a network connection requiring a driver of sorts).  These
> include Servlet, JDBC and JMS.  Even though they're not the nicest, they're
> simple and necessary. Yet they too differ in many ways, especially JDBC.
> JPA has a chance, but only because they essentially took the two most
> popular frameworks that weren't specs and made them into a spec... nobody
> will be winning any innovation awards for that one.
>
> The spec doesn't guarantee anything.  Kind of like a green light doesn't
> guarantee that cars won't be driving through the opposing red light at an
> intersection... do you not check?
>
> The only thing that defines how a framework will work is the framework
> itself -- spec or not.  The only protection you have is your own unit,
> functional and integration tests -- which you need anyway, as it's also the
> only way you'll know if YOUR code works.
>
> We've created a user guide to describe the intended behavior of the iBATIS
> framework.  If it is somehow incomplete or incorrect, you can contribute to
> it via the wiki discussed on page 2.
>
> Clinton
>
>
>
> On Tue, Apr 6, 2010 at 10:37 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>
>>
>>> Yes, iBATIS will rollback the connection if it deems it necessary.  The
>>> only
>>> time you might need to call rollback explicitly is if you have a "select"
>>> that actually updates data in the database.  Such is sometimes the case
>>> with
>>> stored procedures.
>>>
>>>
>>
>>  Clinton,
>>
>> Coming back to our earlier discussion of Javadoc... where do you document
>> the iBatis specification? I hope you understand my reluctance of depending
>> on behavior outside of an explicit specification. Today one person will tell
>> me the method works one way, tomorrow another person will tell me a
>> different story. I'd love to have an official document to refer back to.
>>
>>
>> Thanks,
>> Gili
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>
>>
>
>

Mime
View raw message