haskelldb-users — For questions, suggestions, bug reports and patches

[Haskelldb-users] Call for patches: Converting haskelldb repo to darcs-2

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

Greetings!

I am planning on upgrading the haskelldb repository at
http://code.haskell.org/haskelldb/ to darcs-2. I would like to do a
"full" upgrade, but any patches against the darcs-1 repo won't be
valid any longer.

Does anyone have patches - besides Brian, who I know about. I'll leave
this out here for a week or two and if I don't get much response I'm
going to assume its good to go.

Justin

p.s. This is part of my larger plan to get to a haskelldb 1.0 release
this summer. More about that to come ...

Re: [Haskelldb-users] [Haskell-cafe] Request for feedback: HaskellDB + HList

[Brian B. <ph...@ho...>]

Hi Justin,

> src\Database\HaskellDB\Query.hs:152:31:
>     Not in scope: type constructor or class `RecordValues'

That's a part of some changes I made to hlist:



http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz

There were a few things which I thought would be generally
useful for hlist, so I added them there. I mean to see if the
HList devs were interested in merging the changes, but haven't
gotten around to it yet.

Thanks,
-Brian

_________________________________________________________________
Microsoft brings you a new way to search the web.  Try  Bing™ now
http://www.bing.com?form=MFEHPG&publ=WLHMTAG&crea=TEXT_MFEHPG_Core_tagline_try_bing_1x1

Re: [Haskelldb-users] [Haskell-cafe] Request for feedback: HaskellDB + HList

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

Brian,

Sorry for the long delay in my reply. I am trying to build your
updated HaskellDB and am missing a "RecordValues" class:

src\Database\HaskellDB\Query.hs:152:31:
    Not in scope: type constructor or class `RecordValues'

src\Database\HaskellDB\Query.hs:265:33:
    Not in scope: type constructor or class `RecordValues'

src\Database\HaskellDB\Query.hs:551:10:
    Not in scope: type constructor or class `RecordValues'

