[elephant-devel] Design Suggestion Request

[Ian Eslick]

All,

I think the long term goal is to make read/write policy something that
is integrated into a per-class policy with per-instance state.  Robert,
have you forwarded that discussion we had about DCM to the list?  If so
it should be in the archives from several months back.  The short story
is that you want to have different policies with different amounts of
explicit control based on your problem.

For small DB's where ACID properties aren't important - just keep
everything in memory as if Elephant wasn't there.  If you want to save
something - just tell the object to store itself to get the benefits of
auto serialization.

For larger DB's you might want a tiered approach:
- Critical new objects have read-from-memory but write-through-to-disk
for fast reads but safe writes
- Non-critical new objects are read/write from memory unless explicitly
checkpointed
- Critical objects that aren't new are read/write from disk (existing
Elephant default) so you don't overwhelm
your physical memory

Rucksack has some of the same features as DCM, but is not yet ready for
real deployment (since I last looked a few months back).

The 0.6.0 manual should have a section on indexing and the function
reference should have get-instances-by-class (an elephant function in
elephant/classindex.lisp).  defpclass may not be documented but is just
shorthand for adding the :metaclass class option.  Just M-. defpclass
with elephant loaded.  In fact the doc strings are available for all
these if you do M-. via Slime when the elephant package is loaded.

The select-if is a function I use locally that just accepts each element
of the list accepted by the predicate, it's not a part of elephant.

I'm not sure when we'll get to adding new major features but if someone
would like to dive in and think about this I'm happy to answer questions
about the rationale behind the code.

Ian

Daniel Salama wrote:
> Granded. Now, your original suggestion addressed the issue of using
> collections in slots and instead of collections of objects, simply to
> use collections of references to objects, which make sense and in a
> way is somewhat along the lines of what indexes do (from a general PoV).
>
> Not having looked at DCM yet, is it possible to just use the
> "persistence machinery" and DCM in a more seamless fashion? For
> example, if I declare a persistent CLOS class, can I hook that up to
> DCM and get the benefits of DCM and persistence at the same time? From
> Ian's last statement, this doesn't seem possible yet, but I may be wrong.
>
> Thanks,
> Daniel
>
> On Jul 27, 2006, at 2:07 PM, Robert L. Read wrote:
>
>> A reasonable way to work is to use completely persistent objects and
>> see how the performance 
>> is for you --- LISP and elephant support this kind of rapid
>> prototyping extremely well.  I may be 
>> a bit old-fashioned---but I often find that I end up having to take
>> explicit control of the write-back
>> policy in any case, and I personally never find having to remember
>> when to write things a burden,
>> since they are almost always part of a "business rule", if your using
>> a 3-tiered application.
>>
>> On the other hand, you can follow your plan based on Ian's idea, and
>> similar layer on secondary 
>> indexes once prototyping shows that you need them.
>