haskelldb-users

[Haskelldb-users] Interested in updating HaskellDB

[Justin B. <jgb...@gm...>]

Greetings,

I've spent most of this week investigating HaskellDB. I am interested
in using it as the basis for specifying and generating an ORM layer
for an application I work on at my day job. I've gotten to the point
of using it to query our existing database and generate table
specifications from that. I am very impressed, especially considering
the low level of activity on the project over the last several years.
It's solid work.

I'd like to extend the API to do joins properly and to not force a
"DISTINCT" clause into each query. Is that a feasible idea (assuming
my Haskell abilities are up to it)? Would this list be a good resource
for asking questions about the code, if I start hacking on it?

Thanks for the great work so far and in advance for any help or advice.

Justin

Re: [Haskelldb-users] Interested in updating HaskellDB

[Bjorn B. <bri...@cs...>]

On Nov 16, 2007, at 21:16 , Justin Bailey wrote:

> Greetings,
>
> I've spent most of this week investigating HaskellDB. I am interested
> in using it as the basis for specifying and generating an ORM layer
> for an application I work on at my day job. I've gotten to the point
> of using it to query our existing database and generate table
> specifications from that. I am very impressed, especially considering
> the low level of activity on the project over the last several years.
> It's solid work.
>
> I'd like to extend the API to do joins properly and to not force a
> "DISTINCT" clause into each query. Is that a feasible idea (assuming
> my Haskell abilities are up to it)? Would this list be a good resource
> for asking questions about the code, if I start hacking on it?
>
> Thanks for the great work so far and in advance for any help or =20
> advice.
>
> Justin

Hi Justin,

that sounds like a good plan. The DISTINCT thing ought to be easy =20
enough. It's not obvious to me how to get the types right for joins, =20
but you are welcome to look at it. CoddFish [1] might provide some =20
inspiration.

This list doesn't get a lot of traffic, but I think it's the best =20
place for discussing HaskellDB hacking.

Peter Gammie is also hacking on HaskellDB at the moment, so you may =20
want to talk to him. Peter: It might makes sense for you to be on =20
this list.

/Bj=F6rn

[1] http://wiki.di.uminho.pt/twiki/bin/view/Research/PURe/CoddFish

Re: [Haskelldb-users] Interested in updating HaskellDB

[Jeremy S. <jer...@li...>]

Hello,

You should also look into the fixing the bug that occurs if the same
column name appears in two tables, and you do a query that uses both
columns.

There are also two issues I have with the way HaskellDB does things:

 1. I don't think the queries really need constructed using monads.

 2. I think HaskellDB converts from Query Algebra to the internal data
 structure too early.

I imagine an algebra somewhat like this:

data Algebra :: (* -> *) where
    Project   :: (IsSubset schema schema', FieldName field, Show a) => Projection schema field a -> Algebra schema' -> Algebra ((field :=: a) :*: Empty)
    Selection :: (Expr schemaE Bool) -> Algebra schema -> Algebra schema
    Product   :: Algebra schemaa -> Algebra schemab -> Algebra schemac
    Table     :: TableName -> Algebra schema

and then you write a query a bit like this:

testb = 
    projectAs Table1.field1 (undefined :: Table1.OtherField) $
    selection (Table1.field1 .==. (Lit 1)) $
        product Table1.table Table2.table

*Examples> testb
project <some projections>
  (select Table1.FieldName1 == 1
     (product
        (table Table1)
        (table Table2)))
*Examples> toSql testb
SELECT Table1.FieldName1 AS Table1.OtherField FROM Table1, Table2 WHERE Table1.FieldName1 == 1
*Examples> 

One advantage of this scheme is that it makes it very natural to
compose query fragments into larger queries. It also allows you to
preform a certain level of query optimization at compile time, instead
of runtime.

The disadvantage is that it is difficult to implement. The projections
gave me the most trouble. My hope is that the associated types stuff
will make it easier to write the code.

I developed an untype version of this method for querying debian
package indexes, which you can find here:

http://www.n-heptane.com/nhlab/repos/haskell-dql/

I doubt it still builds however, due to the libraries is uses changing
significantly.

In other news, if you want more information on query algebra, and
doing things such as optimizing out sub-selects, I recommend you get
this book:

http://www.amazon.com/Database-System-Implementation-Hector-Garcia-Molina/dp/0130402648/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1195265481&sr=8-1
http://infolab.stanford.edu/~ullman/dbsi.html

It has a chapter on query algebra and another on query algebra
optimization. Unlike most other writings on the subject, it treats
databases as multisets/bags, instead of sets. Since you want to get
rid of 'DISTINCT', you will need use the correct laws for multiset
union, intersection, etc.

If you are very interested in databases, you could instead buy the
successor to that book:

http://www.amazon.com/Database-Systems-Complete-Hector-Garcia-Molina/dp/0130319953
http://infolab.stanford.edu/~ullman/dscb.html

But it is significantly more expensive. 

j.



At Fri, 16 Nov 2007 12:16:36 -0800,
Justin Bailey wrote:
> 
> Greetings,
> 
> I've spent most of this week investigating HaskellDB. I am interested
> in using it as the basis for specifying and generating an ORM layer
> for an application I work on at my day job. I've gotten to the point
> of using it to query our existing database and generate table
> specifications from that. I am very impressed, especially considering
> the low level of activity on the project over the last several years.
> It's solid work.
> 
> I'd like to extend the API to do joins properly and to not force a
> "DISTINCT" clause into each query. Is that a feasible idea (assuming
> my Haskell abilities are up to it)? Would this list be a good resource
> for asking questions about the code, if I start hacking on it?
> 
> Thanks for the great work so far and in advance for any help or advice.
> 
> Justin
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users

Re: [Haskelldb-users] Interested in updating HaskellDB

[Justin B. <jgb...@gm...>]

On Nov 16, 2007 6:20 PM, Jeremy Shaw <jer...@li...> wrote:
> Hello,
>
> You should also look into the fixing the bug that occurs if the same
> column name appears in two tables, and you do a query that uses both
> columns.
>
> There are also two issues I have with the way HaskellDB does things:
>
>  1. I don't think the queries really need constructed using monads.
>
>  2. I think HaskellDB converts from Query Algebra to the internal data
>  structure too early.
>

I'll keep that in mind, because one of the primary reasons I'd like to
do this is to be able to compose queries. You're proposal below might
be beyond my current abilities though - I haven't quite grokked
type-level programming like that.

Thanks also for the book recommendations. I've got them on the way to
my local library!

Justin

Re: [Haskelldb-users] Interested in updating HaskellDB

[Jeremy S. <jer...@li...>]

At Sat, 17 Nov 2007 09:13:13 -0800,
Justin Bailey wrote:
> 
> On Nov 16, 2007 6:20 PM, Jeremy Shaw <jer...@li...> wrote:
>
> You're proposal below might be beyond my current abilities though -
> I haven't quite grokked type-level programming like that.

No problem. Removing the monadic stuff might be feasible. I believe
the monad is only used to create unique names for internal column and
table names. But, you might be able to use a different system for
ensuring that the names are unique.

> Thanks also for the book recommendations. I've got them on the way to
> my local library!

Good thinking :)

j.