src\Database\HaskellDB\Query.hs:552:33:
    Not in scope: `recordValues'

Is that in a file  you forgot to add to the repo?

On Thu, May 28, 2009 at 6:59 AM, Brian Bloniarz<ph...@ho...> wrote:
>> * I am really uncomfortable with renaming the HaskellDB operators,
>> both SQL and record level "<<", "#" and "!". I can understand
>> replacing the record level stuff so HaskellDB code matches HList
>> documentation,
>
> While hacking, I was imagining a world where HList records were really well
> documented, and users might be familiar with the HList record syntax before
> they start using HaskellDB. This makes common syntax for records important.
> If you think of records as something universal that will eventually
> be provided by a good library, there's something to be said for HaskellDB
> not
> inventing it's own syntax.
>
> That well-documented world doesn't really exist yet -- the HList paper is
> really good but there's not much beyond that. I was hoping to improve
> HList's
> haddock when I get the chance, though.
>
> As an aside, my hope is that GHC eventually gets some support for extensible
> record syntax and/or first class labels, so there's no need for these
> band-aids.
>
>> but the SQL operators are worrisome. How many conflicts
>> are there? I'd rather see HList imported qualified rather than
>> HaskellDB.
>
> Yeah, having to qualify operators is nasty, I agree.
>
> The main problem is HList's (.*.) (a.k.a. record extension) -- it's a
> Record operation in HList and SQL multiplication in HaskellDB, and it's
> basically indispensible when working with records.
>
> There were other, probably less important conflicts: (.<.), (.+.) and (.-.).
>
>> * I notice "emptyRecord" had to be added to the queries in
>> TestCase.hs. Is it possible to define a new binary operator that does
>> not have to end with "emptyRecord", but has the Nil terminator
>> built-in? The (#) allowed that. Or is this a change introduced by not
>> having to have columns in the same order as the DB?
>
> I think the same "type Record r = RecNil -> r" trick would work.
> That's not how the HList people chose to implement it (there's
> even a short comment in the paper: "We could also consider implicitly
> terminated type sequences. Again, we require a terminating HNil
> to avoid a mess."), but I'm pretty sure it could be added in
> at the HaskellDB layer.
>
> This has a similar flavor to the operator issue -- do we want to think
> of HList as a library which we can encapsulate, and export their records
> under a custom guise? Or do we want to adopt HList Records as a common
> approach to records, and hope that syntax gets better eventually, through
> changes to HList or to the language?
>
> My original thinking was more the latter (partially because I'm interested
> in
> using Records for more than just databases). I think there are pluses and
> minuses on both sides, and I'm certainly happy to prepare patches which move
> in
> the first direction if you think that's the best way to go right now.
>
>> * Besides naming, do queries have to be rewritten? I am wondering if
>> it's possible to create a Compatability module for older code that can
>> export the new HList operators under the old HaskellDB names.
>
> Compatibility for queries is doable, I think. I don't think it's
> possible for table & label definitions.
>
> Just FYI, while I was hacking, I had in mind some further changes which
> would go father down the road of incompatibility -- that's for another email
> :)
>
>> * Finally, I am not sure I understand the implications of removing
>> the Attr type. Can you elaborate?
>
> Not sure if I understand _all_ the implications, but here's my version:
>
> I found it clunky in HaskellDB that there were two operators (.=.)
> and (<<) depending on whether you were working at the Record level or
> DB attr level. There's a comment in the "HaskellDB Improved" paper:
>
>> In order to make type inference of record selection easier and to get
>> a more TRex-like syntax, we wrap the actual field labels in a label
>> type which includes the type of the associated field value.
>
> I'm not sure about the "TRex-like syntax" part, because the syntax
> without Attr is only cosmetically different. When I got hacking, it
> seemed to me that inference was doable without Attr. As an example:
>
>> t1 <- table int_tbl
>> project $ f02 << (t1 ! f02) .+. constant 1
>
> The (t1 ! f02) .+. constant 1 gets inferred to be an Expr Int
> thanks to the type of t1. So why does (<<) need to fix the type of type
> of its second argument at all?
>
> In all the cases I looked at, inferring the types from the table definitions
> the expression operators was good enough. I looked closely at TestCases,
> I might have missed some other example.
>
> Thanks a lot for your feedback, I'm glad you're not disgusted yet :)
>
> -Brian
>
>> Justin
>>
>> On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz wrote:
>> > Hi,
>> >
>> > It's come time to share something that I've been playing around with
>> > recently:
>> > a branch of HaskellDB which replaces the home-grown Record code with
>> > HList
>> > records. It's definitely not ready for primetime, but I thought it'd be
>> > a
>> > good
>> > time to post the code and solicit some feedback from the community.
>> >
>> > HaskellDB the concept is very promising, but IMHO the code still falls
>> > short
>> > of that promise. Hopefully this is a small step in the right direction
>> > --
>> > the
>> > advantages of using HList:
>> > * Shared implementation of extensible records
>> > * Additional features from HList
>> > * Better error messages for record misuse
>> > * "Lacks" predicates
>> > * Simpler code
>> >
>> > As an example of how this can be better, a DB insert looks like so:
>> >> insert db table $ constantRecord $
>> >> film .=. "Munchie" .*.
>> >> director .=. Just "Jim Wynorski" .*.
>> >> emptyRecord
>> > The columns need not appear in the same order as in the database. If you
>> > forget
>> > a column, you'll get "error: No instance for (Fail (FieldNotFound (Proxy
>> > Director)))"
>> > rather than an opaque error. Using the new "insertOpt" function, Maybe
>> > columns
>> > will default to Nothing rather than needing to be specified.
>> >
>> > The details:
>> >
>> > I haven't updated everything, but there's enough to run
>> > test/TestCases.hs
>> > under Postgresql. TestCases is probably the best place to look for
>> > examples
>> > of
>> > the new syntax for now.
>> >
>> > HList had name conflicts with HaskellDB's SQL expression language
>> > ((.*.), (.++.), etc.) My temporary band-aid is to move the expression
>> > functions
>> > to Database.HaskellDB.SqlExpr, and require people to import qualified.
>> >
>> > The Attr type is gone, columns labels are untyped now. I also replaced a
>> > few instances of primitive type-level recursion with HMap/HMapOut. This
>> > makes
>> > the code simpler, and the type signatures more complex -- type families
>> > would
>> > help a lot here, I think.
>> >
>> > Feedback welcome! You can find my darcs tree at:
>> >
>> >
>> > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/haskelldb-hlist-20090516.tar.gz
>> > It also requires minor changes to HList, available at:
>> >
>> >
>> > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz
>> > I'll talk to the HList people about getting those merged.
>> >
>> > Thanks!
>> >
>> > Brian Bloniarz
>> >
>> >
>> > ________________________________
>> > Hotmail® has a new way to see what's up with your friends. Check it out.
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > Has...@ha...
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> >
>
>
>
> ________________________________
> Hotmail® goes with you. Get it on your BlackBerry or iPhone.

Re: [Haskelldb-users] [Haskell-cafe] Request for feedback: HaskellDB + HList

[Brian B. <ph...@ho...>]

> * I am really uncomfortable with renaming the HaskellDB operators,
> both SQL and record level "<<", "#" and "!". I can understand
> replacing the record level stuff so HaskellDB code matches HList
> documentation,

While hacking, I was imagining a world where HList records were really well
documented, and users might be familiar with the HList record syntax before
they start using HaskellDB. This makes common syntax for records important.
If you think of records as something universal that will eventually
be provided by a good library, there's something to be said for HaskellDB not
inventing it's own syntax.

That well-documented world doesn't really exist yet -- the HList paper is
really good but there's not much beyond that. I was hoping to improve HList's
haddock when I get the chance, though.

As an aside, my hope is that GHC eventually gets some support for extensible
record syntax and/or first class labels, so there's no need for these band-aids.

> but the SQL operators are worrisome. How many conflicts
> are there? I'd rather see HList imported qualified rather than
> HaskellDB.

Yeah, having to qualify operators is nasty, I agree.

The main problem is HList's (.*.) (a.k.a. record extension) -- it's a
Record operation in HList and SQL multiplication in HaskellDB, and it's
basically indispensible when working with records.

There were other, probably less important conflicts: (.<.), (.+.) and (.-.).

> * I notice "emptyRecord" had to be added to the queries in
> TestCase.hs. Is it possible to define a new binary operator that does
> not have to end with "emptyRecord", but has the Nil terminator
> built-in? The (#) allowed that. Or is this a change introduced by not
> having to have columns in the same order as the DB?

I think the same "type Record r = RecNil -> r" trick would work.
That's not how the HList people chose to implement it (there's 
even a short comment in the paper: "We could also consider implicitly
terminated type sequences. Again, we require a terminating HNil
to avoid a mess."), but I'm pretty sure it could be added in
at the HaskellDB layer.

This has a similar flavor to the operator issue -- do we want to think
of HList as a library which we can encapsulate, and export their records
under a custom guise? Or do we want to adopt HList Records as a common
approach to records, and hope that syntax gets better eventually, through
changes to HList or to the language?

My original thinking was more the latter (partially because I'm interested in
using Records for more than just databases). I think there are pluses and
minuses on both sides, and I'm certainly happy to prepare patches which move in
the first direction if you think that's the best way to go right now.

> * Besides naming, do queries have to be rewritten? I am wondering if
> it's possible to create a Compatability module for older code that can
> export the new HList operators under the old HaskellDB names.

Compatibility for queries is doable, I think. I don't think it's
possible for table & label definitions.

Just FYI, while I was hacking, I had in mind some further changes which
would go father down the road of incompatibility -- that's for another email :)

> * Finally, I am not sure I understand the implications of removing
> the Attr type. Can you elaborate?

Not sure if I understand _all_ the implications, but here's my version:

I found it clunky in HaskellDB that there were two operators (.=.)
and (<<) depending on whether you were working at the Record level or 
DB attr level. There's a comment in the "HaskellDB Improved" paper:

> In order to make type inference of record selection easier and to get
> a more TRex-like syntax, we wrap the actual field labels in a label
> type which includes the type of the associated field value.

I'm not sure about the "TRex-like syntax" part, because the syntax
without Attr is only cosmetically different. When I got hacking, it
seemed to me that inference was doable without Attr. As an example:

> t1 <- table int_tbl
> project $ f02 << (t1 ! f02) .+. constant 1

The (t1 ! f02) .+. constant 1 gets inferred to be an Expr Int
thanks to the type of t1. So why does (<<) need to fix the type of type
of its second argument at all?

In all the cases I looked at, inferring the types from the table definitions
the expression operators was good enough. I looked closely at TestCases,
I might have missed some other example.

Thanks a lot for your feedback, I'm glad you're not disgusted yet :)

-Brian

> Justin
>
> On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz wrote:
> > Hi,
> >
> > It's come time to share something that I've been playing around with
> > recently:
> > a branch of HaskellDB which replaces the home-grown Record code with HList
> > records. It's definitely not ready for primetime, but I thought it'd be a
> > good
> > time to post the code and solicit some feedback from the community.
> >
> > HaskellDB the concept is very promising, but IMHO the code still falls short
> > of that promise. Hopefully this is a small step in the right direction --
> > the
> > advantages of using HList:
> > * Shared implementation of extensible records
> > * Additional features from HList
> > * Better error messages for record misuse
> > * "Lacks" predicates
> > * Simpler code
> >
> > As an example of how this can be better, a DB insert looks like so:
> >> insert db table $ constantRecord $
> >> film .=. "Munchie" .*.
> >> director .=. Just "Jim Wynorski" .*.
> >> emptyRecord
> > The columns need not appear in the same order as in the database. If you
> > forget
> > a column, you'll get "error: No instance for (Fail (FieldNotFound (Proxy
> > Director)))"
> > rather than an opaque error. Using the new "insertOpt" function, Maybe
> > columns
> > will default to Nothing rather than needing to be specified.
> >
> > The details:
> >
> > I haven't updated everything, but there's enough to run test/TestCases.hs
> > under Postgresql. TestCases is probably the best place to look for examples
> > of
> > the new syntax for now.
> >
> > HList had name conflicts with HaskellDB's SQL expression language
> > ((.*.), (.++.), etc.) My temporary band-aid is to move the expression
> > functions
> > to Database.HaskellDB.SqlExpr, and require people to import qualified.
> >
> > The Attr type is gone, columns labels are untyped now. I also replaced a
> > few instances of primitive type-level recursion with HMap/HMapOut. This
> > makes
> > the code simpler, and the type signatures more complex -- type families
> > would
> > help a lot here, I think.
> >
> > Feedback welcome! You can find my darcs tree at:
> >
> > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/haskelldb-hlist-20090516.tar.gz
> > It also requires minor changes to HList, available at:
> >
> > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz
> > I'll talk to the HList people about getting those merged.
> >
> > Thanks!
> >
> > Brian Bloniarz
> >
> >
> > ________________________________
> > Hotmail® has a new way to see what's up with your friends. Check it out.
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Has...@ha...
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >



_________________________________________________________________
Hotmail® goes with you. 
http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tutorial_Mobile1_052009

Re: [Haskelldb-users] Integrating haskelldb-th with DBDirect

[Artyom S. <art...@gm...>]

2009/5/28 Justin Bailey <jgb...@gm...>:
>> I wanted to create a database table exclusively through HaskellDB; don't
>> tell me I'm mad, please. :)
>>
>
> Another good idea but I think something that falls outside haskellDB.

Is the scope of the project outlined anywhere? It would be helpful to define it,
I suppose.

> You can create your own type-level info that represents what you want,
> though. You could use that along with a HaskellDB table definition to
> create the table w/ additional constraints.

I'll see what I can do.

> This paper on CoddFish, "Strong Types for Relational Databases
> (Functional Pearl)" by Alexandra Silva and Joost Visser,  has a great
> tutorial on type-level programming in the first two sections, worth
> reading if you want to go that route:
>
>  http://www.di.uminho.pt/~joostvisser/publications/StrongTypesForRDBs.pdf

Thanks for the link!

Cheers,
Artyom Shalkhakov.

Re: [Haskelldb-users] [Haskell-cafe] Request for feedback: HaskellDB + HList

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

Brian,

Thanks for all your hard work here. I have a few comments:

  * I am really uncomfortable with renaming the HaskellDB operators,
both SQL and record level  "<<", "#" and "!". I can understand
replacing the record level stuff so HaskellDB code matches HList
documentation, but the SQL operators are worrisome. How many conflicts
are there? I'd rather see HList imported qualified rather than
HaskellDB.
  * Besides naming, do queries have to be rewritten? I am wondering if
it's possible to create a Compatability module for older code that can
export the new HList operators under the old HaskellDB names.
  * I notice "emptyRecord" had to be added to the queries in
TestCase.hs. Is it possible to define a new binary operator that does
not have to end with "emptyRecord", but has the Nil terminator
built-in? The (#) allowed that. Or is this a change introduced by not
having to have columns in the same order as the DB?
  * Finally, I am not sure I understand the implications of removing
the Attr type. Can you elaborate?

Justin

On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz <ph...@ho...> wrote:
> Hi,
>
> It's come time to share something that I've been playing around with
> recently:
> a branch of HaskellDB which replaces the home-grown Record code with HList
> records. It's definitely not ready for primetime, but I thought it'd be a
> good
> time to post the code and solicit some feedback from the community.
>
> HaskellDB the concept is very promising, but IMHO the code still falls short
> of that promise. Hopefully this is a small step in the right direction --
> the
> advantages of using HList:
> * Shared implementation of extensible records
> * Additional features from HList
>   * Better error messages for record misuse
>   * "Lacks" predicates
> * Simpler code
>
> As an example of how this can be better, a DB insert looks like so:
>> insert db table $ constantRecord $
>>     film .=. "Munchie" .*.
>>     director .=. Just "Jim Wynorski" .*.
>>     emptyRecord
> The columns need not appear in the same order as in the database. If you
> forget
> a column, you'll get "error: No instance for (Fail (FieldNotFound (Proxy
> Director)))"
> rather than an opaque error. Using the new "insertOpt" function, Maybe
> columns
> will default to Nothing rather than needing to be specified.
>
> The details:
>
> I haven't updated everything, but there's enough to run test/TestCases.hs
> under Postgresql. TestCases is probably the best place to look for examples
> of
> the new syntax for now.
>
> HList had name conflicts with HaskellDB's SQL expression language
> ((.*.), (.++.), etc.) My temporary band-aid is to move the expression
> functions
> to Database.HaskellDB.SqlExpr, and require people to import qualified.
>
> The Attr type is gone, columns labels are untyped now. I also replaced a
> few instances of primitive type-level recursion with HMap/HMapOut. This
> makes
> the code simpler, and the type signatures more complex -- type families
> would
> help a lot here, I think.
>
> Feedback welcome! You can find my darcs tree at:
>
> http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/haskelldb-hlist-20090516.tar.gz
> It also requires minor changes to HList, available at:
>
> http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz
> I'll talk to the HList people about getting those merged.
>
> Thanks!
>
> Brian Bloniarz
>
>
> ________________________________
> Hotmail® has a new way to see what's up with your friends. Check it out.
> _______________________________________________
> Haskell-Cafe mailing list
> Has...@ha...
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

Re: [Haskelldb-users] Integrating haskelldb-th with DBDirect

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

On Tue, May 26, 2009 at 10:44 PM, Artyom Shalkhakov
<art...@gm...> wrote:
> At the moment, one has to provide a DB specification in terms
> of Database.HaskellDB.DBSpec, and the boilerplate code is generated
> automagically with DB/Direct. HaskellDB-TH on the other hand provides
> programmer with TH-specific functions while I think it would be much
> better if these functions operated over DB/Direct specifications: you give
> it a specification to get your boilerplate, as simple as that.
>

Cool idea! I don't have time to do it right now but I like it. It's a
great opportunity to learn template haskell if you want to get a patch
together :)

>
> I wanted to create a database table exclusively through HaskellDB; don't
> tell me I'm mad, please. :)
>

Another good idea but I think something that falls outside haskellDB.
You can create your own type-level info that represents what you want,
though. You could use that along with a HaskellDB table definition to
create the table w/ additional constraints.

This paper on CoddFish, "Strong Types for Relational Databases
(Functional Pearl)" by Alexandra Silva and Joost Visser,  has a great
tutorial on type-level programming in the first two sections, worth
reading if you want to go that route:

  http://www.di.uminho.pt/~joostvisser/publications/StrongTypesForRDBs.pdf

Justin

Re: [Haskelldb-users] strange/wrong NULL handling

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

Mathjis,

I am glad you are putting this much thought into haskelldb. My comments below.

On Tue, May 26, 2009 at 4:32 PM, Mathijs Kwik <blu...@gm...> wrote:
> Since this is not the current behaviour (nor wanted behaviour in most
> cases), the .==. operator probably means "where both fields are filled
> in (not NULL) and have the same value".
> In this case, comparing a field that _can_ be NULL to a field that
> can't be NULL should be allowed, since the meaning of .==. in this
> case dictates that all values will be not NULL.
>

Even though this is SQL-like behavior, it takes away some of what
HaskellDB gives you. Like Haskell, HaskellDB forces you to think about
types. Allowing .==. to match (Maybe expr) to (expr) is like allowing
null values for any object in Java or C#. It's convenient but
dangerous. HaskellDB takes the route that you need to explicitly deal
with the situation, even if SQL will silently fail for you. I think
you have pointed out a weakness with (Maybe expr) compared to (Maybe
expr), in that you need to know the SQL behavior for NULLs, but I
don't think that asks a lot.

Back to your point about .==., I could see an operator which behaves
the way you describe, but I don't think the meaning of .==. should be
changed.

> So the question seems to be:
> Do we want to abstract away from SQL by emulating haskell operators?
> (where .==. acts like ==)

...

> If we want to stay closer to SQL (.==. means sql =) ...

I think of HaskellDB taking a third route - a type-safe way to
generate SQL queries. When you write haskellDB code, you are thinking
of the query generated. In that case, .==. generates an equality
comparison in SQL. If you want to generate a null comparison, you use
isNull/fromNull. Still, the case of (constant Nothing .==. constant
Nothing) being translated to (NULL == NULL) is a wart. A small one,
though.

> Maybe I'm missing something here, I'm not a haskell expert, but it
> seems the current behaviour of the operators doesn't match SQL or
> haskell, which leaves us with some hybrid that is less flexible than
> both.
>
> Any thoughts?
>

For me, HaskellDB is a concise way to write SQL. It does not model a
relational DB. It leverages the Haskell type system to make it a
little easier to write mostly safe SQL. When combined with table
definitions generated from your database, it gives you a great way to
know when a query has broken because a table definition has changed.
The issues you have pointed out have merit, but I don't (yet) see a
significant benefit in solving them.

Justin

Re: [Haskelldb-users] Integrating haskelldb-th with DBDirect

[Artyom S. <art...@gm...>]

2009/5/26 Justin Bailey <jgb...@gm...>:
> Can you be more specific? How are they incompatible?

At the moment, one has to provide a DB specification in terms
of Database.HaskellDB.DBSpec, and the boilerplate code is generated
automagically with DB/Direct. HaskellDB-TH on the other hand provides
programmer with TH-specific functions while I think it would be much
better if these functions operated over DB/Direct specifications: you give
it a specification to get your boilerplate, as simple as that.

The opportunity to have database schema as a first-class value is appealing.

I would have already added that functionality to HaskellDB, but unfortunately,
I'm not familiar with Template Haskell yet.

>> In addition to that, how hard is it to add primary keys, foreign keys
>> and indices
>> annotations to HaskellDB?
>>
>
> There isn't support for that at the moment, but it's kind of outside
> the domain too. I would suggest layering that information on top of
> your schema through additional types or classes. What did you have in
> mind?

I wanted to create a database table exclusively through HaskellDB; don't
tell me I'm mad, please. :)

Cheers,
Artyom Shalkhakov.

[Haskelldb-users] strange/wrong NULL handling

[Mathijs K. <blu...@gm...>]

Hi,

I think there is a mismatch between how sql handles NULL and how
haskelldb handles it.

In haskelldb, fields that can be NULL are mapped to Maybe.
Comparing 2 fields that can be NULL using .==. will translate into
"where field1 = field2'
The sql = operator will not match any records where the field that is
being compared is NULL.

So if the .==. operator should mean something like "where the fields
have the exact same value", it doesn't work, since results that have
NULL for both the fields match this predicate but won't be returned.
The correct behaviour in that case would be "where field1 = field2 OR
(field1 IS NULL and field2 IS NULL)" for which there might be some
sql-helper-function.

Since this is not the current behaviour (nor wanted behaviour in most
cases), the .==. operator probably means "where both fields are filled
in (not NULL) and have the same value".
In this case, comparing a field that _can_ be NULL to a field that
can't be NULL should be allowed, since the meaning of .==. in this
case dictates that all values will be not NULL.

This example can probably be simplified by not looking at
field-comparison, but at simple constants.
If we want Nothing to be the representation of NULL, "field1 .==.
constant Nothing" should become "field1 IS NULL" in sql instead of
"field1 = NULL" (current behavior).

So the question seems to be:
Do we want to abstract away from SQL by emulating haskell operators?
(where .==. acts like ==)
If so, the operators and types should be extended somehow, so the
conversion/mapping will keep the meaning intact.
in that case:
"field1 .==. constant Nothing" should become "field1 IS NULL",
"field1 .==. field2" should become "where field1 = field2 OR (field1
IS NULL and field2 IS NULL)" and
"field1 .==. field2 .&&. notNull field1 .&&. notNull field2" should
become "where field1 = field2"

If we want to stay closer to SQL (.==. means sql =), some changes are
required to make Maybe Int comparable to Int, since sql's = operator
allows comparing a non-nullable field to a nullable one.
It's a bit more than just comparison operators, since sql allows other
stuff on nullable fields as well, like "select field1 * 3600 from
table1" so Maybe Int * Int -> Int

Maybe I'm missing something here, I'm not a haskell expert, but it
seems the current behaviour of the operators doesn't match SQL or
haskell, which leaves us with some hybrid that is less flexible than
both.

Any thoughts?

Mathijs

Re: [Haskelldb-users] Integrating haskelldb-th with DBDirect

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

On Mon, May 25, 2009 at 10:11 PM, Artyom Shalkhakov
<art...@gm...> wrote:
>
> Is there a way to integrate HaskellDB TH utilities with DBDirect specifications?
> Looks like they are incompatible right now. What I would like is a
> single place to
> specify database schema.

Can you be more specific? How are they incompatible?

>
> In addition to that, how hard is it to add primary keys, foreign keys
> and indices
> annotations to HaskellDB?
>

There isn't support for that at the moment, but it's kind of outside
the domain too. I would suggest layering that information on top of
your schema through additional types or classes. What did you have in
mind?

> Cheers,
> Artyom Shalkhakov.
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

[Haskelldb-users] Integrating haskelldb-th with DBDirect

[Artyom S. <art...@gm...>]

Hello,

Is there a way to integrate HaskellDB TH utilities with DBDirect specifications?
Looks like they are incompatible right now. What I would like is a
single place to
specify database schema.

In addition to that, how hard is it to add primary keys, foreign keys
and indices
annotations to HaskellDB?

Cheers,
Artyom Shalkhakov.

Re: [Haskelldb-users] simple question

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

Just like SQL, HaskellDB has the "isNull" operator. You can use that
to test if a column is null. I've found the best way to use HaskellDB
is to think how I would write a query in SQL, and then find the
equivalents in HaskellDB.

As for the optimized SQL, I agree. There isn't anything in the package
that you aren't seeing. If you see opportunity for improvements please
send a message or better yet, a patch!

On Sat, May 23, 2009 at 1:43 AM, Mathijs Kwik <blu...@gm...> wrote:
> Hi,
>
> Thanks for the quick reply.
> I was affraid that fromNull thing was gonna be needed indeed.
> While this works in this case, I'm not very happy with it.
> NULL != 0, and there might be cases where all possible values are
> allowed in a certain column (including 0).
> Isn't it possible to do this the other way around? (tell the other,
> mandatory field to become Just ...)
>
> Also, while I don't mind yet (since I like the idea of haskelldb very
> much), the so-called optimized sql is horrible :)
> Maybe some optimizations (things like using inner joins) should be
> turned on? How can I do this?
>
> Thanks again,
> Mathijs
>
>
>
>
> On Sat, May 23, 2009 at 6:37 AM, Justin Bailey <jgb...@gm...> wrote:
>> The error is telling you that you can't compare an "Int" to a "Maybe
>> Int", which makes sense becuse one column can hold NULL or an int,
>> while the other can only hold ints. Use the fromNull operator.
>> Assuming group_id is the column which can be null, I think you want:
>>
>>  let q = do { u <- table users; g <- table groups; restrict (g !
>> G.xid .==. fromNull (constant 0) (u ! U.group_id))}
>>
>> Justin
>>
>> On Fri, May 22, 2009 at 6:36 PM, Mathijs Kwik <blu...@gm...> wrote:
>>> Hi all,
>>>
>>> I finally got haskelldb working. It took some time, but (after many
>>> tries in the past) I got it.
>>> I'm playing around with querying and I have a simple question:
>>>
>>> I have a table with a foreign key that can be NULL.
>>> Now if I try to create an inner-join like restriction, I get a
>>> type-mismatch, which I can understand, but couldn't figure out how to
>>> solve it (it's a little late here :)
>>>
>>>  let q = do { u <- table users; g <- table groups; restrict (g!G.xid
>>> .==. u!U.group_id)}
>>>
>>> <interactive>:1:4:
>>>    Couldn't match expected type `Int'
>>>           against inferred type `Maybe Int'
>>>      Expected type: Expr Int
>>>      Inferred type: Expr (Maybe Int)
>>>    When using functional dependencies to combine
>>>      Select (Attr f a) (Rel r) (Expr a),
>>>        arising from the dependency `f r -> a'
>>>        in the instance declaration at <no location info>
>>>      Select (Attr U.Group_id (Maybe Int)) (Rel U.Users) (Expr Int),
>>>        arising from a use of `!' at <interactive>:1:97-107
>>>    When generalising the type(s) for `q'
>>>
>>> What would be the correct way to fix this?
>>>
>>> Thanks,
>>> Mathijs
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>> is a gathering of tech-side developers & brand creativity professionals. Meet
>>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>>> _______________________________________________
>>> Haskelldb-users mailing list
>>> Has...@li...
>>> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>>>
>>
>

