You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2010/01/20 14:18:54 UTC
[jira] Created: (DERBY-4520) Refactor and extend data type cloning
facilities
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
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.
unsubscribing from an Apache list,
was: [jira] Commented: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Srinivasa,
Instructions for unsubscribing from an Apache list can be found here:
http://www.apache.org/foundation/mailinglists.html
Hope this helps,
-Rick
SrinivasaRao.Nalleboyina@cognizant.com wrote:
> Hi All,
>
> Could you please unsubscribe from the list or let me know what are all steps to be followed for unsubscribe.
>
> -----Original Message-----
> From: Kristian Waagan (JIRA) [mailto:jira@apache.org]
> Sent: Monday, January 25, 2010 4:20 PM
> To: derby-dev@db.apache.org
> Subject: [jira] Commented: (DERBY-4520) Refactor and extend data type cloning facilities
>
>
> [ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804499#action_12804499 ]
>
> Kristian Waagan commented on DERBY-4520:
> ----------------------------------------
>
> I wonder if we should just remove the same asserts for init-, close- and resetStream in FormatIdInputStream as well?
>
>
>> 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
>>
>>
>> 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.
>>
>
>
RE: [jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by Sr...@cognizant.com.
Hi All,
Could you please unsubscribe from the list or let me know what are all steps to be followed for unsubscribe.
-----Original Message-----
From: Kristian Waagan (JIRA) [mailto:jira@apache.org]
Sent: Monday, January 25, 2010 4:20 PM
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4520) Refactor and extend data type cloning facilities
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804499#action_12804499 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
I wonder if we should just remove the same asserts for init-, close- and resetStream in FormatIdInputStream as well?
> 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
>
>
> 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.
This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful.
[jira] Closed: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan closed DERBY-4520.
----------------------------------
Resolution: Fixed
Fix Version/s: 10.6.0.0
Closing issue, related / additional work will be done in separate Jiras.
> 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
> Fix For: 10.6.0.0
>
> 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, derby-4520-6a-unused_imports.diff, derby-4520-7a-lob_clonevalue_methods.diff, derby-4520-7b-lob_clonevalue_methods.diff
>
>
> 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).
> NOTE: See comment below, the method names changed during the course of development.
> 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.
> * New method names:
> It turned out that using only two methods was sufficient:
> cloneHolder <shallow> (as above)
> cloneValue(boolean forceMaterialization) <halfDeep or deep>
> Basically, cloneValue(false) equals cloneState() above, and cloneValue(true) equals cloneValue() above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-4520:
-----------------------------------
Issue & fix info: (was: [Patch Available])
Thanks for having a look at the patch, Knut Anders.
Committed patch 1a to trunk with revision 901642.
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803716#action_12803716 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
Knut> [confusing comment] Does "We still do" mean that we still materialize the stream, or that we still do not materialize the stream?
It means we still don't materialize. However, I might change the way the stream is cloned (using the terms in the issue description, either cloneState or cloneHolder).
I will clarify the comment in a later patch.
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-1a-RowLocation_cloning.diff
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804547#action_12804547 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
FYI, I've seen the following stream classes passed in to FormatIdInputStream (this list may not be exhaustive):
java.io.ByteArrayInputStream
org.apache.derby.iapi.services.io.ArrayInputStream
org.apache.derby.iapi.services.io.LimitInputStream
org.apache.derby.iapi.types.RawToBinaryFormatStream
org.apache.derby.iapi.types.ReaderToUTF8Stream
org.apache.derby.impl.store.raw.data.OverflowInputStream
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-4520:
-----------------------------------
Issue & fix info: (was: [Patch Available])
> 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, derby-4520-6a-unused_imports.diff, derby-4520-7a-lob_clonevalue_methods.diff, derby-4520-7b-lob_clonevalue_methods.diff
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804499#action_12804499 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
I wonder if we should just remove the same asserts for init-, close- and resetStream in FormatIdInputStream as well?
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-4520:
-----------------------------------
Issue & fix info: [Patch Available]
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-2a-remove_CloneableObject_iface.stat
derby-4520-2a-remove_CloneableObject_iface.diff
Patch 2a removes the interface CloneableObject.
I moved the method cloneObject into DataValueDescriptor, and plan to rename it (or maybe merge it with another clone-method). Note that the method now returns a DataValueDescriptor, not an Object.
Updated some comments and removed some unused imports.
Regression tests passed.
Patch ready for review.
> 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 <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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-4520:
-----------------------------------
Description:
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).
NOTE: See comment below, the method names changed during the course of development.
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.
* New method names:
It turned out that using only two methods was sufficient:
cloneHolder <shallow> (as above)
cloneValue(boolean forceMaterialization) <halfDeep or deep>
Basically, cloneValue(false) equals cloneState() above, and cloneValue(true) equals cloneValue() above.
was:
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.
Changed issue description to mention the resulting two methods (instead of three).
Also, I'm not sure if more work needs to be done under this issue, but I'll keep it open for while.
> 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, derby-4520-6a-unused_imports.diff, derby-4520-7a-lob_clonevalue_methods.diff, derby-4520-7b-lob_clonevalue_methods.diff
>
>
> 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).
> NOTE: See comment below, the method names changed during the course of development.
> 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.
> * New method names:
> It turned out that using only two methods was sufficient:
> cloneHolder <shallow> (as above)
> cloneValue(boolean forceMaterialization) <halfDeep or deep>
> Basically, cloneValue(false) equals cloneState() above, and cloneValue(true) equals cloneValue() above.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-7a-lob_clonevalue_methods.diff
Patch 7a changes the cloneValue methods for SQLBlob and SQLClob.
The general idea for the character and binary values is that all streams are materialized when cloning the value, expect for BLOB and CLOB.
Note that BasicSortObserver is now forcing materialization of streams. This is how it used to be (before patch 5a), but I think this may cause problems for a few types of queries - for instance 'select * from mytable order by length(myClob)'. This will have to be addressed under a different Jira.
Also note that there are a few TODOs in the clone methods. I'd appreciate feedback on any of these if you have something on your mind.
Regression tests passed (re-running as well to be sure).
Patch ready for review.
> 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, derby-4520-6a-unused_imports.diff, derby-4520-7a-lob_clonevalue_methods.diff
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12802857#action_12802857 ]
Knut Anders Hatlen commented on DERBY-4520:
-------------------------------------------
Patch 1a looks like a good improvement to me.
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803696#action_12803696 ]
Knut Anders Hatlen commented on DERBY-4520:
-------------------------------------------
Patch 2a looks good to me. I found one of the comments a little unclear, though:
+ // History: We used to *not* materialize streams when getting a clone
+ // here (i.e. used cloneObject, not getClone). We still do.
+ // DERBY-802
Does "We still do" mean that we still materialize the stream, or that we still do not materialize the 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 <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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-4520:
-----------------------------------
Issue & fix info: [Patch Available]
> 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 <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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804525#action_12804525 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
Removed unhelpful asserts, and added @see tags to copy JavaDoc from the interfaces, with revision 902798.
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-7b-lob_clonevalue_methods.diff
Attached patch 7b, which corrects two typos (BLOB -> CLOB) and adds a shortcut for cloning NULLs.
The shortcut feels better, because using the fall-back case (calling clone.setValue(getBytes()) results in the two DVDs referencing the same byte array for BLOBs.
I have decided to create a separate Jira for CollatorSQLClob, see DERBY-4542.
Committed to trunk with revision 907732.
> 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, derby-4520-6a-unused_imports.diff, derby-4520-7a-lob_clonevalue_methods.diff, derby-4520-7b-lob_clonevalue_methods.diff
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829733#action_12829733 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
I need to provide a new revision of patch 7, as I forgot to modify CollatorSQLClob. As it stands now, these CLOB values will always be materialized. I guess we don't have any tests for large collator CLOBs running in VMs with a small heap...
> 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, derby-4520-6a-unused_imports.diff, derby-4520-7a-lob_clonevalue_methods.diff
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805127#action_12805127 ]
Dag H. Wanvik commented on DERBY-4520:
--------------------------------------
Patch 4a looks good to me.
The issue description puzzled me in the explanatiion of cloneHolder
<shallow>":
:
- 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.
But for cloneValue you say: "- the data value will be materialized",
so presumablu the sentence above should read:
- for streams, the data value will never be materialized due to
cloneHolder being invoked
or some such?
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-3b-CloneableStream_and_delayed_fill.diff
derby-4520-3b-CloneableStream_and_delayed_fill.stat
Thanks for the suggestions, Knut Anders.
Moving the interface definitely makes sense.
I also removed the call to fillByteBuffer in OverflowInputStream.resetStream and ran the regression tests. No tests failed.
I had a look at the code using the resetStream method, and I think the only thing we change is that any exceptions raised by fillByteBuffer will occur in an InputStream-call instead of in resetStream. In most cases the resetStream is called first, followed by a call to either read or skip.
I don't think this last change will have any effect on performance, but it is better to keep the behavior consistent across the different methods.
I incorporated both changes into patch 3b, and committed it to trunk with revision 902742.
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-1a-RowLocation_cloning.diff
Patch 1a removes the use of CloneableObject.cloneObject for RowLocation because it isn't needed. DataValueDescriptor.getClone is used instead.
There is an assert in MergeSort (line 462), checking if the objects implement CloneableObject. HeapRowLocation extends DataType, which implements CloneableObject. The assert will be removed in a follow-up patch, together with CloneableObject itself.
I rewrote the assert code in BaseActivation to avoid creating two clones of the row location in sane builds.
I plan to commit this patch very soon, after I have once more run the regression tests.
After these changes, there are just a few usages of CloneableObject.cloneObject left. The method will be moved into DataValueDescriptor.
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804482#action_12804482 ]
Knut Anders Hatlen commented on DERBY-4520:
-------------------------------------------
Thanks for making these changes, Kristian. One nit that I missed the last time:
+ public InputStream cloneStream() {
+ if (SanityManager.DEBUG)
+ SanityManager.ASSERT(in instanceof CloneableStream);
+ InputStream new_input_stream = ((CloneableStream) in).cloneStream();
Here, the ASSERT is actually making debugging harder, so I think it's better to remove it. The only thing we will see in debug builds is "assert failed", whereas non-debug builds will show the more helpful message "ClassCastException: SomeStreamClass cannot be cast to CloneableStream".
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805191#action_12805191 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
Hi Dag,
Yes, you are right - this is all about streams :) I'll edit the description in a little while (just want to wait for another potential change).
Regarding the non-stream values, I think it is still correct to say they will be materialized by cloneValue. I haven't verified this for all data types, but for instance SQLDecimal will transform the value from a byte array (all in memory) to a BigDecimal-object when cloning. If the value is already a BigDecimal, it is shared between the original and the clone (which is fine, BigDecimal is immutable).
When it comes to the methods from the description, I'm considering merging cloneState and cloneValue into cloneValue(boolean forceMaterialization): false will equal cloneState, true will equal the cloneValue-method from the issue description.
Running the regression tests with getClone changed to cloneValue(true) was successful.
Changing all these to cloneValue(false) resulted in a total of 21 (four distinct error messages) test failures in the following tests:
org.apache.derbyTesting.functionTests.tests.jdbc4.LobSortTest
org.apache.derbyTesting.functionTests.tests.lang.TriggerTest
org.apache.derbyTesting.functionTests.tests.store.StreamingColumnTest
org.apache.derbyTesting.functionTests.tests.tools.ImportExportLobTest
I don't know yet if the streams causing these errors are coming from the store or from triggers, procedures or the user - I'll look into this.
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803725#action_12803725 ]
Knut Anders Hatlen commented on DERBY-4520:
-------------------------------------------
Patch 3a looks fine, as far as I can tell. A couple of questions:
- Would it be better to place CloneableStream in iapi.services.io instead of iapi.types?
- Do you think it would also make sense to remove the call to fillByteHolder() from OverflowInputStream.resetStream(), based on the same reasoning that led to its removal from OverflowInputStream's constructor?
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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 <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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-4a-cloneObject_renamed_cloneHolder.diff
Attached patch 4a, a small patch renaming cloneObject to cloneHolder and modifying a few comments.
Patch ready for review.
I hope to commit this tomorrow. Running tests again now due to a last minute change.
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804500#action_12804500 ]
Knut Anders Hatlen commented on DERBY-4520:
-------------------------------------------
Yes, +1 to removing them from FormatIdInputStream too.
> 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
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804960#action_12804960 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
Committed patch 4a to trunk with revision 903150.
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-3a-CloneableStream_and_delayed_fill.stat
derby-4520-3a-CloneableStream_and_delayed_fill.diff
Attached patch 3a, which does the following:
- adds the required code for cloning store streams
- modified OverflowInputStream to fill the byte array on the first read instead of at construction/initialization time, which also allowed me to remove some throws-clauses
The delayed buffer filling should reduce the penalty in cases where we clone and the user never actually access the value. I had to fix the broken/inaccurate error reporting in OverflowInputStream.fillByteHolder to make the regression tests pass. The cause for the failures was that the error got reported in a different way because the real exception got lost.
Most of the code is from Mike's patch, but I did make some changes. Also note that I haven't included any of the real fixes from derby-3650-preliminary_2_diff.txt (see DERBY-3650).
Patch ready for review.
The next step is to introduce and/or modify the various clone methods we need in DataValueDescriptor, wiring in the stream cloning where appropriate.
> 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
>
>
> 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.
[jira] Updated: (DERBY-4520) Refactor and extend data type cloning
facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ 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-6a-unused_imports.diff
I factored out the removal of unused imports in the data type sub-trees starting with SQLBinary and SQLChar (which are the most relevant ones regarding the cloning).
Attached as patch 6a and committed to trunk with revision 906609.
> 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, derby-4520-6a-unused_imports.diff
>
>
> 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.
[jira] Commented: (DERBY-4520) Refactor and extend data type
cloning facilities
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829683#action_12829683 ]
Kristian Waagan commented on DERBY-4520:
----------------------------------------
Committed patch 5a to trunk with revision 906595.
I'll incorporate any feedback in a later patch.
> 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.