Hi Thomas, On Fri, Apr 1, 2011 at 5:47 AM, Thomas Chust <[email protected]> wrote:
> > There is at least one small point that I would want to do differently, > though: In my opinion it has some value if the procedure establishing > the database connection has a fixed signature and driver specific > information is encoded in a single argument. I'm pondering about using > an URI for that purpose. This has the advantage that it's very easy > then to read this single parameter from a configuration file and keep > the code one writes entirely agnostic of any driver specifics. URI is definitely an interesting approach. I originally wanted to use a connection string like ODBC, but realized that since I am using DBI to be more than just for RDBMS (I have a memcached driver and a filepath driver) and the key/value pairs is not fixed, so it becomes a situation where the underlying driver will dictate the key/value pairs, so I just bypass the need to parse the connection string (and user's need to format such string) and let the underlying driver call the shot. > What I like about the bzlib/dbi interface is that SQL syntax is > somewhat normalized with respect to query parameter placeholders and > reformatted by the specific driver. To make the interface more natural > I wonder whether it wouldn't be nice to pass the query parameters as > keyword arguments to the procedure executing the query, though. In > particular, this style of argument passing would be compatible with > optionally allowing positional arguments, too. The reason I did not use keyword arguments for query is that in racket keyword arguments needs to be quoted to pass through to the underlying driver, but chicken might not have that issue. The alist approach I chose can feel unwieldy at times for sure if written manually, but nice when the alist is already formulated elsewhere (which occurs quite a bit in web code) to be passed in. Love to collaborate more if you are interested - it would be nice to eventually have a single DBI mechanism for the major scheme implementations. -- Cheers, yc http://yinsochen.com
_______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
