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

Re: [Haskelldb-users] Identity columns

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

In that case I would use the database driver's support for returning
auto-increment columns. You'll want to look at the specific library
you are using to see how to do that. The HaskellDB interface may hide
that from you - I'm not sure. You may want to use  HaskellDB just to
generate the appropriate SQL, which you then execute using the DB
library.

On Thu, Sep 17, 2009 at 8:05 AM, Colin Paul Adams
<co...@co...> wrote:
>>>>>> "Justin" == Justin Bailey <jgb...@gm...> writes:
>
>    Justin> If you want the numbers generated in Haskell, consider the
>    Justin> 'value-supply' library on Hackage. It allows you to create
>    Justin> a generator which you can pass around and which will
>    Justin> generate a unique number for you, on demand.
>
> I suppose that might help a little. I will only have to read the
> existing maximum value from the table when restarting the application,
> instead of on every insert.
>
>    Justin> On Thu, Sep 17, 2009 at 7:45 AM, Colin Paul Adams
>    Justin> <co...@co...> wrote:
>    >>>>>>> "Justin" == Justin Bailey <jgb...@gm...> writes:
>    >>
>    >>    Justin> Not specifically. What are you looking for?
>    >>
>    >> I want an identity column, to uniquely number the rows of a
>    >> table (and use that number within the application).
>    >>
>    >>    Justin> <co...@co...> wrote:
>    >>    >> Does HaskellDB support identity columns (auto-incremented
>    >>    >> integers)?  -- Colin Adams Preston Lancashire
>    >>
>
>
> --
> Colin Adams
> Preston Lancashire
>

Re: [Haskelldb-users] Identity columns

[Colin P. A. <co...@co...>]

>>>>> "Justin" == Justin Bailey <jgb...@gm...> writes:

    Justin> If you want the numbers generated in Haskell, consider the
    Justin> 'value-supply' library on Hackage. It allows you to create
    Justin> a generator which you can pass around and which will
    Justin> generate a unique number for you, on demand.

I suppose that might help a little. I will only have to read the
existing maximum value from the table when restarting the application,
instead of on every insert.

    Justin> On Thu, Sep 17, 2009 at 7:45 AM, Colin Paul Adams
    Justin> <co...@co...> wrote:
    >>>>>>> "Justin" == Justin Bailey <jgb...@gm...> writes:
    >> 
    >>    Justin> Not specifically. What are you looking for?
    >> 
    >> I want an identity column, to uniquely number the rows of a
    >> table (and use that number within the application).
    >> 
    >>    Justin> <co...@co...> wrote:
    >>    >> Does HaskellDB support identity columns (auto-incremented
    >>    >> integers)?  -- Colin Adams Preston Lancashire
    >> 


-- 
Colin Adams
Preston Lancashire

Re: [Haskelldb-users] Identity columns

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

If you want the numbers generated in Haskell, consider the
'value-supply' library on Hackage. It allows you to create a generator
which you can pass around and which will generate a unique number for
you, on demand.


On Thu, Sep 17, 2009 at 7:45 AM, Colin Paul Adams
<co...@co...> wrote:
>>>>>> "Justin" == Justin Bailey <jgb...@gm...> writes:
>
>    Justin> Not specifically. What are you looking for?
>
> I want an identity column, to uniquely number the rows of a table (and
> use that number within the application).
>
>    Justin> <co...@co...> wrote:
>    >> Does HaskellDB support identity columns (auto-incremented
>    >> integers)?
> --
> Colin Adams
> Preston Lancashire
>

Re: [Haskelldb-users] Identity columns

[Colin P. A. <co...@co...>]

>>>>> "Justin" == Justin Bailey <jgb...@gm...> writes:

    Justin> Not specifically. What are you looking for? 

I want an identity column, to uniquely number the rows of a table (and
use that number within the application).

    Justin> <co...@co...> wrote:
    >> Does HaskellDB support identity columns (auto-incremented
    >> integers)? 
-- 
Colin Adams
Preston Lancashire

Re: [Haskelldb-users] Identity columns

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

Not specifically. What are you looking for?

On Thu, Sep 17, 2009 at 2:30 AM, Colin Paul Adams
<co...@co...> wrote:
> Does HaskellDB support identity columns (auto-incremented integers)?
> --
> Colin Adams
> Preston Lancashire
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

[Haskelldb-users] Identity columns

[Colin P. A. <co...@co...>]

Does HaskellDB support identity columns (auto-incremented integers)?
-- 
Colin Adams
Preston Lancashire

Re: [Haskelldb-users] Latest patch to HaskellDB

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

I should also mention that the latest patch to HaskellDB breaks
backward comparability in a big way. If you don't want to go through a
painful update, I suggest staying with the current version of
HaskellDB (v 0.12) for now. The UPGRADE file will contain directions
on whats needed to update existing programs, but it is very raw at the
moment.

