Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (athena.apache.org: domain of ellis.m.a@gmail.com
 designates 209.85.220.228 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=nQZFcuAqIoSETmNdZMlGbqUKaLX/X480bi70AxKKufcYXOyMECXmb4+OTGe/GxDZhT
         nWyMKwkxg2UyYPkS/BL2dkMRAu+/zNBc6qgYU8FAgqn7wTHNCfVtKPw7uS+XUqMdbKsg
         5ZEI/R9yOzgPxVsTz8Znv+7PA+i7DRKtWtbSc=
MIME-Version: 1.0
In-Reply-To: <4BBCAA6B.5050406@bbs.darktech.org>
References: <4BBC0BF3.5050109@bbs.darktech.org>
	 <h2z16178eb11004070650qf3c433eameefef5dc0a5cbd62@mail.gmail.com>
	 <4BBCAA6B.5050406@bbs.darktech.org>
Date: Wed, 7 Apr 2010 17:43:13 +0100
Message-ID: <x2ua54079f21004070943reea9bdaaz37f8c44f98742c08@mail.gmail.com>
Subject: Re: SqlSession.close() without committing
From: Martin Ellis <ellis.m.a@gmail.com>
To: user-java@ibatis.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One thing I'd have liked to see is an indicator of which packages are
intended as API packages for public consumption, and which packages
are implementation.

The idea being that I'd like to minimise dependencies on 'private' API.
There're a few incentives to do that:

* making sure you're using a well-trodden code paths - they tend to be
well tested;
* reducing the likelihood of having to rework code when upgrading to
later versions;
* ensuring you're not caught out if iBATIS ever gets an OSGI
MANIFEST.MF, which prevents importing private packages.

For example, right now I have a dependency on BoundSql - and I've no
idea whether that's likely to be maintained as part of a stable API.

I don't share the cynicism about Javadoc - I can think of plenty of
libraries outside the JDK with useful Javadoc.  For example, the
Apache Commons javadocs tend to be very good, describe corner-cases
like null-handling, and have class javadocs that show useful examples.

I've been completely baffled by how MetaClass, MetaObject,
ObjectFactory and ObjectWrapper and ObjectWrapperFactory are related,
and what they're used for.  I don't know whether they're all
considered public API, but I've had to trace through them tracking
down bugs.

Martin


On 7 April 2010 16:53, cowwoc <cowwoc@bbs.darktech.org> wrote:
> Clinton,
>
> =C2=A0=C2=A0=C2=A0 I'm not looking for a specification in that sense of t=
he word :) I meant
> something along the lines of Design by Contract:
> http://en.wikipedia.org/wiki/Design_by_contract
>
> =C2=A0=C2=A0=C2=A0 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 guarante=
ed
> 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.=C2=A0 Although I'd warn t=
hat such
> specs are rarely implemented consistently.
>
> This is what has killed J2EE vs. the alternatives.=C2=A0 Look at the hist=
ory:
>
> * CMP - Spec.=C2=A0 Dead, along with all implementations.
>
> * EJB - Spec.=C2=A0 Dead.=C2=A0 Spring killed it -- not a spec.
>
> * JDO - Spec.=C2=A0 Dead, along with all implementations.
>
> * JSF - DOA.=C2=A0 Bad idea to begin with, and has failed to unify client=
 side
> Java.=C2=A0 Struts, GWT, Wickett, Stripes, ZK, Tapestry, etc.=C2=A0 all s=
till 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).=C2=
=A0 These
> include Servlet, JDBC and JMS.=C2=A0 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.=C2=A0 Kind of like a green light doe=
sn'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.=C2=A0 The only protection you have is your own uni=
t,
> functional and integration tests -- which you need anyway, as it's also t=
he
> only way you'll know if YOUR code works.
>
> We've created a user guide to describe the intended behavior of the iBATI=
S
> framework.=C2=A0 If it is somehow incomplete or incorrect, you can contri=
bute 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. =C2=
=A0The
>>> only
>>> time you might need to call rollback explicitly is if you have a "selec=
t"
>>> that actually updates data in the database. =C2=A0Such is sometimes the=
 case
>>> with
>>> stored procedures.
>>>
>>
>> Clinton,
>>
>> Coming back to our earlier discussion of Javadoc... where do you documen=
t
>> the iBatis specification? I hope you understand my reluctance of dependi=
ng
>> 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
>>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org