[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're solving a different problem. Are you talking about the fact that the EntryAuthorIn constructor takes a list instead of a Set? That'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'm not sure what you'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'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'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've used this myself when I needed to do something that Persistent didn'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's missing that is preventing people from dropping down to SQL now? If it's just a documentation issue, I'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>