[web-devel] Join support in persistent

[Greg Weber]

[snip]

 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.
>
> I'm not sure what you're suggesting here to be honest, can you clarify?
>

An O(m + n) implementation instead of O(m * n) by using constant lookups
instead of repeatedly searching through a list.


[snip]


>> It would be best for it to also be clear from the function names or
>> arguments..
>>
>> 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 ;)
>

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.

[snip]


>
>>> 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.
>>
>>
> 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).
>
> 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.
>
> Michael
>
>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110402/4ba23c45/attachment.htm>