[
https://issues.apache.org/jira/browse/DERBY-4563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4563:
-----------------------------------
Attachment: derby-4563-1b-dvd_hasStream.diff
Thanks for reviewing the patch, Dag.
I decided to remove the unclear comment for now, as I realized it isn't
entirely clear how this will play out yet. I do plan to revisit the issue (at
latest when optimizing the cloneValue methods for BLOB/CLOB).
I'm also having some doubts about the call to hasStream in getStream /
getStreamWithDescriptor, and I did consider simply changing the implementation
to do just 'stream != null'. Again, I'll have to revisit this when / if more
substantial logic is added to the hasStream-method.
Committed the newly attached patch 1b to trunk with revision 916261.
I will post another patch shortly, replacing the use of StreamStorable in the
JDBC-layer.
> Avoid unnecessary use of getStream and getStreamWithDescriptor
> --------------------------------------------------------------
>
> Key: DERBY-4563
> URL: https://issues.apache.org/jira/browse/DERBY-4563
> Project: Derby
> Issue Type: Improvement
> Components: JDBC
> Affects Versions: 10.6.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.6.0.0
>
> Attachments: derby-4563-1a-dvd_hasStream.diff,
> derby-4563-1a-dvd_hasStream.stat, derby-4563-1b-dvd_hasStream.diff
>
>
> A pattern in Derby is to use the following piece of code to determine if the
> data value has a stream or not:
> if (dvd.getStream() != null) ...
> Since the stream has mutable state, obtaining a reference to it just to check
> if it is not null is sub-optimal for several reasons:
> - it may throw an exception (data types not supporting streams)
> - the stream reference is leaked, which is unfortunately if we are / will be
> required to guarantee something about the stream state (for instance that the
> descriptor is in sync with the stream).
> - in cases where we have to investigate the state of the stream, we're doing
> unnecessary work
> - makes it harder to write debug code (i.e., is a stream reference obtained
> from the data value descriptor more than once?)
> I plan to introduce the method DataValueDescriptor.hasStream, returning a
> boolean.
> In addition to the obvious check if the stream variable is non-null, it can
> also be used to instruct Derby to treat certain data values as non-streams
> even though the underlying value is currently a stream. One example is CHAR
> and VARCHAR, whose maximum lengths are so small that they should always be
> materialized to avoid the added complexity coming with streams (stream state,
> isolation levels - extra lock to keep stream stable?, cloning).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
