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 <[EMAIL PROTECTED]> 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@common-lisp.net >>> http://common-lisp.net/mailman/listinfo/elephant-devel >>> >> _______________________________________________ >> elephant-devel site list >> elephant-devel@common-lisp.net >> http://common-lisp.net/mailman/listinfo/elephant-devel > _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
