Hi again! On 04/17/2008 09:37 AM Tobias Schlitt wrote:
> On 04/16/2008 08:53 PM Derick Rethans wrote: >> On Wed, 16 Apr 2008, Tobias Schlitt wrote: >>> On 04/16/2008 08:05 PM Derick Rethans wrote: >>>> On Mon, 14 Apr 2008, Tobias Schlitt wrote: >>>>> On 04/07/2008 09:25 PM Tobias Schlitt wrote: >>>>> It needs to be clearified, if restored items should be bubbled up >>>>> to higher storages. >>>> Why wouldn't we want that? >>> Because it costs time again. Imagine a 4 level stack, where file system >>> is the lowest and largest one. Each time an item would be restored from >>> the there, it would be placed in 3 higher storages again. Not sure if we >>> want this, since it slows down the read process. >> I think this is one of the major things why you'd want a stacked >> cache... so yes, I definitely think it should be stored in higher >> storages. Perhaps we can add an option to restore() to *not* do that, >> but I do want the general case to store it in the higher caches. > I think the parameter for restore() idea is not good. Let's better add > an option to the stack to determine this. I'll add this to the design > and will think about it some more, if it could not make any problems. I just added the desired option. However, there is a proble with the attributes of an item: Storage objects do not support to retrieve the attributes stored for an item (yet). Some storages even cannot support this in their current state. Therefore, an item would only be stored in upper stack levels with the attributes that have been used for restoring it instead of all attributes. Regards, Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
