I have a dilemma deciding on the structure on persiting data.  I need your advice on.  <br><br>I'm relying on a third party package (Amazon-ECS) that helps me parse Amazon XML data feed, with the result that the XML is translated into a set of nested CLOS objects (all classes use metaclass ELEMENT-CLASS).   The XML documents are represented by a root object, and there subparts of the XML by the nested objects accessible via root object slots, and so on recursively.   It's actually a small tree structure of various types of objecs at each level.   The data within this structure is valuable for current and future needs for the project and I would like to cache it instead of fetching from Amazon (there is a limit on how much you can fetch at one time, plus the volume would make it prohitive). <br>
<br>For the purpose of the application, currently I only need a small subset of the data.   As a solution I thought that perhaps can I just create a facade object that will contain the basic data slots I need plus an OBJECT-REFERENCE field that refers to XMLRoot (and the objects hidden within)?  When this facade object is persisted, will the entire XMLRoot with its descendends (objects refering to objects either through slots or lists in slots) be persisted?  That is, when an object is serialized, is the serialization recursive?<br>
<br>The second option is to build a set of persistend mirror objects for the XML objects I get and copy the data onto it.  This probably can be automated somehow.  <br><br>The third option is to modify the package Amazon ECS parsing package to use persistent objects by default.  It's problematic, because now I will effectively create a branch of the package and maintain it separately from the core.  I would not want to persist all of the classes, so I would have to be selective - it isn't simply making Amazon-ECS' ELEMENT-CLASS an Elephant's PERSISTENT-CLASS.<br>
<br>Any clarifications and advice would be much appreciated.<br><br>Thanks,<br><br>Yarek<br><br>