Scribit Ian Eslick dies 11/04/2007 hora 13:44:
> This sounds intriguing! I'm not sure what you mean by data model,
> however.
I did that in my very first application with Elephant. It was a real
estate catalog. Several times, I had to add slots to the objects
describing the products.
All I had t
Ian Eslick wrote:
You should check out Arthur Lemmon's Rucksack, it's architecture is
much more ZODB like.
A couple of people are also interested in doing an all-lisp data store
for Elephant that gets rid of any license issues. I believe that it
may be possible to make the native solution ru
You should check out Arthur Lemmon's Rucksack, it's architecture is
much more ZODB like.
A couple of people are also interested in doing an all-lisp data
store for Elephant that gets rid of any license issues. I believe
that it may be possible to make the native solution run faster than
This sounds intriguing! I'm not sure what you mean by data model,
however. Do you mean change the underlying backing store? It
wouldn't be hard to add something like this into the MOP data access
protocol. I think there are some interesting issues surrounding how
to handle this in an onl
this is an entirely anecdotal remark, not really relevant, but one of
the original inspirations for elephant was a database system that was
used in-house at a company i was at with andrew blumberg and other
lisp hackers. i was doing java crap and was a complete lisp neophyte,
and was amazed to se
Scribit Robert L. Read dies 09/04/2007 hora 18:43:
> However, if someone else can go, I am also happy to help or to
> co-author a paper with them.
It occurred to me that the combination of persistence and the MOP goes
far beyond anything else I know in terms of flexibility WRT to the data
model.
Scribit Robert L. Read dies 11/04/2007 hora 09:01:
> The real problem here is that Elephant is so different, and so much
> more powerful and convenient than a relational system, that [...] if
> we use a relational benchmark, we are tying our hands behind our back.
We could also look at OO specific
Well that was easy. In that case all four supported lisps should
generate interoperable serializations at this time on the same
machine architecture (little endian and big endian will not be
compatible, but 32 and 64-bit should be. I will not test this
feature during this release, but if
On Wed, 11 Apr 2007 09:54:17 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
> The docs are actually not clear on this and I haven't had time to do
> an experiment, but they seemed to indicate that while wide words are
> supported internally and that external IO could have an external
> format of uni
I suspect the raw IO costs are going to dominate the query compilation
time, and for straight scans and point reads, which I imagine to be the
majority of the queries, the optimizers will find a good plan trivially.
An interesting experiment would be to take a simple benchmark that
stores a million
The docs are actually not clear on this and I haven't had time to do
an experiment, but they seemed to indicate that while wide words are
supported internally and that external IO could have an external
format of unicode as well as many others. There was no indication
which external format
On Wed, 11 Apr 2007 08:45:36 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote:
> I don't think that Lispworks returns proper unicode codes.
Why not?
___
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-
One interesting result from the recent serializer rewrites is that I
was able to open a database in SBCL that was created in Allegro and
read back in strings, symbols, numbers, regular and persistent classes.
I think that SBCL, Allegro, OpenMCL and Lispworks will have
compatible databases f
It's interesting that there is only a little performance advantage.
Have you done some profiling to see where the time is going? It
sounds like either the queries were simple enough that the
compilation step was trivial or that we're seeing Ahmdal's law and
the SQL costs are swamped by so
Regarding stored procedures, I agree with Ian that the main performance
advantage that come from them is that the query planning is prepared in
advance. This is also done if you use prepared sql statements, so they
give the same advantage. Stored procedures can however be faster if they
involve sev
15 matches
Mail list logo