Some of the major stuff:

  * Regenerate all DBDirect-generated modules - they will no longer compile.

  * Operators which have changed:

    (!) becomes (.!.)
    (<<) becomes (.=.)
    (#) becomes (.*.)
    (field <<- value) becomes (field .=. constant value)

  * emptyRecord needs to be added to the end of all projections:

      project $ TInt.f02 << count(s ! TInt.f02)

  becomes

      project $ TInt.f02 .=. count(s .!. TInt.f02) .*. emptyRecord



On Wed, Sep 16, 2009 at 9:17 AM, Justin Bailey <jgb...@gm...> wrote:
> I've just pushed an update to HaskellDB to the repo and I'm hoping to
> get feedback and/or patches:
>
>  * Thanks to Brian Bloniarz, HaskellDB now uses the HList library to
> represent queries. An upgrade guide will be provided. The file UPGRADE
> in the root directory is very rough but describes changes necessary.
>
>  * All cabal files have been updated to v 1.0.
>
>  * HUnit tests have been updated to reflect new changes.
>
>  * A PrintQuery module, for debugging intermediate query forms, has been added.
>
>  * HDBC driver support has been updated to support HDBC 2.0.
>
>  * Versioning updates to require the Haskell Platform, 2009.2, have been made.
>
> HaskellDB isn't quite ready for another release yet, but more to come
> on that soon.
>
> Justin
>

[Haskelldb-users] Latest patch to HaskellDB

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

I've just pushed an update to HaskellDB to the repo and I'm hoping to
get feedback and/or patches:

  * Thanks to Brian Bloniarz, HaskellDB now uses the HList library to
represent queries. An upgrade guide will be provided. The file UPGRADE
in the root directory is very rough but describes changes necessary.

  * All cabal files have been updated to v 1.0.

  * HUnit tests have been updated to reflect new changes.

  * A PrintQuery module, for debugging intermediate query forms, has been added.

  * HDBC driver support has been updated to support HDBC 2.0.

  * Versioning updates to require the Haskell Platform, 2009.2, have been made.

HaskellDB isn't quite ready for another release yet, but more to come
on that soon.

Justin

Re: [Haskelldb-users] Writing signatures for record-manipulating functions

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

Colin,

HaskellDB is going to give you some complicated type signatures - its
a side-effect of using the type system to enforce things like field
membership. You could just do the record selection in the
topLevelGalleries function:

>  return $ map (\rec -> newGallery (rec DB.! galleryName) (rec DB.! parentGalleryName) (rec DB.! readImageCapabilityName)  (rec DB.! uploadImageCapabilityName)  (rec DB.! administerGalleryCapabilityName)) rs

> newGallery name parent read upload admin = Gallery name parent read upload admin

On Tue, Sep 15, 2009 at 3:20 AM, Colin Paul Adams
<co...@co...> wrote:
> I have the following code:
>
>
> -- | Get list of all top-level galleries from database
> topLevelGalleries :: DB.Database -> IO [Gallery]
> topLevelGalleries db = do
>  let q = do
>        t <- DB.table galleryTable
>        DB.restrict (DB.isNull $ t DB.! parentGalleryName)
>        return t
>  rs <- DB.query db q
>  return $ map newGallery rs
>
> --newGallery :: DB.Record vr -> Gallery
> newGallery rec = Gallery (rec DB.! galleryName) (rec DB.! parentGalleryName) (rec DB.! readImageCapabilityName)  (rec DB.! uploadImageCapabilityName)  (rec DB.! administerGalleryCapabilityName)
>
>
> The reason the signature for newGallery is commented out is that it is
> very hard to write. I fired up ghci and did a :t newGallery. I got:
>
> newGallery
>  :: (Database.HaskellDB.HDBRec.Select
>        (Database.HaskellDB.Query.Attr
>           Database.GalleryTable.GalleryName String)
>        r
>        String,
>      Database.HaskellDB.HDBRec.Select
>        (Database.HaskellDB.Query.Attr
>           Database.GalleryTable.ParentGalleryName (Maybe String))
>        r
>        (Maybe String),
>      Database.HaskellDB.HDBRec.Select
>        (Database.HaskellDB.Query.Attr
>           Database.GalleryTable.ReadImageCapabilityName String)
>        r
>        String,
>      Database.HaskellDB.HDBRec.Select
>        (Database.HaskellDB.Query.Attr
>           Database.GalleryTable.UploadImageCapabilityName String)
>        r
>        String,
>      Database.HaskellDB.HDBRec.Select
>        (Database.HaskellDB.Query.Attr
>           Database.GalleryTable.AdministerGalleryCapabilityName String)
>        r
>        String) =>
>     r -> Dragonfly.ImageGallery.ImageGallery.Gallery
>
> Well, that's a bit of a mouthful. I don't really want to type that in.
>
> I would have hoped that somwhere there was a type definition generated
> from this from the DBInfo, but I can't find it. Any suggestions as to
> where to look?
> --
> Colin Adams
> Preston Lancashire
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

Re: [Haskelldb-users] [Haskell-cafe] haskelldb and Debian

[Joachim B. <no...@de...>]

Hi,

Am Dienstag, den 08.09.2009, 09:44 +0200 schrieb Joachim Breitner:
> Am Montag, den 07.09.2009, 12:51 -0700 schrieb Justin Bailey:
> > I am maintaing the haskelldb package and it is definitely alive and
> > well. I don't have a Debian install to test on, but I am glad to help
> > get things compiling. See my detailed answers below:
> 
> Great to hear that. I’ll upgrade the haskelldb package 0.12 soon (or
> someone else from the Debian Haskell Group), and package the
> haskelldb-odbc-* packages.

Just FYI: haskelldb-0.12 has been packaged and uploaded, along with the
hdbc drivers. The hsql drivers are removed from Debian.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  no...@de... | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: no...@jo... | http://people.debian.org/~nomeata

[Haskelldb-users] Writing signatures for record-manipulating functions

[Colin P. A. <co...@co...>]

I have the following code:

      
-- | Get list of all top-level galleries from database
topLevelGalleries :: DB.Database -> IO [Gallery]
topLevelGalleries db = do
  let q = do
        t <- DB.table galleryTable
        DB.restrict (DB.isNull $ t DB.! parentGalleryName)
        return t
  rs <- DB.query db q
  return $ map newGallery rs

--newGallery :: DB.Record vr -> Gallery
newGallery rec = Gallery (rec DB.! galleryName) (rec DB.! parentGalleryName) (rec DB.! readImageCapabilityName)  (rec DB.! uploadImageCapabilityName)  (rec DB.! administerGalleryCapabilityName) 


The reason the signature for newGallery is commented out is that it is
very hard to write. I fired up ghci and did a :t newGallery. I got:

newGallery
  :: (Database.HaskellDB.HDBRec.Select
        (Database.HaskellDB.Query.Attr
           Database.GalleryTable.GalleryName String)
        r
        String,
      Database.HaskellDB.HDBRec.Select
        (Database.HaskellDB.Query.Attr
           Database.GalleryTable.ParentGalleryName (Maybe String))
        r
        (Maybe String),
      Database.HaskellDB.HDBRec.Select
        (Database.HaskellDB.Query.Attr
           Database.GalleryTable.ReadImageCapabilityName String)
        r
        String,
      Database.HaskellDB.HDBRec.Select
        (Database.HaskellDB.Query.Attr
           Database.GalleryTable.UploadImageCapabilityName String)
        r
        String,
      Database.HaskellDB.HDBRec.Select
        (Database.HaskellDB.Query.Attr
           Database.GalleryTable.AdministerGalleryCapabilityName String)
        r
        String) =>
     r -> Dragonfly.ImageGallery.ImageGallery.Gallery

Well, that's a bit of a mouthful. I don't really want to type that in.

I would have hoped that somwhere there was a type definition generated
from this from the DBInfo, but I can't find it. Any suggestions as to
where to look?
-- 
Colin Adams
Preston Lancashire

Re: [Haskelldb-users] [Haskell-cafe] haskelldb and Debian

[Joachim B. <no...@de...>]

Hi Justin,

Am Montag, den 07.09.2009, 12:51 -0700 schrieb Justin Bailey:

> I am maintaing the haskelldb package and it is definitely alive and
> well. I don't have a Debian install to test on, but I am glad to help
> get things compiling. See my detailed answers below:

Great to hear that. I’ll upgrade the haskelldb package 0.12 soon (or
someone else from the Debian Haskell Group), and package the
haskelldb-odbc-* packages.

> On Mon, Sep 7, 2009 at 11:04 AM, Joachim Breitner <no...@de...>
> wrote:
>          * Are the haskelldb-hsql-* and haskelldb-dynamic packages
>         still
>         maintained? If so, is there a release expected soon? If not,
>         we will
>         have to remove these from Debian.
> These are not maintained any more. 

Ok, I see no point in having these in Debian any more, and I’ll request
removal. Any objections someone?

>          * Without the hsql-* packages, the haskelldb package itself
>         is useless,
>         correct? So we need to package the hdbc series. Are these
>         maintained
>         actively?
> Yes, the haskelldb-hdbc is still maintained and will continue to be as
> much as I am able. I belive I updated at least haskelldb-hdbc and
> haskelldb-hdbc-postgres to work with the 2.0 release of HDBC. 
>  
> Like I said, I don't have a Debian install readily accessible to build
> these but I am glad to help. If need be, I am sure I can get a VM
> image and build myself but finding the time coudl be hard.

Don’t worry, as long as you make sure your packages build with the
latest ghc and appear on hackage, and are responsive about bug reports,
we are fully satisfied with you as the upstream developer :-)

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  no...@de... | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: no...@jo... | http://people.debian.org/~nomeata

