Simple search API proposal, take 2

[Jamie McCracken]

Mikkel Kamstrup Erlandsen wrote:
> 2007/1/11, Jamie McCracken <jamiemcc at blueyonder.co.uk>:
>> Jamie McCracken wrote:
>> >
>> >>
>> >> Could you define what the a{sa{sas}} map is?
>> >
>> > it should probably be a{sv} where s is the uri and v is the variant
>> > holding an array of metadata values for that uri (the order of the
>> > metadata fields will match the fields specified in the properties 
>> array)
>> >
>>
>> actually we use "aas" or "aav" for the equivalent function in tracker
>> simply because the hashtable/dict screws up the rank ordering
>>
>> in fact never use a{xx} for anything where you want to preserve the
>> order of results
> 
> Well, using a flat list would require that the hit_id was a property
> too. It doesn't feel right to me...
> 
> Is it really that bad to screw up ordering? There could just be a
> property to sort after. If you request (0,100) you know you are only
> going to sort 100 hits at a time... I acknowledge that it is doulbe
> work though.
> 

its not that - it simply passes the problem onto the client to sort 
stuff which also means you need to send the rank down. Clients sould be 
able to interface with the minimal amount of code.

a{xx} is only useful if you want quick random access to elements and 
dont care about order.

"aas" or "aav" is no different if all the client does is iterate over 
them (which almost all of them will do) especially when the backend 
sorts the results, a{xx} jumbles them up and then the client resorts 
them by putting them into a list - would it not be best to simply return 
a sorted list?




-- 
Mr Jamie McCracken
http://jamiemcc.livejournal.com/