Re: [Haskelldb-users] simple question

[Mathijs K. <blu...@gm...>]

Hi,

Thanks for the quick reply.
I was affraid that fromNull thing was gonna be needed indeed.
While this works in this case, I'm not very happy with it.
NULL != 0, and there might be cases where all possible values are
allowed in a certain column (including 0).
Isn't it possible to do this the other way around? (tell the other,
mandatory field to become Just ...)

Also, while I don't mind yet (since I like the idea of haskelldb very
much), the so-called optimized sql is horrible :)
Maybe some optimizations (things like using inner joins) should be
turned on? How can I do this?

Thanks again,
Mathijs




On Sat, May 23, 2009 at 6:37 AM, Justin Bailey <jgb...@gm...> wrote:
> The error is telling you that you can't compare an "Int" to a "Maybe
> Int", which makes sense becuse one column can hold NULL or an int,
> while the other can only hold ints. Use the fromNull operator.
> Assuming group_id is the column which can be null, I think you want:
>
>  let q = do { u <- table users; g <- table groups; restrict (g !
> G.xid .==. fromNull (constant 0) (u ! U.group_id))}
>
> Justin
>
> On Fri, May 22, 2009 at 6:36 PM, Mathijs Kwik <blu...@gm...> wrote:
>> Hi all,
>>
>> I finally got haskelldb working. It took some time, but (after many
>> tries in the past) I got it.
>> I'm playing around with querying and I have a simple question:
>>
>> I have a table with a foreign key that can be NULL.
>> Now if I try to create an inner-join like restriction, I get a
>> type-mismatch, which I can understand, but couldn't figure out how to
>> solve it (it's a little late here :)
>>
>>  let q = do { u <- table users; g <- table groups; restrict (g!G.xid
>> .==. u!U.group_id)}
>>
>> <interactive>:1:4:
>>    Couldn't match expected type `Int'
>>           against inferred type `Maybe Int'
>>      Expected type: Expr Int
>>      Inferred type: Expr (Maybe Int)
>>    When using functional dependencies to combine
>>      Select (Attr f a) (Rel r) (Expr a),
>>        arising from the dependency `f r -> a'
>>        in the instance declaration at <no location info>
>>      Select (Attr U.Group_id (Maybe Int)) (Rel U.Users) (Expr Int),
>>        arising from a use of `!' at <interactive>:1:97-107
>>    When generalising the type(s) for `q'
>>
>> What would be the correct way to fix this?
>>
>> Thanks,
>> Mathijs
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> _______________________________________________
>> Haskelldb-users mailing list
>> Has...@li...
>> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>>
>

Re: [Haskelldb-users] simple question

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

The error is telling you that you can't compare an "Int" to a "Maybe
Int", which makes sense becuse one column can hold NULL or an int,
while the other can only hold ints. Use the fromNull operator.
Assuming group_id is the column which can be null, I think you want:

  let q = do { u <- table users; g <- table groups; restrict (g !
G.xid .==. fromNull (constant 0) (u ! U.group_id))}

Justin

On Fri, May 22, 2009 at 6:36 PM, Mathijs Kwik <blu...@gm...> wrote:
> Hi all,
>
> I finally got haskelldb working. It took some time, but (after many
> tries in the past) I got it.
> I'm playing around with querying and I have a simple question:
>
> I have a table with a foreign key that can be NULL.
> Now if I try to create an inner-join like restriction, I get a
> type-mismatch, which I can understand, but couldn't figure out how to
> solve it (it's a little late here :)
>
>  let q = do { u <- table users; g <- table groups; restrict (g!G.xid
> .==. u!U.group_id)}
>
> <interactive>:1:4:
>    Couldn't match expected type `Int'
>           against inferred type `Maybe Int'
>      Expected type: Expr Int
>      Inferred type: Expr (Maybe Int)
>    When using functional dependencies to combine
>      Select (Attr f a) (Rel r) (Expr a),
>        arising from the dependency `f r -> a'
>        in the instance declaration at <no location info>
>      Select (Attr U.Group_id (Maybe Int)) (Rel U.Users) (Expr Int),
>        arising from a use of `!' at <interactive>:1:97-107
>    When generalising the type(s) for `q'
>
> What would be the correct way to fix this?
>
> Thanks,
> Mathijs
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

[Haskelldb-users] simple question

[Mathijs K. <blu...@gm...>]

Hi all,

I finally got haskelldb working. It took some time, but (after many
tries in the past) I got it.
I'm playing around with querying and I have a simple question:

I have a table with a foreign key that can be NULL.
Now if I try to create an inner-join like restriction, I get a
type-mismatch, which I can understand, but couldn't figure out how to
solve it (it's a little late here :)

 let q = do { u <- table users; g <- table groups; restrict (g!G.xid
.==. u!U.group_id)}

<interactive>:1:4:
    Couldn't match expected type `Int'
           against inferred type `Maybe Int'
      Expected type: Expr Int
      Inferred type: Expr (Maybe Int)
    When using functional dependencies to combine
      Select (Attr f a) (Rel r) (Expr a),
        arising from the dependency `f r -> a'
        in the instance declaration at <no location info>
      Select (Attr U.Group_id (Maybe Int)) (Rel U.Users) (Expr Int),
        arising from a use of `!' at <interactive>:1:97-107
    When generalising the type(s) for `q'

What would be the correct way to fix this?

Thanks,
Mathijs

Re: [Haskelldb-users] [Haskell-cafe] Request for feedback: HaskellDB + HList

[Brian B. <ph...@ho...>]

Hi Justin,

I updated my changes to apply against that repo, thanks for 
the pointer. Cool to see new changes to haskelldb, especially
all the new unit tests!

You can find my updated repo at:
http://patch-tag.com/r/haskelldb-hlist
Re-reading your email now, I see you asked for a patch, but seeing
patch-tag for the first time I got excited and uploaded a whole new
repo, whoops.

Anyway, I had to do some minor surgery to update to the new
version -- everything compiles, but I haven't tested much beyond that
yet. Let me know if you have any questions.

Thanks,
-Brian

> I like the direction you are going. I looked into using HList a year
> or so ago and I wasn't quite up to it.  The latest (unreleased)
> version of HaskellDB is on patch-tag at
> http://patch-tag.com/r/haskelldb/snapshot/current/content/pretty.
> Would you mind creating a patch file against that for easier review? I
> won't commit it until you say its ready but I'd like to see what
> changes you have made.
> 
> No announcement has been made but I took over maintainership from
> Bjorn a few months ago. I hope to get a 1.0 release of HaskellDB out
> this summer, and having something new like this in it would be pretty
> sweet.
> 
> On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz <ph...@ho...> wrote:
> > Hi,
> >
> > It's come time to share something that I've been playing around with
> > recently:
> > a branch of HaskellDB which replaces the home-grown Record code with HList
> > records. It's definitely not ready for primetime, but I thought it'd be a
> > good
> > time to post the code and solicit some feedback from the community.
> >
> > HaskellDB the concept is very promising, but IMHO the code still falls short
> > of that promise. Hopefully this is a small step in the right direction --
> > the
> > advantages of using HList:
> > * Shared implementation of extensible records
> > * Additional features from HList
> >   * Better error messages for record misuse
> >   * "Lacks" predicates
> > * Simpler code
> >
> > As an example of how this can be better, a DB insert looks like so:
> >> insert db table $ constantRecord $
> >>     film .=. "Munchie" .*.
> >>     director .=. Just "Jim Wynorski" .*.
> >>     emptyRecord
> > The columns need not appear in the same order as in the database. If you
> > forget
> > a column, you'll get "error: No instance for (Fail (FieldNotFound (Proxy
> > Director)))"
> > rather than an opaque error. Using the new "insertOpt" function, Maybe
> > columns
> > will default to Nothing rather than needing to be specified.
> >
> > The details:
> >
> > I haven't updated everything, but there's enough to run test/TestCases.hs
> > under Postgresql. TestCases is probably the best place to look for examples
> > of
> > the new syntax for now.
> >
> > HList had name conflicts with HaskellDB's SQL expression language
> > ((.*.), (.++.), etc.) My temporary band-aid is to move the expression
> > functions
> > to Database.HaskellDB.SqlExpr, and require people to import qualified.
> >
> > The Attr type is gone, columns labels are untyped now. I also replaced a
> > few instances of primitive type-level recursion with HMap/HMapOut. This
> > makes
> > the code simpler, and the type signatures more complex -- type families
> > would
> > help a lot here, I think.
> >
> > Feedback welcome! You can find my darcs tree at:
> >
> > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/haskelldb-hlist-20090516.tar.gz
> > It also requires minor changes to HList, available at:
> >
> > http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz
> > I'll talk to the HList people about getting those merged.
> >
> > Thanks!
> >
> > Brian Bloniarz
> >
> >
> > ________________________________
> > Hotmail® has a new way to see what's up with your friends. Check it out.
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Has...@ha...
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >

_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009

Re: [Haskelldb-users] [Haskell-cafe] Request for feedback: HaskellDB + HList

[Brian B. <ph...@ho...>]

_________________________________________________________________
Insert movie times and more without leaving Hotmail®.
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd1_052009

Re: [Haskelldb-users] [Haskell-cafe] Request for feedback: HaskellDB + HList

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

I like the direction you are going. I looked into using HList a year
or so ago and I wasn't quite up to it.  The latest (unreleased)
version of HaskellDB is on patch-tag at
http://patch-tag.com/r/haskelldb/snapshot/current/content/pretty.
Would you mind creating a patch file against that for easier review? I
won't commit it until you say its ready but I'd like to see what
changes you have made.

No announcement has been made but I took over maintainership from
Bjorn a few months ago. I hope to get a 1.0 release of HaskellDB out
this summer, and having something new like this in it would be pretty
sweet.

On Sat, May 16, 2009 at 3:08 PM, Brian Bloniarz <ph...@ho...> wrote:
> Hi,
>
> It's come time to share something that I've been playing around with
> recently:
> a branch of HaskellDB which replaces the home-grown Record code with HList
> records. It's definitely not ready for primetime, but I thought it'd be a
> good
> time to post the code and solicit some feedback from the community.
>
> HaskellDB the concept is very promising, but IMHO the code still falls short
> of that promise. Hopefully this is a small step in the right direction --
> the
> advantages of using HList:
> * Shared implementation of extensible records
> * Additional features from HList
>   * Better error messages for record misuse
>   * "Lacks" predicates
> * Simpler code
>
> As an example of how this can be better, a DB insert looks like so:
>> insert db table $ constantRecord $
>>     film .=. "Munchie" .*.
>>     director .=. Just "Jim Wynorski" .*.
>>     emptyRecord
> The columns need not appear in the same order as in the database. If you
> forget
> a column, you'll get "error: No instance for (Fail (FieldNotFound (Proxy
> Director)))"
> rather than an opaque error. Using the new "insertOpt" function, Maybe
> columns
> will default to Nothing rather than needing to be specified.
>
> The details:
>
> I haven't updated everything, but there's enough to run test/TestCases.hs
> under Postgresql. TestCases is probably the best place to look for examples
> of
> the new syntax for now.
>
> HList had name conflicts with HaskellDB's SQL expression language
> ((.*.), (.++.), etc.) My temporary band-aid is to move the expression
> functions
> to Database.HaskellDB.SqlExpr, and require people to import qualified.
>
> The Attr type is gone, columns labels are untyped now. I also replaced a
> few instances of primitive type-level recursion with HMap/HMapOut. This
> makes
> the code simpler, and the type signatures more complex -- type families
> would
> help a lot here, I think.
>
> Feedback welcome! You can find my darcs tree at:
>
> http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/haskelldb-hlist-20090516.tar.gz
> It also requires minor changes to HList, available at:
>
> http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz
> I'll talk to the HList people about getting those merged.
>
> Thanks!
>
> Brian Bloniarz
>
>
> ________________________________
> Hotmail® has a new way to see what's up with your friends. Check it out.
> _______________________________________________
> Haskell-Cafe mailing list
> Has...@ha...
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

