Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 11634 invoked from network); 22 Jan 2010 10:35:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Jan 2010 10:35:42 -0000 Received: (qmail 13206 invoked by uid 500); 22 Jan 2010 10:35:42 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 13150 invoked by uid 500); 22 Jan 2010 10:35:42 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 13142 invoked by uid 99); 22 Jan 2010 10:35:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jan 2010 10:35:42 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jan 2010 10:35:41 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7D49629A0012 for ; Fri, 22 Jan 2010 02:35:21 -0800 (PST) Message-ID: <940141640.2131264156521511.JavaMail.jira@brutus.apache.org> Date: Fri, 22 Jan 2010 10:35:21 +0000 (UTC) From: "Kristian Waagan (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-4520) Refactor and extend data type cloning facilities In-Reply-To: <583334191.368401263993534659.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803659#action_12803659 ] Kristian Waagan commented on DERBY-4520: ---------------------------------------- Committed patch 2a to trunk with revision 902050. I'll move on to provide the patch for cloning a store stream (extracting the code from the patch attached to DERBY-3650). Note that cloning a store stream doesn't materialize the data value. Another stream object will be instantiated which will read data from the same data pages as the original stream. > Refactor and extend data type cloning facilities > ------------------------------------------------ > > Key: DERBY-4520 > URL: https://issues.apache.org/jira/browse/DERBY-4520 > Project: Derby > Issue Type: Improvement > Components: Store > Affects Versions: 10.6.0.0 > Reporter: Kristian Waagan > Assignee: Kristian Waagan > Attachments: derby-4520-1a-RowLocation_cloning.diff, derby-4520-1a-RowLocation_cloning.diff, derby-4520-2a-remove_CloneableObject_iface.diff, derby-4520-2a-remove_CloneableObject_iface.stat > > > With the increased use of streams to represent data values, the cloning facilities needs to be improved. > Unless I get pushback, I will proceed by producing patches to reach the following goals: > - move the functionality provided by CloneableObject into DataValueDescriptor > (all classes implementing CloneableObject also implements DataValueDescriptor) > - introduce the cloning methods cloneValue, cloneState and cloneHolder (all in DataValueDescriptor, see description below) > Note that they all return a usable DVD. I'm all ears for better names for the clone methods (another suggestion mentioned is cloneDeep, cloneHalfDeep, and cloneShallow). > cloneValue (new method, functionality was present through combined calls to the DVD public interface) > - a DVD obtained through cloneValue is independent of other DVDs and the state of the Derby store > - the data value will be materialized > cloneState (~= DataValueDescriptor.getClone) > - a DVD obtained through cloneState is independent of other DVDs, but may depend on the state of the Derby store (due to references to store streams) > - the data value will be materialized if the value is represented by a non-cloneable stream or if Derby believes materializing the value is more appropriate than keeping the stream representation > cloneHolder (~= CloneableObject.cloneObject) > - a DVD obtained through cloneHolder is dependent on the original DVD and its clones made through cloneHolder. If one of the DVDs changes its state, all of them will be affected. Will also be dependent on the state of the Derby store if there are references to store streams. > - the data value will never be materialized due to cloneHolder being invoked > For many of the data types, cloneState and cloneHolder will forward to cloneValue. > cloneState will be used the most. cloneValue is currently only required in the sorter. cloneHolder is required (for performance reasons and maybe to avoid OOME) when DVDs pass through temporary holders (BackingStoreHashtable, TemporaryRowHolderImpl). I have not gone through all the usages of cloneState to see if any of them can be, or has to be, replaced with another clone-call. > The ability to clone store streams will be added by Mike's patch attached to DERBY-3650. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.