Right now they're 32 bits by convention, but I'd like them to be 64-
bits on a 64-bit machine eventually so far I don't think we're in
danger of blowing out 32 bits of oids - you can compact OID values by
doing a migration. Actually it wouldn't be hard to replace this with
a 'find next unus
Correction (missing single quotes):
(format t "~8,'0X ~8,0'X" slot-a-val slot-b-val)
On Wed, Jan 14, 2009 at 12:07 PM, Yarek Kowalik wrote:
> Out of curiosity, the OIDs in elephant are they 32 bit integers or 64? I'm
> running on Ubuntu-64/SBCL-64.
>
> I'm thinking that my 'query' slot vale w
Out of curiosity, the OIDs in elephant are they 32 bit integers or 64? I'm
running on Ubuntu-64/SBCL-64.
I'm thinking that my 'query' slot vale would be generated something like
this (for 32 bit values):
(format t "~8,0X ~8,0X" slot-a-val slot-b-val)
Yarek
On Tue, Jan 13, 2009 at 5:51 PM, Robe
Thanks Alex,
I think a toolkit/wrapper around the current model of derived indices
where you can define a derived index with a function where that
function is parameterized by the slots it indexes and a specification
of the maximum size of that slot, etc would be easy to include as an
aid.
IE> Alex, what would the issues be for the postmodern backend?
IE> Could we use a behind the scenes convert-to-string strategy so we had
IE> a common API for indexing on tuples?
doing it in "proper way" (sorting on multiple columns) will be quite hard
in postmodern, as it means complicating c
There is no good general solution to this is you are going to change
encodings from something open-ended to something of fixed radix (e.g.
a pair of integers => fixed length string field).
We might be able to provide some support for specific kinds of items
defined by a simple specification
I'd like to add a mechanism for sorting on small tuples, but it would
be different for each backend. I think I know how to do it for BDB,
but it will take some work. CLSQL could do it pretty easily (however
see my response to Leslie's recent mail).
Alex, what would the issues be for the pos
I don't believe the Postmodern backend, at least, allows search by conses.
If you want sensible (ordered) results with a and b if a and/or b are
integers, by the way, you should zero-pad them; otherwise, say, '1 2'
comes after '1 12', which is probably not what you want
Rob
2009/1/14 Yarek Kowali
When serializing tuples, is the string representation best: You suggest
using (format t "~A ~A" a b) - is that efficient enough? what about doing
(cons a b) = is there a way to index and search for conses? Any other ideas?
Yarek
On Tue, Jan 6, 2009 at 5:17 AM, Alex Mizrahi wrote:
> YK> Is thi
On Tue, Jan 06, 2009 at 03:17:13PM +0200, Alex Mizrahi wrote:
>
> LP> Use MAP-CLASS, this will considerably speed up the query.
>
> how is that? using at least one index is much better than using no index at
> all.
Indeed. I've been think about this a bit today after I wrote it and
MAP-INVERTED-
Generally using get-instances-xxx is expensive (you have to cons up
all objects). A more efficient solution would be to map-inverted-
index over slot-b value and filter by the slot-a value. If slot-b
returns a small set, this is pretty darned efficient.
The little query interpreter we have
YK> Is this a reasonable way of finding an object of type
YK> 'my-class that matches on values val-a and val-b for slots a and b?
yep, it is reasonable if you have relatively low number of objects
in returned by (get-instances-by-value 'my-class 'slot-b val-b) query.
if number of objects is signif
On Mon, Jan 05, 2009 at 10:36:29PM -0800, Yarek Kowalik wrote:
> I've run into several situations where I want to query for objects that
> match values two or more slots. I currently do something like this:
>
> (defclass my-class ()
> ((a :accessor slot-a)
>(b :accessor slot-b
> :inde
I've run into several situations where I want to query for objects that
match values two or more slots. I currently do something like this:
(defclass my-class ()
((a :accessor slot-a)
(b :accessor slot-b
:index b))
(:documentation "my test class"))
(find-if (lambda (obj)
14 matches
Mail list logo
