On Tue, Feb 10, 2009 at 6:33 PM, Ian Eslick <span dir="ltr"><<a href="mailto:eslick@media.mit.edu">eslick@media.mit.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For that particular query there is a more efficient way, but it's not<br>
natively supported in any of the high level APIs.  We're not (yet)<br>
trying to reproduce all the queries you are accustomed to in SQL<br>
databases.  The goal of the query system is to move in that direction<br>
when it makes sense.  For example we don't have an efficient COUNT.</blockquote><div><br>I can live with that for the time being. I just need to learn how to be able to perform these queries efficiently, even if they need to access low-level API calls. Maybe when the query system is ready we won't need those, maybe we still may need those.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If you need to do lots of table ops, better to use a SQL database!<br>
The goal of an OODB is really to support queries based on the link-<br>
structure of the objects and not based on treating their slots like<br>
ORM columns.<br>
</blockquote><div><br>Agree. Maybe I could create a class STATE with an associated slot for all the "offices" in each state and access it through there. Would that be more efficient? I suppose that for any "relational" slot, I could "link" it to a new persistent class and then just follow the links. I just have a feeling that may not necessarily be as efficient.<br>
<br>Regardless, I think the query system will be a big plus to all this. After all the links are defined and done, there's always going to be a query which will require some type of table op.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That said you can use the underlying dup-btrees directly when you need<br>
to...but it turns out I wrote one for my own use that you can look at<br>
as an example:<br>
<br>
(ele::get-unique-values (find-inverted-index 'provider 'state))<br>
<br>
I can probably export some of the macros I use to make using cursors<br>
more convenient, but I'd rather put the limited time I have into the<br>
query system which we can extend to do stuff like this...<br>
<br>
I'm curious what performance you get on the get-unique-values call...</blockquote><div><br>Ask and you shall get :) Well the performance difference is tremendous and more efficient in terms of consing as well:<br><br>
(time (ele::get-unique-values (find-inverted-index 'provider 'state)))<br>Evaluation took:<br>  0.349 seconds of real time<br>  0.014830 seconds of total run time (0.010738 user, 0.004092 system)<br>  4.30% CPU<br>
  27 lambdas converted<br>  724,402,627 processor cycles<br>  489,624 bytes consed<br>  <br>("AL" "AR" "AZ" "CA" "CO" "CT" "DC" "DE" "GA" "HI" "IA" "ID" "IL" "IN" "KS"<br>
 "KY" "LA" "MA" "MD" "ME" "MI" "MN" "MO" "MS" "MT" "NC" "ND" "NE" "NH" "NJ"<br>
 "NM" "NV" "NY" "OH" "OK" "OR" "PA" "RI" "SC" "SD" "TN" "TX" "UT" "VA" "VT"<br>
 "WA" "WI" "WV" "WY")<br><br>I will look at your get-unique-values and learn from it. I'm sure similar solutions can be applied to other similar types of queries.<br><br>Thanks again<br>
JD<br></div></div>