??>> The derived index hack is still more efficient for large sets.
??>> Without changes to the data stores to create an efficient way of
??>> sorting concatenated values, I don't see a way to improve on it
??>> easily.
LPP> I'm not sure you actually need concatenated index values at all
LPP> if
IE> (defpclass user ()
IE>((name :accessor name)
IE> (index :accessor index :associate (message user
IE> (setf charlie (make-instance 'user))
IE> (defpclass message ()
IE>((user :accessor user :associate user)))
IE> (make-instance 'message charlie)
IE> (make-instance 'message ch
??>> it postmodern backend each btree is backed by a database table,
??>> so i think it's not that negligable there..
IE> Ah, I think the CL-SQL and BDB have different performance implications
IE> then. What is the purpose of doing it this way? Are you specializing
IE> the table on the type of
On May 8, 2008, at 11:32 AM, Leslie P. Polzer wrote:
(defpclass person ()
((name ...)
(inbox :accessor inbox :initform (make-indexed-btree message)
:index-on (date sender
Which would create a indexed-btree that stored messages and auto-
created indices on the date and sender
> (defpclass person ()
>((name ...)
> (inbox :accessor inbox :initform (make-indexed-btree message)
> :index-on (date sender
>
> Which would create a indexed-btree that stored messages and auto-
> created indices on the date and sender slots?
>
> That is a bit more OODB/Lispy tha
On May 8, 2008, at 6:14 AM, Leslie P. Polzer wrote:
Wouldn't it make sense to generalize the class index mechanism?
class indexing is basically a specialization ofbtrees. It's pretty
easy to build your own indexes for special purposes and to store them
wherever you want. Common idioms
The table is the closest thing to a btree structure in an sql
database. For example cursor operations are done on table. That is the
idea of using tables as btrees.
BDB maps multiple btrees onto a single large btree. An Elephant btree
key is a binary concatenation of btree-oid+key. This pre
On Thu, May 8, 2008 at 1:11 PM, Ian Eslick <[EMAIL PROTECTED]> wrote:
>
> On May 7, 2008, at 4:20 PM, Alex Mizrahi wrote:
>
>> IE> Given that in Elephant, the cost of a btree instance is negligable,
>>
>> it postmodern backend each btree is backed by a database table,
>> so i think it's not that ne
On May 7, 2008, at 4:20 PM, Alex Mizrahi wrote:
IE> Given that in Elephant, the cost of a btree instance is
negligable,
it postmodern backend each btree is backed by a database table,
so i think it's not that negligable there..
Ah, I think the CL-SQL and BDB have different performance impl
Wouldn't it make sense to generalize the class index mechanism?
At the moment we have one big global name space for indexed objects.
Storing everything there is hellishly expensive for many purposes.
Example:
(intersection
(get-instances-by-value 'message 'owner "Charlie")
(get-instan
> as an interface, it could look like:
>(get-by-range (messages-of user) 'date yesterday nil)
>From my daily work I can say that this functionality would make Elephant
way more useful.
Leslie
___
elephant-devel site list
elephant-devel@common-li
IE> Given that in Elephant, the cost of a btree instance is negligable,
it postmodern backend each btree is backed by a database table,
so i think it's not that negligable there..
IE> one way to do this is the just have a set of messages for each user in
IE> a user slot (a pset or set-valued slo
Hi Alex,
You make a good point below. I haven't dealt with these kind of small
subsets from large sets using multiple parameters problems in a large
system. However, if we take a page from Robert's book about using
lisp as the query engine - how would we solve this problem just with
lis
Do you count fast in 10's of ms or 100's? :) -Ian
On Mar 23, 2008, at 5:27 PM, Alex Mizrahi wrote:
IE> unnecessary. If you have messages indexed by time than you can
simply
IE> walk the index and filter by user until you have a web page
worth of
IE> messages.
worst case behaviour is very
IE> unnecessary. If you have messages indexed by time than you can simply
IE> walk the index and filter by user until you have a web page worth of
IE> messages.
worst case behaviour is very bad -- to prove that there are no messages, it
will have to scan all of them..
what's even worse, this
Another thought on this topic is that with a sufficiently efficient
query system, some of the indices you describe should become
unnecessary. If you have messages indexed by time than you can simply
walk the index and filter by user until you have a web page worth of
messages. A scan, eve
Hi Alex,
I've changed the interface but maintained essentially the existing
functionality, except that subclasses can share a derived index with a
common base class. Allowing heirarchy means that at the low-level
indexes are no longer tied to a specific class in the way they were
before,
IE> :index t is not necessary - in fact it is ignored. :slot-deps
are
also not required, but the derived index is updated on any slot write
if that slot is not transient, set-valued or an association. We can
add those last three slot types into the mix if necessary, but
Do you think you might want to compute derived index updates based on
the value in a transient slot?
The implementation I've chosen is a little different than described
last night:
(defpclass foo ()
((slot1 :accessor slot1 ...)
(slot2 :accessor slot2 ...)
(slot3 :accessor slot3 ...)
Sigh...
Ok, I'll make sure the same facility is available in the new code base.
How painful would it be if I changed the interface to this
functionality? I'd like to make derived indices part of the class
definition rather than a dynamic facility. It simplifies schema
evolution to have a
IE> Does anyone actually use derived indices in the current slot indexing
IE> model?
add-class-derived-index?
yep, we are using them, as they are only way to make some non-trivial
lookups
___
elephant-devel site list
elephant-devel@common-lisp.net
21 matches
Mail list logo
