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
