<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-B683496C-652E-5F48-924E-52D2FF3A78A7" xml:lang="en"><title>Direct

File Store</title><shortdesc>The main characteristic of a direct file store is that streams

can be created and objects externalized to them but, once the streams have

been committed and closed, they cannot subsequently be changed.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>Once the streams have been committed and closed, they cannot be replaced,

deleted, extended or changed in any way. A direct file store is useful for

the type of application which treats the in-memory copy of its data as its

prime copy, such as a word processor which implements the classic load/save

paradigm. In this paradigm:</p>

<ul>

<li id="GUID-DE651688-71D8-5E52-BA3A-D3ED93B58F55"><p>application data is

first created, in an internal, non-persistent, form — i.e., in RAM</p> </li>

<li id="GUID-F6012000-CE82-5940-9CEB-386664FF0EA5"><p>when the file is first

saved, the data is externalised to the file store. When saving its data, an

application writes the whole object network forming the data to a new direct

file store, replacing any existing file of the same name. The last stream

written is always the root stream.</p> </li>

<li id="GUID-9896F0DD-1D96-5EC7-959F-D3C7EB226BD6"><p>the application can

exit</p> </li>

<li id="GUID-27B6B647-FA91-52BF-855C-2F6CE31AB0E6"><p>when the application

is started again, it can open the file store and read in the persistent data.

It need not load the whole object network into memory; the loading of objects

can be deferred by using Swizzles. </p> </li>

<li id="GUID-1BF73B14-8CB1-57B3-A687-7C76B5100C9E"><p>the data is edited in

its internal, non-persistent form</p> </li>

<li id="GUID-8FFA6658-0753-5601-979A-2833AD415691"><p>when data is saved again,

the old file is erased (or renamed for safety!) and completely rewritten</p> </li>

</ul>

<p>With a direct file store, a stream may not be appended once it has been

written and closed. Writing to different streams may not be interleaved. The

root stream must be the last stream to be written. The direct file store is

very efficient as the allocation of new streams, and finding existing streams,

are trivially mapped onto the most efficient operations of the underlying

file system.</p>

<p>For this type of application, the most efficient file format is obtained

when all the data is written in sequence to the file. Any references within

the file are to data which was written earlier. When reading the file back,

it is read in several sections starting with a section that is at the <i>end</i> of

the file.</p>

<p>A typical relationship between a direct file store and its contained streams

is shown below. In this stream network streams <i>I</i> and <i>J</i> must

be written before stream <i>A</i>; stream <i>K</i> must be written before

stream <i>C</i>; streams <i>A</i>,<i>B</i> and <i>C</i> must be written before

the root stream.</p>

<fig id="GUID-D45A96E3-5900-5817-8B32-8AA74E3DE584">

<title>Streams linked in a store</title>

<image href="GUID-DE5FC074-75C1-5833-83B2-D25396F52732_d0e581278_href.png" placement="inline"/>

</fig>

<p>Direct file stores are encapsulated by the <codeph>CDirectFileStore</codeph> class. </p>

</conbody><related-links>

<link href="GUID-D7211372-9411-5A18-88F0-615F4983A2E0.dita"><linktext>Store Streams</linktext>

</link>

</related-links></concept>