Re: [Chicken-users] Standard APIs for databases, Web-apps

[Graham Fawcett]

On 2/10/06, Toby Butzon <address@hidden> wrote:
> The problem I have with all this is, unless you *really* focus on being
> non-database-specific, and make try to force all the database
> interaction into its own "box", you'll end up with SQL statements
> throughout your application (along with the associated references to
> the JDBC API). That's bad because SQL *isn't* non-database-specific
> (even though that was the original intent), so you'll have to chase down
> those points if you change databases anyway.

I think we're on the same page. I'm not suggesting that the proposed
API should try to obscure the differences between SQL *dialects*. But
I would like to see a standard set of functions to handle
query-responses. For example, the current postgresql egg does not
provide a means for accesing the metadata of a result set; I think a
consistent metadata-accessor is a reasonable goal for all db bindings.
Also, wouldn't it be nice to have a standard set of row accessors:
fetch-all, fetch-one, foldr, for-each, etc., common to each database
wrapper?

I appreciate that the eggs are the work of volunteers, and not
suggesting that any of the eggs is deficient; rather, they are
idiosyncratic, and I think that users (me!) could benefit from a more
consistent API.

> The only way to maintain portability in this case is to make the database
> code a well-organized, compact "layer" between the DB and the rest of your
> app. Then if the DB changes, the layer is all that has to change. But
> once you start thinking like this, the app-dependant "layer" takes the
> place of JDBC's API. The API is at that point useless, and only confuses
> matters because its notions don't always map well to the DB vendor's
> notions of queries, responses, etc. It's clearer to use the DB vendor's
> library/API directly, and forget JDBC even exists.

I agree about separating database concerns into a different layer. But
are vendors' notions of queries and responses really so different?
Maybe you've used databases that I haven't. It's possible that one
vendor might provide a feature set not available in other databases,
but a designer who has portability as a goal would generally avoid
those features. (I know that portability isn't always an objective.)

> > This decoupling
> > allows the vast sea of Python Web frameworks to share common Web
> > server bindings, and lets those frameworks share middleware components
>
> Hrm... so the vast number of frameworks out there don't actually do
> different jobs? They're copies of each other with maybe a few innovative
> ideas each?

Definitely true; a lot of NIH going on there. I don't see the
profileration of Python frameworks being played out again in the the
Chicken/Scheme community; as Brandon mentioned, the two communities
are very different.

I didn't intend to bash Spiffy in any way. It would be helpful,
though, if there were a clear set of hooks for introducing new
server-drivers. At work, we use SCGI extensively, and I'd like to plug
in a Chicken app the same way we plug in everything else. But it's not
clear to me how to write an SCGI driver that works with Spiffy out of
the box. I don't want to write a new framework, but I do want a
framework that talks SCGI in a clean (and easily monitored/debugged)
fashion. Making the Web API explicit would be a benefit here.

> I'm only confused about why you would do this in the first place. What
> alternatives are there to spiffy? And if there are none, but "may" be in
> the future, why would there be? Why not continue to improve spiffy?

Honestly, that's my game plan. I really just want a clear point of
demarcation between my SCGI driver and the app server. If that point
already exists, I'm having a little trouble finding it. :-) I don't
want to dilute the audience by introducing a different app server,
it's the connectivity side that I'm concerned with. I mentioned
middleware because it's a possibility, but it's not a personal
motivator.

> Again, I'm not trying to be personal, Graham. I'm just trying out ideas.

Me too. I don't mind if my ideas get shot down; every shot fired is a
learning opportunity. ;-)

Graham