Re: [Haskelldb-users] [Haskell-cafe] haskelldb and Debian

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

Joachim,

I am maintaing the haskelldb package and it is definitely alive and well. I
don't have a Debian install to test on, but I am glad to help get things
compiling. See my detailed answers below:

On Mon, Sep 7, 2009 at 11:04 AM, Joachim Breitner <no...@de...>wrote:

>
>  * Are the haskelldb-hsql-* and haskelldb-dynamic packages still
> maintained? If so, is there a release expected soon? If not, we will
> have to remove these from Debian.
>
These are not maintained any more.


>  * Without the hsql-* packages, the haskelldb package itself is useless,
> correct? So we need to package the hdbc series. Are these maintained
> actively?
>
Yes, the haskelldb-hdbc is still maintained and will continue to be as much
as I am able. I belive I updated at least haskelldb-hdbc and
haskelldb-hdbc-postgres to work with the 2.0 release of HDBC.

Like I said, I don't have a Debian install readily accessible to build these
but I am glad to help. If need be, I am sure I can get a VM image and build
myself but finding the time coudl be hard.


>  * Anything else to consider?
>
> I guess just making sure haskelldb-hdbc and haskelldb-hdbc-postgres builds
against the latest haskell platform release.

Justin

p.s. Please send replies only to haskelldb-users.

