Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 29866 invoked from network); 9 Jul 2009 14:45:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Jul 2009 14:45:16 -0000 Received: (qmail 34707 invoked by uid 500); 9 Jul 2009 14:45:25 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 34639 invoked by uid 500); 9 Jul 2009 14:45:24 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 34631 invoked by uid 99); 9 Jul 2009 14:45:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jul 2009 14:45:24 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [77.238.184.38] (HELO smtp106.mail.ukl.yahoo.com) (77.238.184.38) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 09 Jul 2009 14:45:13 +0000 Received: (qmail 8484 invoked from network); 9 Jul 2009 14:44:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.it; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Vs08rrC8SUX6s5KJmRVyKjDRW9pH9LAQDUFVjJt4NlKztBJBSDiYW5PHQx72rN5nHBiZHlOwLKymn+u3DIy1ORkttotY++SFUX37c9/HaefUOuo8aRiHNG5KfLNumkLRd/hIu65xh+Bq+tlViI6MNxdcWV7bEnLS3PhaSvENczg= ; Received: from unknown (HELO ?192.168.1.3?) (alexbottoni@151.61.2.217 with plain) by smtp106.mail.ukl.yahoo.com with SMTP; 9 Jul 2009 14:44:51 -0000 X-Yahoo-SMTP: 9ezwDEiswBCdH9TDPDmtxbz3dxmVvlB9 X-YMail-OSG: .6PwGQIVM1k0jzZGF4Tffv6kdFgNV6vAJfW.WyZ7gPFkGVO5Ihw1oLAhnGNlS8Vu98ax1aoe.pJzCBS1138CM4BWrVX5RKAh.SSt7mkuM6zNp7cHdgzXpN9BlU9xODvW1Uo8NjmtWQYhJiI7Jnt.C2O3bRIJw4VP4RgBy1sMdmlZSicm4poQqlZReIiZfuHqbAeIk04z.Zj6C2cE3oQS12x6F4cKe2h22qmEUcsmmB_y1F7qs.Kw0Drn4r_lZv9rjlPDu1dZc7MYvpt6icWyO82qoru3ruFEZ62rJ_3zOjmig0vR7OEaCRFA3VIgpctTCcIdAmyjo7BMUdGyEttpuZ8F.HvXy44UTah3ghpOkqNAuNeikw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A560262.6020004@yahoo.it> Date: Thu, 09 Jul 2009 16:44:50 +0200 From: Alessandro Bottoni User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Derby Discussion Subject: Re: How would you implement a record-level versioning system with Derby and Java? References: <4A55EA88.1010506@yahoo.it> <5627810d0907090630p768223f9sf08d911a92546a70@mail.gmail.com> In-Reply-To: <5627810d0907090630p768223f9sf08d911a92546a70@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Donald McLean ha scritto: > Actually, this is a question that I have previously considered for a > project that I am starting. > > My thought was to have an identity column (value assigned by the DBMS) > and a separate ID column. From here, you can do several different > things: > > 1. Have a "version" column. Use the max function to find the current > version, or make the current version -1 or something else easy to > find. > 2. Use the max function on the identity column to find the latest version. I thought about this mechanism but I'm not completely convinced it would be the right one. I mean, there are two different "user views" to take into account: 1) The user view onto the whole database while browsing/searching for a specific record. 2) The single-record view used to examine/edit a specific record. While it is easy to use a SELECT with MAX to get the latest version of a specific record, it is not clear how I could get only the most recent version of every single record to build up the "browse" view. It looks like I should use a nested SELECT: first, select all matching records and, second, select the latest version of each of them. A little bit messy... > 3. Have "previous" and "next" columns with the identity values of the > appropriate objects in the chain. The current version would have a > null "next". Nice approach! Actually, I did not think about this possibility. Many thanks for this suggestion. This would simplify a lot the SELECT operation used to generate the "browse" view (just select all of the records that have a NULL "next-version" field) while maintaining the possibility to go back and forth between versions (and build up a list of them, if needed). I think I will experiment with this one. > There are probably other approaches that I haven't thought of. I thought about triggers/procedures, as well, but I had the feeling they would have the same problem as the SELECT + MAX approach. > I have used and recommend Hibernate. It simplifies things immensely > IMO, though it does have its quirks (some of which are not properly > explained by the documentation). It also works well with a number of > other DBMS (if changing is something that might happen later). Thanks. I'm new to Hibernate, as well, so I'm going to ask you (all) which book is best for learning Hibernate. I browsed a little bit on Amazon's but I did not find anything to be enthusiastic about. What would you suggest me as a good starting point/introductory book? Any good web article/tutorial to signal, as well? Thanks again. -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ "In mathematics you don't understand things. You just get used to them." -- John von Neumann