It'd probably be easier to manage the index yourself as a separate table. Maybe an ordered_set table where the record is something like {key={indice, record_id}, val=val}. Then you can match on the indice to pull out record_ids and vals.<br>
<br>Jacob<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I have an index on a table that represents a user taxonomy - how the<br>
user has chosen to organise their world in the application.<br><br>
It is a fairly dense index, that is for each indice there will be<br>
between 30 and several hundred actual records.<br><br>
At the moment to expose the taxonomy to the user I have to build a<br>
query that returns the value of the index from every record, and then<br>
de-duplicate that back down to get the index - which has been slow on<br>
occasions...<br><br>
As far as I can tell there is no way through the published API to<br>
simply 'read the index' but I am sure I could plow into the code and<br>
'work it out' but I am wary of the old 'undocumented API' beartrap.<br><br>
Any suggestions?<br><br>
Gordon<br></blockquote>