[Haskelldb-users] haskelldb and Debian

[Joachim B. <no...@de...>]

Hi Haskell-DB-interested people,

we are still on our way to get the Haskell coverage on Debian back in a
good shape. One of the open issues is haskelldb, haskelldb-dynamic and
haskelldb-hsql-*. All of these are on 0.10 [1] and do not build with
ghc-6.10. It seems that at least haskelldb itself has a 0.12 which does
build, but the others do not. Thus, some questions:

 * Are the haskelldb-hsql-* and haskelldb-dynamic packages still
maintained? If so, is there a release expected soon? If not, we will
have to remove these from Debian.
 * Without the hsql-* packages, the haskelldb package itself is useless,
correct? So we need to package the hdbc series. Are these maintained
actively?
 * Anything else to consider?

Greetings,
Joachim

[1] http://packages.debian.org/search?suite=sid&arch=any&searchon=sourcenames&keywords=haskelldb

-- 
Joachim "nomeata" Breitner
Debian Developer
  no...@de... | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: no...@jo... | http://people.debian.org/~nomeata

Re: [Haskelldb-users] Primary keys?

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

You guessed right - you'd have to maintain that constraint yourself.

On Wed, Aug 26, 2009 at 4:23 AM, Colin Paul
Adams<co...@co...> wrote:
> I'm just playing with HaskellDB at the moment.
>
> I got a program working which generates a database and a Haskell
> module - just one table so far. But I notice there is no option to
> mark a column as being the unique primary key. Have I missed
> something, or do I have to maintain this invariant throughout the
> program logic?
> --
> Colin Adams
> Preston Lancashire
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

[Haskelldb-users] Primary keys?

[Colin P. A. <co...@co...>]

I'm just playing with HaskellDB at the moment.

I got a program working which generates a database and a Haskell
module - just one table so far. But I notice there is no option to
mark a column as being the unique primary key. Have I missed
something, or do I have to maintain this invariant throughout the
program logic?
-- 
Colin Adams
Preston Lancashire

[Haskelldb-users] Haskelldb repo converted to darcs-2

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

I've converted the repository at http://code.haskell.org/haskelldb to
darcs-2 format. The old repository is still available at
darcs1/haskelldb but I don't plan on accepting patches to it.

Let me know if any problems come up.

On Thu, Jul 16, 2009 at 3:50 PM, Justin Bailey<jgb...@gm...> wrote:
> 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] Dynamic queries with HaskellDB

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

Yes, don't declare a type for the query, let the type checker infer it.

/Bjorn

