[elephant-devel] Querying for objects on two slots

[Ian Eslick]

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 language.

e.g. '(tuple (integer 16) (integer 16))          ; (to-user-id, from- 
user-id)
      '(tuple (string 40) boolean (integer 8))    ; (last-name, sex,  
age)

For example we could export a multi-item index with a new API and let  
the backend decide how to do it or tell you it can't.  For classes  
this could be an extension so the derived index model.  A specific  
data store could check for violations when you insert and you can do a  
bulk upgrade to rebuild the index if you need to.

Ian

On Jan 13, 2009, at 8:51 PM, Robert Synnott wrote:

> 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 Kowalik <yarek.kowalik at gmail.com>:
>> 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  
>> <killerstorm at newmail.ru> wrote:
>>>
>>> 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 significant and you get a slowdown because
>>> of this, you might want to optimize this. a trivial thing is to  
>>> try it
>>> symmertrically with slot-a -- whatever returns less objects is  
>>> better.
>>> less trivial optimizations would be to work on lower-level -- via
>>> map-inverted-index (to avoid allocating whole list but instead test
>>> objects
>>> one by one) or even cursor API (this way you can retrieve oids  
>>> rather
>>> than objects, which should be faster, and also iterating both  
>>> indices at
>>> once might be a significant benefit if values are not uniformly
>>> distributed).
>>>
>>> but the most optimal way doing this in case of high number of  
>>> objects
>>> in both slot-a and slot-b queries would be building and using  
>>> multi-column
>>> index. unfortunately, Elephant does not help you with it -- either  
>>> you'll
>>> have
>>> to serialize slot tuples into a string (e.g (format nil "~a_~a"  
>>> slot-a
>>> slot-b)),
>>> or reorganize your data to use a custom index structure (like  
>>> btree of
>>> btrees).
>>>
>>> there are also backend-specific considerations. for postmodern
>>>
>>> (intersection (get-instances-by-value 'my-class 'slot-b val-b)
>>>                   (get-instances-by-value 'my-class 'slot-a val-a))
>>>
>>> would be much faster then testing objects one by one, for BDB -- i  
>>> doubt
>>> so.
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> elephant-devel site list
>>> elephant-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>
>>
>> _______________________________________________
>> elephant-devel site list
>> elephant-devel at common-lisp.net
>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>
>
>
>
> -- 
> Robert Synnott
> http://myblog.rsynnott.com
> MSN: rsynnott at gmail.com
> Jabber: rsynnott at gmail.com
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel