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
|