Unit Tests! On Wed, Apr 7, 2010 at 9:53 AM, cowwoc <cow...@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 <cow...@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-unsubscr...@ibatis.apache.org >> For additional commands, e-mail: user-java-h...@ibatis.apache.org >> >> > >
