From: Vladimir Zolotykh
Subject: simple database handling
Date: 
Message-ID: <3C84E3FD.285269BD@eurocom.od.ua>
I've recently wrote some sketch of code (it follows) main aim is to
deal with more than one database connections open simultaneously and
try to recover (reconnect) if it possible.

Assume here some vendor's database package DB. It has DB:DATABASE
class, notion of default database (*DEFAULT-DATABASE*) some query
functions (DB:QUERY) and error handling (DB:DATABASE-ERROR).

I'd like to hear your comments what are drawbacks, benefits,
improvements, possible problems etc. 

Also I think it will be reasonable to integrate this with some simple
transaction handling. I'm not ready to write it down now.

It is intended that the code dedicated to use this will run in 'batch'
mode.  I mean without much attention from operator (probably he could
read some log file from time to time). Hence entering password
couldn't be interactive. But I'm worrying a bit hard-coding it
(password) in sources. Does some safe solution exits ?

(defvar *db-1* nil)                     ;account
(defvar *db-2* nil)                     ;proba2

(defclass my-db (database)
  ((connect :initarg :connect :accessor my-db-connect)))

(defmacro with-default-db ((db) &body body)
  (let ((try-again (gensym "try-again")))
    `(let ((allowed 5))
       (prog nil
         ,try-again
         (return
           (handler-case (let ((db:*default-database* ,db))
                           ,@bod                   y)
             (db:database-error (condition)
               (declare (ignore condition))
               (unless (zerop (decf allowed))
                 (setq ,db (funcall (my-db-connect ,db)))
                 (go ,try-again)))))))))
  
(let ((user "John Doe")
      (password "Foo"))
(defun connect-1 ()
  (let ((db (change-class 
             (db:connect :db "account" :user user :password password)
             'my-db)))
    (setf (my-db-connect db) #'connect-1)
    db))

(defun connect-2 ()
  (let ((db (change-class
             (db:connect :db "proba2" :user user :password password)
             'my-db)))
    (setf (my-db-connect db) #'connect-2)
    db))
)

(defun select-1 ()
  (db:query "select count(*) from special"))

(defun select-2 ()
  (db:query "select * from streets limit 1"))

(defun test ()
  (list (with-default-db (*db-1*) (select-1))
        (with-default-db (*db-2*) (select-2))))

-- 
Vladimir Zolotykh

From: Marco Antoniotti
Subject: Re: simple database handling
Date: 
Message-ID: <y6cn0xnhv4h.fsf@octagon.mrl.nyu.edu>
Vladimir Zolotykh <······@eurocom.od.ua> writes:

> I've recently wrote some sketch of code (it follows) main aim is to
> deal with more than one database connections open simultaneously and
> try to recover (reconnect) if it possible.

Are you aware of MaiSQL and UncommSQL?

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.
From: Vladimir Zolotykh
Subject: Re: simple database handling
Date: 
Message-ID: <3C84ED45.E2729081@eurocom.od.ua>
Marco Antoniotti wrote:
> 
> Are you aware of MaiSQL and UncommSQL?

Know former a little. Haven't learn yet sources of the latter though, does it
do something similar ? 

I'd like to understand (at least a basic figure) not only get tool that
do that for me without understanding it.

-- 
Vladimir Zolotykh
From: Jochen Schmidt
Subject: Re: simple database handling
Date: 
Message-ID: <a62rgc$8nr$1@rznews2.rrze.uni-erlangen.de>
Vladimir Zolotykh wrote:

> Marco Antoniotti wrote:
>> 
>> Are you aware of MaiSQL and UncommSQL?
> 
> Know former a little. Haven't learn yet sources of the latter though, does
> it do something similar ?
> 
> I'd like to understand (at least a basic figure) not only get tool that
> do that for me without understanding it.

UncommonSQL is very similar to Xanalys' CommonSQL (which I suppose you are 
using...). UncommonSQL is definitely worth a look if you want to understand
how a database binding similar to CommonSQL can be built.

ciao,
Jochen

--
http://www.dataheaven.de
From: Vladimir Zolotykh
Subject: Re: simple database handling
Date: 
Message-ID: <3C84F594.5FBB3B60@eurocom.od.ua>
Jochen Schmidt wrote:
> 
> UncommonSQL is very similar to Xanalys' CommonSQL (which I suppose you are
> using...). UncommonSQL is definitely worth a look if you want to understand
> how a database binding similar to CommonSQL can be built.

Yes I having thought about it. But it looks rather big (aprox 10,000 lines
of code) and learning it won't be fast or simple.

-- 
Vladimir Zolotykh
From: Rahul Jain
Subject: Re: simple database handling
Date: 
Message-ID: <874rjqps5c.fsf@photino.sid.rice.edu>
Vladimir Zolotykh <······@eurocom.od.ua> writes:

> Jochen Schmidt wrote:
> > UncommonSQL ...
> 
> Yes I having thought about it. But it looks rather big (aprox 10,000 lines
> of code) and learning it won't be fast or simple.

How does that follow? Implementing a natural language system will
result in a rather large volume of code. The whole point of such a
system is to be faster and simpler to learn. The (un)CommonSQL API is
quite simple and powerful and is essentially what you seem to have
developed with a lispy syntax for SQL and more flexibility, etc.

-- 
-> -/-                       - Rahul Jain -                       -\- <-
-> -\- http://linux.rice.edu/~rahul -=-  ············@techie.com  -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.221020101.23.50110101.042
   (c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Christopher Browne
Subject: Re: simple database handling
Date: 
Message-ID: <m3u1rq62g3.fsf@chvatal.cbbrowne.com>
-----BEGIN PGP SIGNED MESSAGE-----

In an attempt to throw the authorities off his trail, Rahul Jain <·····@sid-1129.sid.rice.edu> transmitted:
> Vladimir Zolotykh <······@eurocom.od.ua> writes:
>> Jochen Schmidt wrote:
>> > UncommonSQL ...

>> Yes I having thought about it. But it looks rather big (aprox
>> 10,000 lines of code) and learning it won't be fast or simple.

> How does that follow? Implementing a natural language system will
> result in a rather large volume of code. The whole point of such a
> system is to be faster and simpler to learn. The (un)CommonSQL API is
> quite simple and powerful and is essentially what you seem to have
> developed with a lispy syntax for SQL and more flexibility, etc.

Flip side of that:  The *CommonSQL API is fairly _large_, having
rather a large set of macros, functions, and classes, in order for it
to be able to support the not-exactly-minscule standard that is SQL.

Compare, for instance, with Berkeley DB.  It has a _few_ layers of
macrology involved to set up environment, but since you're only really
using the database to store "raw payload," usually amounting to a
hash table, it stays pretty simple even at its most sophisticated.
- -- 
(reverse (concatenate 'string ···········@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/lsf.html
Signs of a Klingon Programmer #7: "Klingon function  calls do not have
'parameters' -- they have 'arguments' -- and they ALWAYS WIN THEM."

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBPIlPG+t2yn4mZPwlAQHQigP/ZD4g8icMB+qy8hnF1svNU4CGxXANVZ2k
r3BRg4+dzzY10vnUzrewZEkjDipIa91BMvp1q4fyp+gGmSoo8a0vMwafGIP0KKkA
sh+xL/CQ1nqhssXInHGtKTyeHBdXz1H2UpvOoRC21z3jNGY5U4GZrhZw9+iWcwU3
znR1/ZxFQH0=
=Vngm
-----END PGP SIGNATURE-----
From: Rahul Jain
Subject: Re: simple database handling
Date: 
Message-ID: <874rjp1q8u.fsf@photino.sid.rice.edu>
Christopher Browne <········@acm.org> writes:

> In an attempt to throw the authorities off his trail, Rahul Jain <·····@sid-1129.sid.rice.edu> transmitted:
> Flip side of that:  The *CommonSQL API is fairly _large_, having
> rather a large set of macros, functions, and classes, in order for it
> to be able to support the not-exactly-minscule standard that is SQL.

Right, but you don't need to learn all the details just to do simple
things. e.g., you don't need to learn how do define a slot as a join
of two tables in order to send a simple select and update within a
transaction.

> Compare, for instance, with Berkeley DB.  It has a _few_ layers of
> macrology involved to set up environment, but since you're only really
> using the database to store "raw payload," usually amounting to a
> hash table, it stays pretty simple even at its most sophisticated.

That's fine for cases where it's all that's needed, but I don't see
how it's simpler to construct and deconstruct the rows of the table
manually when you could just define a table in an RDBMS and let it do
the hard work, even helping you out if you want to change the table
format slightly (or do they still not let you do that? I haven't
actually tried.).

In fact, the API to set up a connection is quite simple:
(sql::connect '(something to tell the db driver what db to connect to)
              :database-type :some-dbms)

and then you query the database, which is now the default, so you
don't need to speify it in any of the calls.

-- 
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  ············@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Vladimir Zolotykh
Subject: Re: simple database handling
Date: 
Message-ID: <3C8B3296.314373EC@eurocom.od.ua>
Rahul Jain wrote:
> 
> ..... The (un)CommonSQL API is
> quite simple and powerful and is essentially what you seem to have
> developed with a lispy syntax for SQL and more flexibility, etc.

You're right. I had changed my mind some time ago. I'll try to learn
(un)CommonSQL if I could (actually I'm already doing that). But I
can't learn it partially. I should have it running under ACL to be
able use it also (not just learning).

-- 
Vladimir Zolotykh
From: Rahul Jain
Subject: Re: simple database handling
Date: 
Message-ID: <87y9gy4q5k.fsf@photino.sid.rice.edu>
Vladimir Zolotykh <······@eurocom.od.ua> writes:

> Rahul Jain wrote:
> > 
> > ..... The (un)CommonSQL API is
> > quite simple and powerful and is essentially what you seem to have
> > developed with a lispy syntax for SQL and more flexibility, etc.

> I'll try to learn (un)CommonSQL if I could (actually I'm already
> doing that). But I can't learn it partially.

Why can't you? Just learn the features you need to use and not the
ones you don't. e.g., it seems like you don't want to use a CLOS
interface to the database, so don't learn how that works just
yet. When you feel the need later, you can always learn it. The point
of a well-designed language is that you can learn what you need
without being side-tracked with other irrelevant features. I think the
(un)commonSQL API is an example of this.

> I should have it running under ACL to be able use it also (not just
> learning).

I don't see any FFI bindings in it for ACL, so I think you're out of
luck (but it seems that a conversion to UFFI is in the works).

-- 
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  ············@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Kevin Rosenberg
Subject: Re: simple database handling
Date: 
Message-ID: <slrna8qu7m.n3g.kevin@boa.b9.com>
>> I should have it running under ACL to be able use it also (not just
>> learning).
> 
> I don't see any FFI bindings in it for ACL, so I think you're out of
> luck (but it seems that a conversion to UFFI is in the works).

I have a package, CL-SQL, that is a port of MaiSQL that uses UFFI.
(http://uffi.med-info.com). So far, it is testing well with AllegroCL,
Lispworks, and CMCUL.  I plan on release that as soon. I'm still working
on adding features and documenting UFFI. As I change UFFI, the interface
in CL-SQL is changing as well.

As soon as I consider the UFFI interface reasonable stable, I intend
to release CL-SQL. I expect the next port that I work on with UFFI will
the the CLG package (http://www.sf.net/projects/clg).

-- 
Kevin Rosenberg
·····@rosenberg.net
From: Vladimir Zolotykh
Subject: Re: simple database handling
Date: 
Message-ID: <3C8DBAAE.A1D1E4D6@eurocom.od.ua>
Rahul Jain wrote:
> 
> Vladimir Zolotykh <······@eurocom.od.ua> writes:
> > I should have it running under ACL to be able use it also (not just
> > learning).
> 
> I don't see any FFI bindings in it for ACL, 
Doesn't FFI stand for Foreign Function Interface, does it?

> so I think you're out of
> luck 

Even after porting ?

(but it seems that a conversion to UFFI is in the works).

What does UFFI stand for, may I ask ?

-- 
Vladimir Zolotykh
From: Rahul Jain
Subject: Re: simple database handling
Date: 
Message-ID: <87d6ya41ft.fsf@photino.sid.rice.edu>
Vladimir Zolotykh <······@eurocom.od.ua> writes:

> Rahul Jain wrote:
> > I don't see any FFI bindings in it for ACL, 
> Doesn't FFI stand for Foreign Function Interface, does it?

It does, yes.

> > so I think you're out of luck

> Even after porting ?

Obviously, that can be done, but

> (but it seems that a conversion to UFFI is in the works).

> What does UFFI stand for, may I ask ?

Unified FFI, I believe. Look at Kevin Rosenberg's (UFFI's author)
reply for more information.

-- 
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  ············@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Vladimir Zolotykh
Subject: Re: simple database handling
Date: 
Message-ID: <3C8DD40B.6A39FC47@eurocom.od.ua>
Rahul Jain wrote:
> 
> Obviously, that can be done, but
> 
> > (but it seems that a conversion to UFFI is in the works).
> 
> > What does UFFI stand for, may I ask ?
> 
> Unified FFI, I believe. Look at Kevin Rosenberg's (UFFI's author)
> reply for more information.

I'll try this myself if I could. I don't know better way to learn things.
Especially I'm feeling growing sympathy to *CommonSQL.

-- 
Vladimir Zolotykh
From: Kevin Rosenberg
Subject: Re: simple database handling
Date: 
Message-ID: <slrna8sc0p.2jm.kevin@boa.b9.com>
> What does UFFI stand for, may I ask ?

Universal Foreign Function Interface (http://uffi.med-info.com).


-- 
Kevin Rosenberg
·····@rosenberg.net