From dev-return-10633-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Mon Feb 23 16:18:29 2009 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 64827 invoked from network); 23 Feb 2009 16:18:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Feb 2009 16:18:29 -0000 Received: (qmail 96730 invoked by uid 500); 23 Feb 2009 16:18:29 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 96702 invoked by uid 500); 23 Feb 2009 16:18:29 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 96691 invoked by uid 99); 23 Feb 2009 16:18:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Feb 2009 08:18:29 -0800 X-ASF-Spam-Status: No, hits=2.4 required=10.0 tests=HTML_MESSAGE,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of techhusky@gmail.com designates 209.85.132.242 as permitted sender) Received: from [209.85.132.242] (HELO an-out-0708.google.com) (209.85.132.242) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 23 Feb 2009 16:18:19 +0000 Received: by an-out-0708.google.com with SMTP id d40so716175and.18 for ; Mon, 23 Feb 2009 08:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=sW6CWib0miXypJ8MDGNy6dNFTeMWzsGJxOuySubxZdU=; b=Wa0gyHVzhcwcisG3EtfEG/BKR1sUkq/O2xyKgdvBGSPW1CHvaw4FBnR+1y+d63M1PG IPG0KJ08QSa5QuhY7/519JUBSPLetq9WV9NsSSFM1wEgMeikpC8dRu4ifI/zQTndkIEd uqfHxPWeG8TFgjlLrlx006TRWrmN/86VgoakM= 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; b=ntE0qgrCt/HZwRvQ3gG1rDUv9P5bmQFDUOvIlG4RvikWJQSqXIfpLOCAbQTF7STRbN ScTkpnZNDYBLzlf9X65UuqSzvtJtVdcULE4dm+5I39BQRbms+vMjnrxp95DRD+bDvq9o Ro0W6SBLSk9m+KddLFhLoEfFNhRVyfgQOimkU= MIME-Version: 1.0 Received: by 10.100.138.10 with SMTP id l10mr4177018and.25.1235405878751; Mon, 23 Feb 2009 08:17:58 -0800 (PST) In-Reply-To: <1235400068286-2372385.post@n2.nabble.com> References: <49A1D9AB.70402@gmail.com> <1235400068286-2372385.post@n2.nabble.com> Date: Mon, 23 Feb 2009 10:17:58 -0600 Message-ID: Subject: Re: @PersistentCollection question From: Jeremy Bauer To: dev@openjpa.apache.org Content-Type: multipart/alternative; boundary=0016e645b9c48e70cd0463985898 X-Virus-Checked: Checked by ClamAV on apache.org --0016e645b9c48e70cd0463985898 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tim, I think you've found a valid problem in the test cases. The basic use of PersistentCollection does not enforce ordering so results will vary for each database. Depending on what is being tested you could: a) Modify the validation code to validate the collection based on non-deterministic ordering of data. This may be the best option since the OpenJPA execution path being tested is the same. b) Add explicit column ordering using @OrderBy. This requires the use of a persistent field/property that is order-able. Possibly the Id field? This also requires that the elements in you your list are in that order. Might be get kind of messy - and this changes the OpenJPA execution path. c) As Pinaki mentioned, use synthetic ordering. This can be achieved with @OrderColumn. An 'order' column will be added to the collection table and OpenJPA will use this column to manage the order of the collection. If changing the execution path isn't a big concern, this is likely the best option. However, OpenJPA has OrderColumn specific tests, so I vote for option a) to keep the non-ordered path(s) covered, if possible. -Jeremy On Mon, Feb 23, 2009 at 8:41 AM, Pinaki Poddar wrote: > > afaicr, OpenJPA was maintaining ordering for elements for field that is > declared (or even instantiated) as java.util.List. It has the capability of > creating synthetic column to maintain element ordering even when @OrderBy > or > some other ordering spec is absent. > > > > > Tim McConnell wrote: > > > > Hi, I see a number of inconsistencies in the OpenJPA Junit testcases > > concerning > > the usage of the @PersistentCollection annotation on a java.util.List > > variable > > without the @OrderBy annotation. If I'm interpreting this scenario > > correctly, > > without the @OrderBy annotation there is no column in the database used > > for > > ordering when retrieving the List back into memory, and thus there can be > > no > > assumption made about that order in the testcase. This appears to be why > > these > > testcases work on some database and not others (e.g., works on Derby, > > fails on > > PostgreSQL). Am I interpreting it correctly ?? Or am I missing something > > obvious ?? > > > > -- > > Thanks, > > Tim McConnell > > > > > > -- > View this message in context: > http://n2.nabble.com/%40PersistentCollection-question-tp2369556p2372385.html > Sent from the OpenJPA Developers mailing list archive at Nabble.com. > > --0016e645b9c48e70cd0463985898--