[elephant-devel] Design Suggestion Request

[Ben]

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
>