Support incremental reading and writing

[GoogleCodeExporter]

I am currently working on a program which needs to work with very large YAML 
files (too large for loading the entire file at once to be practical). The 
files consist of a very long top level list, of which I will only be working 
with one item at a time.

Writing support would be most important for me, and it seems like it probably 
wouldn't be too difficult, as YAML::Emitter would just need to output to a file 
instead of an internal buffer.

Reading support would also be nice, with yaml-cpp reading one list entry at a 
time and returning a YAML::Node.

Thanks.

Original issue reported on code.google.com by rkj...@gmail.com on 14 May 2012 at 10:31

• Merged into: #148

[GoogleCodeExporter]

I agree, the emitter ought to be able to write to an std::ostream as well.

As for reading one entry at a time, see Issue 148. The question there is to 
only read one document at a time, which is probably the behavior you're looking 
for.

YAML naturally provides breaks in its stream, which is intended for exactly 
this problem. I'd recommend, instead of having a top-level list, having lots of 
documents instead. E.g.,

---
key: value
---
key: something else
---
other key: value

You can also separate with "..." (the document ending token) instead of "---" 
(the document start token).

I don't think yaml-cpp will ever offer reading one list entry at a time, but it 
will (I hope) offer reading one document at a time, and leaving the rest of the 
stream intact.

Original comment by jbe...@gmail.com on 14 May 2012 at 11:06

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by jbe...@gmail.com on 19 May 2012 at 9:09

• Added labels: Component-Core

[GoogleCodeExporter]

The emitter now has a constructor that accepts a std::ostream, so you can 
manage the stream yourself, if you like.

This is the extent that I'll do on this issue (as I said, the incremental 
reading, one list entry at a time, means that you should probably use multiple 
documents). For that, I'm now marking this as a duplicate of Issue 148.

Original comment by jbe...@gmail.com on 27 May 2012 at 7:14

• Changed state: Duplicate