[Haskelldb-users] Request for feedback: HaskellDB + HList

[Brian B. <ph...@ho...>]

Hi,

It's come time to share something that I've been playing around with recently:
a branch of HaskellDB which replaces the home-grown Record code with HList
records. It's definitely not ready for primetime, but I thought it'd be a good
time to post the code and solicit some feedback from the community.

HaskellDB the concept is very promising, but IMHO the code still falls short
of that promise. Hopefully this is a small step in the right direction -- the
advantages of using HList:
* Shared implementation of extensible records
* Additional features from HList
  * Better error messages for record misuse
  * "Lacks" predicates 
* Simpler code

As an example of how this can be better, a DB insert looks like so:
> insert db table $ constantRecord $
>     film .=. "Munchie" .*.
>     director .=. Just "Jim Wynorski" .*.
>     emptyRecord
The columns need not appear in the same order as in the database. If you forget
a column, you'll get "error: No instance for (Fail (FieldNotFound (Proxy Director)))"
rather than an opaque error. Using the new "insertOpt" function, Maybe columns
will default to Nothing rather than needing to be specified.

The details:

I haven't updated everything, but there's enough to run test/TestCases.hs
under Postgresql. TestCases is probably the best place to look for examples of
the new syntax for now.

HList had name conflicts with HaskellDB's SQL expression language
((.*.), (.++.), etc.) My temporary band-aid is to move the expression functions
to Database.HaskellDB.SqlExpr, and require people to import qualified.

The Attr type is gone, columns labels are untyped now. I also replaced a 
few instances of primitive type-level recursion with HMap/HMapOut. This makes
the code simpler, and the type signatures more complex -- type families would
help a lot here, I think.

Feedback welcome! You can find my darcs tree at:
    http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/haskelldb-hlist-20090516.tar.gz
It also requires minor changes to HList, available at:
    http://mysite.verizon.net/vzewxzuh/sitebuildercontent/sitebuilderfiles/hlist-20090516.tar.gz
I'll talk to the HList people about getting those merged.

Thanks!

Brian Bloniarz


_________________________________________________________________
Hotmail® has a new way to see what's up with your friends.
http://windowslive.com/Tutorial/Hotmail/WhatsNew?ocid=TXT_TAGLM_WL_HM_Tutorial_WhatsNew1_052009

Re: [Haskelldb-users] Lazy version of query

[Bjorn B. <bj...@br...>]

There was a lazy query function in haskellDB before, but it never
really worked well. There were problems with concurrent queries and
with freeing the resources used by the query when done.

/Bjorn

On Fri, May 1, 2009 at 15:52, Justin Bailey <jgb...@gm...> wrote:
> In short, no. That is really dependent on the underlying database
> library more than haskellDB. You might want to look at Takusen for
> safe, constant-resource queries.
>
> On Fri, May 1, 2009 at 3:37 AM, Guenther Schmidt <gue...@we...> wrote:
>> Hi all,
>>
>> is it possible to create a "lazy" version of query?
>>
>> Günther
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>> _______________________________________________
>> Haskelldb-users mailing list
>> Has...@li...
>> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

