[elephant-devel] Design Suggestion Request

[Daniel Salama]

That's an excellent idea. I wasn't aware there's a blog for Elephant.  
Is there one?

Thanks,
Daniel

On Jul 27, 2006, at 3:14 PM, Ben wrote:

> i wonder if these sorts of design issues for elephant newbies might be
> laid out in a document or tutorial.  perhaps the "blog in a minute"
> tutorial can be updated to reflect your more mature codebase and
> mature approaches to designing applications?  or a design faq?
>
> just an idea,
> Ben
>
> On 7/27/06, Ian Eslick <eslick at csail.mit.edu> wrote:
>> 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.
>> >
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel