ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cowwoc <cow...@bbs.darktech.org>
Subject Re: SqlSession.close() without committing
Date Wed, 07 Apr 2010 15:53:15 GMT
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 
> <mailto: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
>     <mailto:user-java-unsubscribe@ibatis.apache.org>
>     For additional commands, e-mail: user-java-help@ibatis.apache.org
>     <mailto:user-java-help@ibatis.apache.org>
>
>


Mime
View raw message