Re: [Haskelldb-users] About unique

[Guenther S. <gue...@we...>]

Hi Justin,


this is really very frustrating: Every time I think I spotted a bug, a 
flaw, or a deficiency it just turns out to be a mistake in my thinking!

This thing is perfect, apparently, awesome, great, wonderful!

It certainly saved my ass with this project.

Thanks for pointing out subQuery, I hadn't come across that one yet.

Many, many thanks

Günther



Justin Bailey schrieb:
> I came up with this SQL to represent what you want:
>
>   select col1, count(col2)
>   from (select col1, col2
>            from table1
>            group by col1, col2)
>   group by col1
>
> You need to use the "subQuery" operator:
>
>   query = do
>     inner <- subQuery $ do
>       t1 <- table table1
>       unique
>       project $ table1 ! col1 << col1,
>                     table1 ! col2 << col2
>     project $ t1 ! col1 << col1 #
>                  t2 ! col2 << count(col2)
>
> I think that would do it. Did you figure it out?
>
> On Fri, May 1, 2009 at 10:41 AM, Guenther Schmidt <gue...@we...> wrote:
>   
>> Hi Justin,
>>
>> lets say in the inner query I select 2 columns. There will be some
>> duplicates due to identical value pairs in cols 1 & 2.
>>
>> I will eventually only select col 1 and the count of *distinct* pairs of col
>> 1 & 2.
>>
>> Using:
>>
>>   select col1, count (col2) ...   naturally includes the duplicates, which I
>> don't want.
>>
>> How can I do that?
>>
>> Günther
>>
>>
>>
>>     

