[elephant-devel] Design Suggestion Request

[Ian Eslick]

I think there was a tutorial that included a simple design for a
persistent logging system and queries against it.
Should be in examples/index-tutorial.lisp.

There's a nice wiki example for UCW that could easily be adapted to show
off elephant - and a few of our users, including me, use elephant as a
data backend for a UCW front end.  UCW is a bit much for a general
tutorial though.

I think a blog backend to portable aserve would make for a nice example
along with a discussion of tradeoffs.  Of course someone would need to
volunteer for such a thing.  It will be a little while before I can do
more than small support sessions or bug fixes for elephant...  :)

Ian

Daniel Salama wrote:
> 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
>