<concept xml:lang="en" id="GUID-3ABE9420-2668-507E-B857-E62DC50654BD"><title>Storing and restoring</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>An object in its internal form may consist of just simple data types, for example, a <codeph>TPoint</codeph>, which just has two <codeph>TInt</codeph> values representing its X and Y co-ordinates, or a network of objects, for example, a <codeph>CBufSeg</codeph>. There are two ways of storing the external form of the object:</p> <ul><li id="GUID-38BD713B-FD26-53E5-8C9B-982F286A1BCC"><p> externalising it as part of a stream </p> </li> <li id="GUID-52840A22-541D-5CC0-BE55-F572CC292120"><p>storing it as an entire stream network in a store. </p> </li> </ul> <p>When externalizing an object to a stream, the stream is passed to the the <codeph>ExternalizeL()</codeph> function and, in general, an object has no knowledge of where, in the stream, the data is written.</p> <p>When a whole network of objects is to be externalised it is useful to <i>store</i> an object in its own stream network. This is particularly important if other objects are to be restored without restoring this one. The main reason is that it is very difficult to read past an object's data in a single stream without knowing something about its internal form.</p> <section><title>What to store?</title> <p>You should store an object which you might not wish to load along with its containing object. The following are typical situations where storing is used:</p> <ul><li id="GUID-EC0FC73C-F820-5255-B3B9-06282F58897E"><p>when objects are stored in a database, such as a relational database, various indexes to the database are accessed, but not every object is loaded into RAM when the database is opened.</p> </li> <li id="GUID-3EC34AF1-053F-5EE9-B655-925720527510"><p>embedded objects in documents. An object represented by an iconic door is not loaded until that door is opened; an object represented by a glass door may not be loaded until the glass door is required to be displayed.</p> </li> <li id="GUID-EAC3CD9F-0592-5036-97E9-31A718FD9F86"><p>when there is additional information to allow various levels of access to complex data streams. For example, rich text. The text is stored in one stream, but the formatting information is stored in other streams; this enables global text or even plain text to be read without the details of the rich text formatting interfering with the process.</p> </li> <li id="GUID-7077058B-007F-5CFC-AB8B-0AAD68ED1C5D"><p>when there is additional information for later versions of a program. Additional version-2 information can be stored in a separate stream; then, a version-1 program working on the same store will load only the version-1 information, but the version-2 program will load both.</p> </li> </ul> <p>In general, the decision to <i>store</i> rather than <i>externalise</i> is a fundamental characteristic of the object, and should be taken with care. A compound object, which contains stored component objects, must obey store-related protocols which are more complex than the simple stream-related <codeph>ExternalizeL()</codeph> and <codeph>InternalizeL()</codeph>. The decisions already taken by system components, such as rich text, and by the application architecture, influence the kinds of things you store in your own applications.</p> </section> </conbody></concept>