Hmmm...I can't reproduce this. Anyone else?
Did you clean the tests/testdb directory before running the test?
While we try to keep the tests idempotent, sometimes a pre-existing
database (esp. from a prior version of the code) can create problems.
Ian
On Feb 20, 2008, at 8:29 PM, [EMAIL
On Feb 20, 2008, at 10:55 PM, [EMAIL PROTECTED] wrote:
Ian,
Thanks for the great feedback.
I understand your point about the postmodern performance issue.
Hopefully that is something that could be overcome in the future.
Probably not entirely. Especially if you're talking over a socket
Dear Leslie,
Thanks for this patch.
However, I wonder if it possible for you to turn whatever made you
notice it into a test-case? It is possible that this bug exists on the
LISP you are using and not mine, but in any case we should use each such
bug as an opportunity to expand th
Ian,
Thanks for the great feedback.
I understand your point about the postmodern performance issue.
Hopefully that is something that could be overcome in the future.
I do happen to prefer BDB for some reason and I like the whole
elephant system in general for the reasons you mention and ot
On Feb 20, 2008, at 5:14 PM, Alex Mizrahi wrote:
hello
i'm now going to improve transaction handling in db-postmodern.
Great! We should make sure this doesn't change the API, or if it does
to create tracking changes in the BDB and CL-SQL stores.
first of all, i'm going to use "serializa
I doubt that Elephant on postmodern is going to be faster than using
CL-SQL to do direct ORM against Postgresql. Despite the great work
that Henrik and others have done with Postmodern, there are too many
layers of abstraction in the architecture to overcome. The real point
of using Eleph
Well, this is certainly interesting, since this would allow me to
decouple the storage system from the lisp environment allowing the
possibility of setting up a cluster of lisp machines to handle
application logic. Isn't there a way to achieve this on BDB?
We prefer to deploy our systems on
Ok, this is an architectural issue that wasn't completely thought
out. Currently class indexing effectively limits instances of a class
to a specific store. The first time an instance is saved, the current
*store-controller* is used to create the class index tying the class
to that store.
On Feb 20, 2008, at 8:44 PM, [EMAIL PROTECTED] wrote:
Hi all,
I don't mean to start a war here or put any work down. However, I
just needed some clarification/direction into which way the data
stores work is going.
One challenge is that the current implementation is setup to only work
Hi all,
I don't mean to start a war here or put any work down. However, I just
needed some clarification/direction into which way the data stores
work is going.
From the documentation I've read, the BDB data store only supports
BDB version 4.5 (or up to 4.5), so further work done in 4.6 a
Hi all,
I downloaded the latest elephant this morning and ran the BDB tests,
one of which failed. I haven't really looked much into it because I'm
traveling. However, just wanted to share this with you in case you
were aware (or not) and I might have missed something.
Thanks,
Waldo
I'm not sure I understand this part? Do you mean if you have an
internal error which does not complete the intended transaction but
doesn't throw that through the 'with-transaction' statement then you
get bad data?
It seems that you may be expecting too much of the database. If you
are
I just looked at the code and it appears to call 'get-con' in all the
right places. The code certainly is structured to do what you suggest
(get controller from the instance slot). I'll chase this down
tonight. Perhaps some recent change created a corner case that the
tests don't catch,
On Feb 20, 2008, at 11:36 AM, Leslie P. Polzer wrote:
I don't know whether it was a change in Elephant, SBCL or even
somewhere
else that introduced problems with the Unicode serializer, but the fix
is very small (changed two calls to SCHAR to CHAR) and should probably
be applied ASAP.
I'm
hello
i'm now going to improve transaction handling in db-postmodern.
first of all, i'm going to use "serializable" isolation level instead of
default "read commited". this means: transaction can fail because of
concurrent slot updates.
with default isolation level concurrent updates were OK, l
I don't know whether it was a change in Elephant, SBCL or even somewhere
else that introduced problems with the Unicode serializer, but the fix
is very small (changed two calls to SCHAR to CHAR) and should probably
be applied ASAP.
I'm not sure why the code is discerning between STRING and SIMPLE
This concerns indexed classes.
Observe:
(asdf:oos 'asdf:load-op 'elephant)
(defpackage #:ele-test (:use :cl :elephant))
(in-package :ele-test)
(defvar *sc2* nil)
(defvar item nil)
(defpclass myclass ()
((testslot :accessor testslot :initarg testslot :index t)))
(open-store '(:BDB "/tmp/d
17 matches
Mail list logo
