[
https://issues.apache.org/jira/browse/FLINK-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070254#comment-14070254
]
ASF GitHub Bot commented on FLINK-987:
--------------------------------------
Github user uce commented on a diff in the pull request:
https://github.com/apache/incubator-flink/pull/77#discussion_r15227435
--- Diff:
flink-core/src/main/java/org/apache/flink/core/memory/DataOutputView.java ---
@@ -51,4 +55,38 @@
* could not be read, or the output could not be
written.
*/
public void write(DataInputView source, int numBytes) throws
IOException;
+
+ /**
+ * Tells the view to keep the underlying buffers (if any) and allow
calling of {@link #seek(long)} and {@link
+ * #tell()}.
+ */
+ public void lock();
+
+ /**
+ * Tells the system to spill all underlying buffers (if any). Data
written after the current writing position might
--- End diff --
I think `spill` might be confusing in this context? In my head `memory +
spill = go to disk`. :laughing:
> Extend TypeSerializers and -Comparators to work directly on Memory Segments
> ---------------------------------------------------------------------------
>
> Key: FLINK-987
> URL: https://issues.apache.org/jira/browse/FLINK-987
> Project: Flink
> Issue Type: Improvement
> Components: Local Runtime
> Affects Versions: 0.6-incubating
> Reporter: Stephan Ewen
> Assignee: Aljoscha Krettek
> Fix For: 0.6-incubating
>
>
> As per discussion with [~till.rohrmann], [~uce], [~aljoscha], we suggest to
> change the way that the TypeSerialzers/Comparators and
> DataInputViews/DataOutputViews work.
> The goal is to allow more flexibility in the construction on the binary
> representation of data types, and to allow partial deserialization of
> individual fields. Both is currently prohibited by the fact that the
> abstraction of the memory (into which the data goes) is a stream abstraction
> ({{DataInputView}}, {{DataOutputView}}).
> An idea is to offer a random-access buffer like view for construction and
> random-access deserialization, as well as various methods to copy elements in
> a binary fashion between such buffers and streams.
> A possible set of methods for the {{TypeSerializer}} could be:
> {code}
> long serialize(T record, TargetBuffer buffer);
>
> T deserialize(T reuse, SourceBuffer source);
>
> void ensureBufferSufficientlyFilled(SourceBuffer source);
>
> <X> X deserializeField(X reuse, int logicalPos, SourceBuffer buffer);
>
> int getOffsetForField(int logicalPos, int offset, SourceBuffer buffer);
>
> void copy(DataInputView in, TargetBuffer buffer);
>
> void copy(SourceBuffer buffer,, DataOutputView out);
>
> void copy(DataInputView source, DataOutputView target);
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