2009/7/24 Artyom Shalkhakov <art...@gm...>:
> Hi Justin,
>
> It's a pity I can't test the code ATM, but isn't there a way
> to find "the most general type" of the query?
>
> Anyway, thanks for clarifying that. Next time, I will have to check
> the code I post.
>
> 2009/7/23 Justin Bailey <jgb...@gm...>:
>> Looking at your example:
>>
>>>> q val = do
>>>>             s <- table stock
>>>>             restrict (fromNull (constant "") (s!company_name)
>>>>                    `like` constant ("%"++val++"%"))
>>>>             r <- project (company_name << s!company_name #
>>>>                     ticker << s!ticker)
>>>>             return r
>>
>>
>> The type of q would be based on the columns projected. Assuming
>> company_name and ticker are both strings, you would get
>>
>>   q :: Query (Rel (RecCons (CompanyName (Expr String)) (RecCons
>> (Ticker (Expr String)) RecNil)
>>
>> That is, a type-level tuple which indicates that the query has two
>> columns, CompanyName and Ticker, both with type String.
>>
>> Simplying your next example a little bit, I can show that it won't type check:
>>
>>>> flds cond2 s = let a = (vendor_name << s!vendor_name) # fld
>>>>                           b = if cond2
>>>>                                  then (customer_id << s!customer_id) # a
>>>>                                  else a
>>>>                           in b
>>>>          where
>>>>              fld = company_name << s!company_name # ticker << s!ticker
>>
>> What is the type of b? We have to look at the query created. When
>> cond2 is true, then b is:
>>
>>  (customer_id << s!customer_id) #  (vendor_name << s!vendor_name) #
>> company_name << s!company_name # ticker << s!ticker
>>
>> However, if cond2 is false then b is:
>>
>>  (vendor_name << s!vendor_name) # company_name << s!company_name #
>> ticker << s!ticker
>>
>> If cond2 is true, then the type of b can determined by the query shape:
>>
>>  b :: RecCons (CustomerId (Expr Int)) (RecCons (VendorName (Expr
>> String)) (RecCons (CompanyName (Expr String) (...))
>>
>> However, if cond2 is false then the type is
>>
>>  b :: RecCons (VendorName (Expr String)) (RecCons (CompanyName (Expr
>> String) (...))
>>
>> Since the type of the "then" and "else" arms need to agree, this won't
>> compile. Its like writing
>>
>>  b = if True then "a" else 1
>>
>> On Thu, Jul 23, 2009 at 1:37 AM, Artyom
>> Shalkhakov<art...@gm...> wrote:
>>> Hi,
>>>
>>> 2009/7/22 Keren Lenz <ker...@gm...>:
>>>> Here is an example (in imperative psudo code of what I mean by dynamic
>>>> query:
>>>> Query generate(bool cond1, bool cond2) {
>>>>     Colums c = null;
>>>>     if(cond1)
>>>>         c.add(col1);
>>>>     if(cond3)
>>>>         c.add(col2);
>>>>     Query q = SELECT + c + FROM table_name;
>>>>     return q;
>>>> }
>>>
>>>
>>>
>>>> That is, the selected columns are chosen based on runtime conditions.
>>>> Is that possible with HaskellDB?
>>>
>>> I would like to stress how HaskellDB works. You are given atomic building
>>> blocks (relations, tuples and fields) and some combinators ("glue" that helps
>>> you combine your building blocks: relational and query operations). What you
>>> are really doing with HaskellDB is manipulating an abstract syntax tree of a DSL
>>> embedded in Haskell.
>>>
>>> A simple example would be something along these lines [1]:
>>>
>>>> q val = do
>>>>             s <- table stock
>>>>             restrict (fromNull (constant "") (s!company_name)
>>>>                    `like` constant ("%"++val++"%"))
>>>>             r <- project (company_name << s!company_name #
>>>>                     ticker << s!ticker)
>>>>             return r
>>>
>>> It is already somewhat "dynamic". Can we do anything to make it more "dynamic"?
>>> Yes, we can:
>>>
>>>> q flds val = do
>>>>           s <- table stock
>>>>           restrict (fromNull (constant "") (s!company_name)
>>>>                  `like` constant ("%"++val++"%"))
>>>>           r <- project (flds s)
>>>>           return r
>>>
>>> where flds is simply
>>>
>>>> flds s = company_name << s!company_name # ticker << s!ticker)
>>>
>>> So now you can do:
>>>
>>>> flds cond1 cond2 s = let a = if cond1
>>>>                                                     then (vendor_name << s!vendor_name) # fld
>>>>                                                     else fld
>>>>                                         b = if cond2
>>>>                                                     then (customer_id << s!customer_id) # a
>>>>                                                     else a
>>>>                                    in b
>>>>          where
>>>>              fld = company_name << s!company_name # ticker << s!ticker
>>>
>>> (don't forget to change the definition of q!)
>>>
>>> As the number of conditions grows, this style becomes very inconvenient to
>>> program in, so you'd need a writer monad over a monoid or something I suppose.
>>>
>>> Also, I would like to note that I haven't tested the code given above,
>>> so I don't
>>> know if there are any bugs or not. But feel free to ask if there are,
>>> anyway. :-)
>>>
>>> Cheers,
>>> Artyom Shalkhakov.
>>>
>>> [1] http://pseudofish.com/blog/2008/05/11/haskelldb-basics/
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Haskelldb-users mailing list
>>> Has...@li...
>>> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>>>
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

Re: [Haskelldb-users] Dynamic queries with HaskellDB

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

Hi Justin,

It's a pity I can't test the code ATM, but isn't there a way
to find "the most general type" of the query?

Anyway, thanks for clarifying that. Next time, I will have to check
the code I post.

2009/7/23 Justin Bailey <jgb...@gm...>:
> Looking at your example:
>
>>> q val = do
>>>             s <- table stock
>>>             restrict (fromNull (constant "") (s!company_name)
>>>                    `like` constant ("%"++val++"%"))
>>>             r <- project (company_name << s!company_name #
>>>                     ticker << s!ticker)
>>>             return r
>
>
> The type of q would be based on the columns projected. Assuming
> company_name and ticker are both strings, you would get
>
>   q :: Query (Rel (RecCons (CompanyName (Expr String)) (RecCons
> (Ticker (Expr String)) RecNil)
>
> That is, a type-level tuple which indicates that the query has two
> columns, CompanyName and Ticker, both with type String.
>
> Simplying your next example a little bit, I can show that it won't type check:
>
>>> flds cond2 s = let a = (vendor_name << s!vendor_name) # fld
>>>                           b = if cond2
>>>                                  then (customer_id << s!customer_id) # a
>>>                                  else a
>>>                           in b
>>>          where
>>>              fld = company_name << s!company_name # ticker << s!ticker
>
> What is the type of b? We have to look at the query created. When
> cond2 is true, then b is:
>
>  (customer_id << s!customer_id) #  (vendor_name << s!vendor_name) #
> company_name << s!company_name # ticker << s!ticker
>
> However, if cond2 is false then b is:
>
>  (vendor_name << s!vendor_name) # company_name << s!company_name #
> ticker << s!ticker
>
> If cond2 is true, then the type of b can determined by the query shape:
>
>  b :: RecCons (CustomerId (Expr Int)) (RecCons (VendorName (Expr
> String)) (RecCons (CompanyName (Expr String) (...))
>
> However, if cond2 is false then the type is
>
>  b :: RecCons (VendorName (Expr String)) (RecCons (CompanyName (Expr
> String) (...))
>
> Since the type of the "then" and "else" arms need to agree, this won't
> compile. Its like writing
>
>  b = if True then "a" else 1
>
> On Thu, Jul 23, 2009 at 1:37 AM, Artyom
> Shalkhakov<art...@gm...> wrote:
>> Hi,
>>
>> 2009/7/22 Keren Lenz <ker...@gm...>:
>>> Here is an example (in imperative psudo code of what I mean by dynamic
>>> query:
>>> Query generate(bool cond1, bool cond2) {
>>>     Colums c = null;
>>>     if(cond1)
>>>         c.add(col1);
>>>     if(cond3)
>>>         c.add(col2);
>>>     Query q = SELECT + c + FROM table_name;
>>>     return q;
>>> }
>>
>>
>>
>>> That is, the selected columns are chosen based on runtime conditions.
>>> Is that possible with HaskellDB?
>>
>> I would like to stress how HaskellDB works. You are given atomic building
>> blocks (relations, tuples and fields) and some combinators ("glue" that helps
>> you combine your building blocks: relational and query operations). What you
>> are really doing with HaskellDB is manipulating an abstract syntax tree of a DSL
>> embedded in Haskell.
>>
>> A simple example would be something along these lines [1]:
>>
>>> q val = do
>>>             s <- table stock
>>>             restrict (fromNull (constant "") (s!company_name)
>>>                    `like` constant ("%"++val++"%"))
>>>             r <- project (company_name << s!company_name #
>>>                     ticker << s!ticker)
>>>             return r
>>
>> It is already somewhat "dynamic". Can we do anything to make it more "dynamic"?
>> Yes, we can:
>>
>>> q flds val = do
>>>           s <- table stock
>>>           restrict (fromNull (constant "") (s!company_name)
>>>                  `like` constant ("%"++val++"%"))
>>>           r <- project (flds s)
>>>           return r
>>
>> where flds is simply
>>
>>> flds s = company_name << s!company_name # ticker << s!ticker)
>>
>> So now you can do:
>>
>>> flds cond1 cond2 s = let a = if cond1
>>>                                                     then (vendor_name << s!vendor_name) # fld
>>>                                                     else fld
>>>                                         b = if cond2
>>>                                                     then (customer_id << s!customer_id) # a
>>>                                                     else a
>>>                                    in b
>>>          where
>>>              fld = company_name << s!company_name # ticker << s!ticker
>>
>> (don't forget to change the definition of q!)
>>
>> As the number of conditions grows, this style becomes very inconvenient to
>> program in, so you'd need a writer monad over a monoid or something I suppose.
>>
>> Also, I would like to note that I haven't tested the code given above,
>> so I don't
>> know if there are any bugs or not. But feel free to ask if there are,
>> anyway. :-)
>>
>> Cheers,
>> Artyom Shalkhakov.
>>
>> [1] http://pseudofish.com/blog/2008/05/11/haskelldb-basics/
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Haskelldb-users mailing list
>> Has...@li...
>> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>>
>

Re: [Haskelldb-users] Dynamic queries with HaskellDB

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

I don't think the code below can compile. One important aspect of
HaskellDB is that the "shape" of the query is shown in the *type* of
the query.

Looking at your example:

>> q val = do
>>             s <- table stock
>>             restrict (fromNull (constant "") (s!company_name)
>>                    `like` constant ("%"++val++"%"))
>>             r <- project (company_name << s!company_name #
>>                     ticker << s!ticker)
>>             return r


The type of q would be based on the columns projected. Assuming
company_name and ticker are both strings, you would get

   q :: Query (Rel (RecCons (CompanyName (Expr String)) (RecCons
(Ticker (Expr String)) RecNil)

That is, a type-level tuple which indicates that the query has two
columns, CompanyName and Ticker, both with type String.

Simplying your next example a little bit, I can show that it won't type check:

>> flds cond2 s = let a = (vendor_name << s!vendor_name) # fld
>>                           b = if cond2
>>                                  then (customer_id << s!customer_id) # a
>>                                  else a
>>                           in b
>>          where
>>              fld = company_name << s!company_name # ticker << s!ticker

What is the type of b? We have to look at the query created. When
cond2 is true, then b is:

  (customer_id << s!customer_id) #  (vendor_name << s!vendor_name) #
company_name << s!company_name # ticker << s!ticker

However, if cond2 is false then b is:

  (vendor_name << s!vendor_name) # company_name << s!company_name #
ticker << s!ticker

If cond2 is true, then the type of b can determined by the query shape:

  b :: RecCons (CustomerId (Expr Int)) (RecCons (VendorName (Expr
String)) (RecCons (CompanyName (Expr String) (...))

However, if cond2 is false then the type is

  b :: RecCons (VendorName (Expr String)) (RecCons (CompanyName (Expr
String) (...))

Since the type of the "then" and "else" arms need to agree, this won't
compile. Its like writing

  b = if True then "a" else 1

On Thu, Jul 23, 2009 at 1:37 AM, Artyom
Shalkhakov<art...@gm...> wrote:
> Hi,
>
> 2009/7/22 Keren Lenz <ker...@gm...>:
>> Here is an example (in imperative psudo code of what I mean by dynamic
>> query:
>> Query generate(bool cond1, bool cond2) {
>>     Colums c = null;
>>     if(cond1)
>>         c.add(col1);
>>     if(cond3)
>>         c.add(col2);
>>     Query q = SELECT + c + FROM table_name;
>>     return q;
>> }
>
>
>
>> That is, the selected columns are chosen based on runtime conditions.
>> Is that possible with HaskellDB?
>
> I would like to stress how HaskellDB works. You are given atomic building
> blocks (relations, tuples and fields) and some combinators ("glue" that helps
> you combine your building blocks: relational and query operations). What you
> are really doing with HaskellDB is manipulating an abstract syntax tree of a DSL
> embedded in Haskell.
>
> A simple example would be something along these lines [1]:
>
>> q val = do
>>             s <- table stock
>>             restrict (fromNull (constant "") (s!company_name)
>>                    `like` constant ("%"++val++"%"))
>>             r <- project (company_name << s!company_name #
>>                     ticker << s!ticker)
>>             return r
>
> It is already somewhat "dynamic". Can we do anything to make it more "dynamic"?
> Yes, we can:
>
>> q flds val = do
>>           s <- table stock
>>           restrict (fromNull (constant "") (s!company_name)
>>                  `like` constant ("%"++val++"%"))
>>           r <- project (flds s)
>>           return r
>
> where flds is simply
>
>> flds s = company_name << s!company_name # ticker << s!ticker)
>
> So now you can do:
>
>> flds cond1 cond2 s = let a = if cond1
>>                                                     then (vendor_name << s!vendor_name) # fld
>>                                                     else fld
>>                                         b = if cond2
>>                                                     then (customer_id << s!customer_id) # a
>>                                                     else a
>>                                    in b
>>          where
>>              fld = company_name << s!company_name # ticker << s!ticker
>
> (don't forget to change the definition of q!)
>
> As the number of conditions grows, this style becomes very inconvenient to
> program in, so you'd need a writer monad over a monoid or something I suppose.
>
> Also, I would like to note that I haven't tested the code given above,
> so I don't
> know if there are any bugs or not. But feel free to ask if there are,
> anyway. :-)
>
> Cheers,
> Artyom Shalkhakov.
>
> [1] http://pseudofish.com/blog/2008/05/11/haskelldb-basics/
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>

Re: [Haskelldb-users] Dynamic queries with HaskellDB

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

Hi,

2009/7/22 Keren Lenz <ker...@gm...>:
> Here is an example (in imperative psudo code of what I mean by dynamic
> query:
> Query generate(bool cond1, bool cond2) {
>     Colums c = null;
>     if(cond1)
>         c.add(col1);
>     if(cond3)
>         c.add(col2);
>     Query q = SELECT + c + FROM table_name;
>     return q;
> }



> That is, the selected columns are chosen based on runtime conditions.
> Is that possible with HaskellDB?

I would like to stress how HaskellDB works. You are given atomic building
blocks (relations, tuples and fields) and some combinators ("glue" that helps
you combine your building blocks: relational and query operations). What you
are really doing with HaskellDB is manipulating an abstract syntax tree of a DSL
embedded in Haskell.

A simple example would be something along these lines [1]:

> q val = do
>             s <- table stock
>             restrict (fromNull (constant "") (s!company_name)
>                    `like` constant ("%"++val++"%"))
>             r <- project (company_name << s!company_name #
>                     ticker << s!ticker)
>             return r

It is already somewhat "dynamic". Can we do anything to make it more "dynamic"?
Yes, we can:

> q flds val = do
>           s <- table stock
>           restrict (fromNull (constant "") (s!company_name)
>                  `like` constant ("%"++val++"%"))
>           r <- project (flds s)
>           return r

where flds is simply

> flds s = company_name << s!company_name # ticker << s!ticker)

So now you can do:

> flds cond1 cond2 s = let a = if cond1
>                                                     then (vendor_name << s!vendor_name) # fld
>                                                     else fld
>                                         b = if cond2
>                                                     then (customer_id << s!customer_id) # a
>                                                     else a
>                                    in b
>          where
>              fld = company_name << s!company_name # ticker << s!ticker

(don't forget to change the definition of q!)

As the number of conditions grows, this style becomes very inconvenient to
program in, so you'd need a writer monad over a monoid or something I suppose.

Also, I would like to note that I haven't tested the code given above,
so I don't
know if there are any bugs or not. But feel free to ask if there are,
anyway. :-)

Cheers,
Artyom Shalkhakov.

[1] http://pseudofish.com/blog/2008/05/11/haskelldb-basics/

Re: [Haskelldb-users] Dynamic queries with HaskellDB

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

Nope, that really wouldn't work with HaskellDB. I've CC'ed the list
but I am pretty sure on this one.

On Wed, Jul 22, 2009 at 7:16 AM, Keren Lenz<ker...@gm...> wrote:
> Thank you very much for your help.
> I'm comparing features of HaskellDB with those of other libraries/solutions
> for type safe generation of queries.
> Here is an example (in imperative pseudo code) of what I mean by dynamic
> query:
> Query generate(bool cond1, bool cond2) {
>     Colums c = null;
>     if(cond1)
>         c.add(col1);
>     if(cond3)
>         c.add(col2);
>     Query q = SELECT + c + FROM table_name;
>     return q;
> }
>
> That is, the selected columns are chosen based on runtime conditions.
> Is that possible with HaskellDB?
>
> Thanks again,
> Keren.
>
>
>
>
> On Mon, Jul 20, 2009 at 6:17 PM, Justin Bailey <jgb...@gm...> wrote:
>>
>> In what way do you mean "dynamic"? Do you mean the tables & columns
>> used in the query, or the conditions (i.e. whatever is in the "where"
>> clause)?
>>
>> In the first case, not easily. The columns in the result of a query
>> are carried in the type, which means you could only specify that at
>> runtime with some Template Haskell magic. In the second case, easily.
>>
>> If you want to be more specific I'm sure I (or someone) can help you out.
>>
>> 2009/7/19 Keren Lenz <ker...@gm...>:
>> > Hello,
>> >
>> >         Does HaskellDB support dynamic queries, that is, queries which
>> > are
>> >         generated at runtime based on some user input?
>> >
>> >         Thanks in advanced,
>> >         Keren.
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Enter the BlackBerry Developer Challenge
>> > This is your chance to win up to $100,000 in prizes! For a limited time,
>> > vendors submitting new applications to BlackBerry App World(TM) will
>> > have
>> > the opportunity to enter the BlackBerry Developer Challenge. See full
>> > prize
>> > details at: http://p.sf.net/sfu/Challenge
>> > _______________________________________________
>> > Haskelldb-users mailing list
>> > Has...@li...
>> > https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>> >
>> >
>
>

Re: [Haskelldb-users] Dynamic queries with HaskellDB

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

Hello,

2009/7/19 Keren Lenz <ker...@gm...>:
>         Does HaskellDB support dynamic queries, that is, queries which are
>         generated at runtime based on some user input?

HaskellDB query construction is carried out in a monad. Monads are first-class
in the sense that you can pass monadic computation to a function, return it
from a function, etc. So I guess you can support some dynamic queries easily:
actually, I used to invoke HaskellDB in GHCi toploop, that is, interactively and
dynamically. :-)

Can you provide an example of what you're trying to accomplish? Maybe we
could help you.

Cheers,
Artyom Shalkhakov.

Re: [Haskelldb-users] Dynamic queries with HaskellDB

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

In what way do you mean "dynamic"? Do you mean the tables & columns
used in the query, or the conditions (i.e. whatever is in the "where"
clause)?

In the first case, not easily. The columns in the result of a query
are carried in the type, which means you could only specify that at
runtime with some Template Haskell magic. In the second case, easily.

If you want to be more specific I'm sure I (or someone) can help you out.

2009/7/19 Keren Lenz <ker...@gm...>:
> Hello,
>
>         Does HaskellDB support dynamic queries, that is, queries which are
>         generated at runtime based on some user input?
>
>         Thanks in advanced,
>         Keren.
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Haskelldb-users mailing list
> Has...@li...
> https://lists.sourceforge.net/lists/listinfo/haskelldb-users
>
>

[Haskelldb-users] Dynamic queries with HaskellDB

[Keren L. <ker...@gm...>]

Hello,

        Does HaskellDB support dynamic queries, that is, queries which are
        generated at runtime based on some user input?

        Thanks in advanced,
        Keren.