[snip]<div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div></div></div></div></div></blockquote></div>

</div></blockquote>

</div><div>I think you&#39;re solving a different problem. Are you talking about the fact that the EntryAuthorIn constructor takes a list instead of a Set? That&#39;s not where the slowdown comes from. Actually, for the current backends, a set would needlessly slow things down, since the In constructor simply converts things to SQL and lets the database do the work.</div>



<div><br></div><div>I&#39;m not sure what you&#39;re suggesting here to be honest, can you clarify?</div></div></div></blockquote><div><br></div><div>An O(m + n) implementation instead of O(m * n) by using constant lookups instead of repeatedly searching through a list.</div>

<div><br></div><div> </div><div>[snip]</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div><div><br></div></div><div>It would be best for it to also be clear from the function names or arguments..</div><div>

<div><br></div></div></div></blockquote></div><div>I actually thought it *was* clear that it would be an inner join and not an outer join. But how would you change the names? I don&#39;t want to end up with selectJoiningOneToManyRelationshipUsingInnerJoin ;) </div>

</div></div></blockquote><div><br></div><div>How do I know it is an inner join? If there is just one function I would assume it is an outer and I can get an inner by filtering the results, not that there is no way to do an outer. If there is a second function that is called *Outer, then it might be clear that the other is an inner. The other approach is instead of EntryAuthorEq to have something like InnerJoin (if possible) or otherwise EntryAuthorInner.</div>

<div><br></div><div>[snip]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div dir="ltr"><div class="gmail_quote"><div class="im">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div></div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div><br></div></div></div></div></blockquote></div></div></blockquote></div>

<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>I agree, I am not trying to say that we need to elegantly handle every possible query. I am just pushing that for those that we are currently handling to be elegant. Persistent integration with directly writing SQL should probably be a high priority.</div>





<div><br></div></div></blockquote><div><br></div></div><div>Can I get some feedback on what&#39;s missing for this? In the Database.Persist.GenericSql.Raw module[1], there are two functions (withStmt and execute) that let you run any SQL command against the DB you want. I&#39;ve used this myself when I needed to do something that Persistent didn&#39;t allow (a full text search in my case).</div>



<div><br></div><div>I know that the functions are neither pretty nor well documented, but what&#39;s missing that is preventing people from dropping down to SQL now? If it&#39;s just a documentation issue, I&#39;ll address it.</div>



<div><br></div><div>Michael</div><div><br></div></div></div></blockquote><div><br></div><div>Yes we need docs. Is it possible after a raw query to build the data structures back up? -  achieve the same return result of selectList? The other aspect of integration would be the ability to mix SQL fragments with a normal persistent query. For example, for the sql join function under discussion the user could supply the raw join SQL to make it an outer join.</div>

</div></div>