From maxigas at anargeek.net Sun May 9 05:06:26 2010 From: maxigas at anargeek.net (maxigas) Date: Sun, 09 May 2010 06:06:26 +0100 (BST) Subject: [elephant-devel] Berkeley DB error: Invalid argument Message-ID: <20100509.060626.833503636937433487.maxigas@anargeek.net> hi! I tried to use the FAQ [1] with the latest SBCL, BDB and Elephant, but open-store fails on Berkeley databases. I did recompile BerkeleyDB 4.7 after applying the patches advised but the magic line for setting the architecture failed: This line from the FAQ: CCFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" ../dist/configure Threw this error: configure: error: C compiler cannot create executables I looked up "man cc" but the "-arch" option is only documented to work under Darwin. uname -a returns: Linux chaar 2.6.31-9-rt #152-Ubuntu SMP PREEMPT RT Thu Oct 15 13:22:24 UTC 2009 x86_64 GNU/Linux So I am using Ubuntu Karmic Koala with amd64 architecture and a preemptive kernel. My guess is that the compilation was OK and there is another problem. Should I create something like a database before I try open-store or it is enough to have an open and writable directory? [1] http://common-lisp.net/project/elephant/faq10a2.html ----8k----{cut here}----8k---- Berkeley DB error: Invalid argument [Condition of type BDB-DB-ERROR] Restarts: 0: [RETRY] Retry SLIME interactive evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [TERMINATE-THREAD] Terminate this thread (#) Backtrace: 0: (DB-BDB::DB-ENV-SET-FLAGS # #)[:EXTERNAL] 1: ((SB-PCL::FAST-METHOD ELEPHANT::OPEN-CONTROLLER (DB-BDB::BDB-STORE-CONTROLLER)) #)[:EXTERNAL] 2: (OPEN-STORE (:BDB "/home/mxs/dev/stratobe2/db"))[:EXTERNAL] 3: (SB-INT:SIMPLE-EVAL-IN-LEXENV (OPEN-STORE '(:BDB "/home/mxs/dev/stratobe2/db")) #) 4: ((LAMBDA ())) ----8k----{cut here}----8k---- -- maxigas | kiberpunk Exploit code not people! New PGP key: http://maxigas.hu/maxigas.gpg Fingerprint: EE2E D824 B5C3 4544 C2B8 B75F 2183 52B5 8EC1 57C1 From sky at viridian-project.de Tue May 18 15:13:13 2010 From: sky at viridian-project.de (Leslie P. Polzer) Date: Tue, 18 May 2010 17:13:13 +0200 (CEST) Subject: [elephant-devel] Berkeley DB error: Invalid argument In-Reply-To: <20100509.060626.833503636937433487.maxigas@anargeek.net> References: <20100509.060626.833503636937433487.maxigas@anargeek.net> Message-ID: <92d9deb86d42321dc96da5f6b154da9a.squirrel@mail.stardawn.org> maxigas wrote: > configure: error: C compiler cannot create executables Check config.log to see the real error. > My guess is that the compilation was OK and there is another problem. Compilation hasn't even started if you get an error at the configure stage. > Should I create something like a database before I try open-store or it is enough to > have an open and writable directory? You just need to have the directory present. Leslie From wrn.lynn at gmail.com Sun May 30 00:38:58 2010 From: wrn.lynn at gmail.com (Warren Lynn) Date: Sat, 29 May 2010 20:38:58 -0400 Subject: [elephant-devel] Persistent class slot Message-ID: Hi, As I understand from the online document, class slots with :allocation :class are not persisted. Is there any plan to change that soon? I first did not think that is such a big deal, but then I encountered a performance issue to which I think persisted class slot may be the answer. The issue I have is: I am using Weblocks + Elephant + Postmodern to display the instances of a class in paginated web pages. Weblocks needs to know the total count of the instances to plan the pagination (so it can display something like "1 of xxx pages" ). It turns out just counting (by map-class) the instances (about 5000) will take about 8 seconds (my laptop is not that powerful, but quite decent). So I think a possible solution is to allow a class to have persisted class slots, like "count". Then, some generic functions can be defined to allow the user code to update the persisted class slots in a contention safe way (wrapped in transactions) on some critical check-points, such as when a new instance is persisted or when a instance is deleted/modified. The functions could be named as "on-delete, on-add, on-modified. This way we can keep an up-to-date count all the time. Actually, class slot like "count" may even be made ready for the user to use directly without any addition user code. Counting instances of a class seems to be a very common use case. So I hope the above is convincing enough for the need of persistent class slots. But I am too inexperienced to know how much work this will require. Thanks for any comments. Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From wrn.lynn at gmail.com Sun May 30 03:32:19 2010 From: wrn.lynn at gmail.com (Warren Lynn) Date: Sat, 29 May 2010 23:32:19 -0400 Subject: [elephant-devel] Unique persistent slot value Message-ID: Hi, Is there a simple way to ensure that values of a persistent slot must be unique? Namely, when a instance is persisted (either with the plain make-instance or at the end of a transaction), an error of condition will be thrown if the slot value is not unique. Thank you. Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From sky at viridian-project.de Sun May 30 09:07:04 2010 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 30 May 2010 11:07:04 +0200 (CEST) Subject: [elephant-devel] Unique persistent slot value In-Reply-To: References: Message-ID: <771a8411ebd7159bc953cf245b045248.squirrel@mail.stardawn.org> Warren Lynn wrote: > Is there a simple way to ensure that values of a persistent slot must be > unique? Namely, when a instance is persisted (either with the plain > make-instance or at the end of a transaction), an error of condition will be > thrown if the slot value is not unique. Thank you. There is no support for constraints like this right now. Leslie From sky at viridian-project.de Sun May 30 09:20:51 2010 From: sky at viridian-project.de (Leslie P. Polzer) Date: Sun, 30 May 2010 11:20:51 +0200 (CEST) Subject: [elephant-devel] Persistent class slot In-Reply-To: References: Message-ID: Warren Lynn wrote: > So I think a possible solution is to allow a class to have persisted class > slots, like "count". Then, some generic functions can be defined to allow > the user code to update the persisted class slots in a contention safe way > (wrapped in transactions) on some critical check-points, such as when a new > instance is persisted or when a instance is deleted/modified. The functions > could be named as "on-delete, on-add, on-modified. This way we can keep an > up-to-date count all the time. Actually, class slot like "count" may even be > made ready for the user to use directly without any addition user code. Why not have a caching get-instance-count function instead? Leslie From wrn.lynn at gmail.com Sun May 30 15:42:01 2010 From: wrn.lynn at gmail.com (Warren Lynn) Date: Sun, 30 May 2010 11:42:01 -0400 Subject: [elephant-devel] Persistent class slot In-Reply-To: References: Message-ID: > Why not have a caching get-instance-count function instead? > > Leslie > > I doubt that will work well for datasets on which people are adding/deleting records. If we just cache the count, then we will need to do a recount every time some one adds/deletes some records, which will halt the site for a while. I thought it is better to update the persistent count slot when the records are deleted/added so we won't need to do count at all (unless when the count is inconsistent with the dataset). -------------- next part -------------- An HTML attachment was scrubbed... URL: