On Thu, 17 Apr 2008, Tobias Schlitt wrote: > 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: > > >>> 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.
Let's add an issue for this, so that we don't forget about it. regards, Derick -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