Re: [Haskelldb-users] Unicode and Umlauts

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

I'm not sure what might be going on but can you send an example? I
would be good to have for testing purposes.

On Sun, May 3, 2009 at 5:43 PM, Guenther Schmidt <gue...@we...> wrote:
> Hi all,
>
> I'm using haskelldb with HDBC backend. The only problem I don't
> understand is that my umlauts get garbled on the way in and the way out.
> Using HDBC directly works fine, so I wonder if haskelldb does some sort
> of transformation when communication with the driver.
>
> Günther
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

[Haskelldb-users] Unicode and Umlauts

[Guenther S. <gue...@we...>]

Hi all,

I'm using haskelldb with HDBC backend. The only problem I don't 
understand is that my umlauts get garbled on the way in and the way out. 
Using HDBC directly works fine, so I wonder if haskelldb does some sort 
of transformation when communication with the driver.

Günther

Re: [Haskelldb-users] About unique

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

If you want select distinct, "unique" won't give it. The library does
that through Group By instead. Can you be more specific?

On Fri, May 1, 2009 at 10:04 AM, Guenther Schmidt <gue...@we...> wrote:
> Hi guys,
>
> I can honestly say that I don't have a clue on how to use it. Or rather
> where to place it. Or rather to use it to actually get a "select
> distinct".
> Whenever I did use it, it always grouped at the innermost level.
> How can you determine the level *where* the grouping takes place?
>
> Günther
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>