Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of bpendleton.derby@gmail.com
 designates 74.125.83.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=LdEGP4yupI6SYERGrDpIq7YE34vZ60+NMvEZ9Mb/iFtireEyTmnI6QmhxUkoxvFVDX
         ZdZwxSQ6eljcyBzo0gPx5PY65sFWNKk89sT58fl9B6PLXW7v3ljP6ZXOJdSJfkGMOmRq
         Ma5Nes2ItPfyR2lNaIktNDD+i7mSBs9XjL1Q8=
Message-ID: <4BFCA8A5.2060500@gmail.com>
Date: Tue, 25 May 2010 21:50:45 -0700
From: Bryan Pendleton <bpendleton.derby@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: JPA 2.0 and Derby 10.6.1.1 ERROR XCL13
References: <035F2F80-9D74-4C47-809B-7B2F23FF2D54@jpl.nasa.gov>
 <4BFC8813.1000702@gmail.com>
 <8BAC5EC7-BC66-482F-BE95-8E35D3C88CE7@jpl.nasa.gov>
In-Reply-To: <8BAC5EC7-BC66-482F-BE95-8E35D3C88CE7@jpl.nasa.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This part:

 > where product0_.lid=? and product0_.userVersion=? fetch first 2 rows

seems to match this part:

 > cq.where(cb.and(cb.equal(lidAttr, lid), cb.equal(userVersionAttr, userVersion)));

pretty closely, so it's hard to imagine why your O/R tool thought it
needed to set 3 parameters in the query.

Unless it somehow thought it was trying to set the "first 2 rows" part? That is,
did it think it had prepared "fetch first ? rows" and was trying to set the 2?

You may need to ask in a forum that covers your O/R tool, to get some
suggestions about how to understand its query generation behaviors.
Did you say you were using Hibernate?

Regarding whether Derby is processing the statement twice, I think that
the log is just a bit hard to read: the statement is listed twice,
but once is a "begin compiling" trace, and once is an "end compiling" trace.

So, I'm afraid I don't have any breakthrough answers for you, but hopefully
you're armed with more information to ask a more specific question to the
providers of the O/R tool.

thanks,

bryan