db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4520) Refactor and extend data type cloning facilities
Date Thu, 04 Feb 2010 11:16:27 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kristian Waagan updated DERBY-4520:
-----------------------------------

    Attachment: derby-4520-5a-getClone_renamed_cloneValue.stat
                derby-4520-5a-getClone_renamed_cloneValue.diff

Attached patch 5a, which main purposes are to rename getClone to cloneValue and to add the
boolean argument 'forceMaterialization'.

Regarding the methods mentioned in the issue description, 'cloneValue(true)' equals 'cloneValue'
and 'cloneValue(false)' equals 'cloneState'.
The default value of 'forceMaterialization' has been set to false. I'm aware of one location
where it has to be switched to true (BasicSortObserver). Note that I have not yet changed
the methods to actually use the new variable, and further that many types won't care about
its value because they are in a way always materialized (i.e. the value is a primitive, or
represented by an immutable object).

Besides from formatting changes and the renaming, I made a few other changes as well:
* GenericParameter
Removed a bunch of unused imports (iapi.types.* was imported trice).

* ValueRow
Removed special handling of RowLocation in 'getNewNullRow'.

* SQLSmallInt, SQLTinyInt
Made constructor used for cloning only private.

* XML
Added argument in contructor used for cloning to tell whether the underlying source should
be materialized or not.

Regression tests passed.
Patch ready for review.

NOTE: Some of our clone methods are unsafe in the sense that it is possible to change a value
which is shared between two or more holders (DVDs). One such example is values represented
by a byte array.


> 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,
derby-4520-3a-CloneableStream_and_delayed_fill.diff, derby-4520-3a-CloneableStream_and_delayed_fill.stat,
derby-4520-3b-CloneableStream_and_delayed_fill.diff, derby-4520-3b-CloneableStream_and_delayed_fill.stat,
derby-4520-4a-cloneObject_renamed_cloneHolder.diff, derby-4520-5a-getClone_renamed_cloneValue.diff,
derby-4520-5a-getClone_renamed_cloneValue.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 <deep> (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 <halfDeep> (~= 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 <shallow> (~= 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.


Mime
View raw message