squeak to meet databases

Kamil Kukura kamk at volny.cz
Sat Aug 7 10:51:25 UTC 2004


Yanni Chiu wrote:
  > I don't get what's missing. You can issue SQL, and access the
> result set. Then with Seaside, you can spit out HTML.
> Can you explain some more about what you expect.

Simply put, just growing list of databases we can connect to without 
disturbing VM with FFI.

> Why is an SqDBC layer needed? If the reason is rdb portability,
> doesn't ODBC already give you that. IME, you end up building a
> framework (or use code generation) to access the database anyway;
> so why shouldn't that framework target the database driver directly,
> instead of an intermediate layer.

Maybe intermediate layer is not what I meant. It could be rather 
abstract class for subclassing a specific RDB driver. When talking about 
layer, I would go for some SQL adaptation layer for supporting O/R 
frameworks (GLORP, ROE) which generate SQL commands.

> There happen to be three PostgreSQL drivers. Apart from
> connection pooling and authentication support, the driver that
> I wrote was never intended to be much more than it already is.
> It simply sends SQL, and returns a result set. It was expected
> that some kind of object mapping, code-generation, CRUD package
> would be built on top. (In fact, I'm working on such a thing).

I use it and it's quote cool. I like it as a proof that native RDB 
drivers can be written in Squeak. I think almost all RDBs can be 
contacted from sockets and I don't see need to go other way.

> As for protocol version 3, I looked at it earlier and figured
> it was not worth doing, just to get:
>     - perhaps better error recovery
>     - prepared stmt support
> If there's interest, I can look at implementing it.

Right now version 2 seems OK. For another version I vote for cursor 
support in resultsets. I'm not sure if PostgreSQL does have support for 
uni- or bi- directional cursors.

-- 
Kamil



More information about the Squeak-dev mailing list