Yes, and it works pretty well - but the squeak port works only with Yanni's postgres library. No mysql (not that I care since I have pg) and no oracle (which is potentially a biggie).

On Aug 5, 2004, at 12:09 PM, John M McIntosh wrote:

I'm sure I've seen some code that lets you talk to mysql via the socket layer.

but really you should look at the glorp work.

http://www.smalltalkpro.com/squeakextras.html

Beyond the whole issue of read/writing data to the database, you need to make that information into objects over on the smalltalk side. Glorp handles all of this with ease.

On Aug 5, 2004, at 8:04 AM, Kamil Kukura wrote:

...

Hi,

I would like to first point out that I don't intent to compare here databases like relational vs. object ones. It's all about getting squeak and ubiquitous world of relational databases together.

When trying to attract web developers from environments such as PHP, ASP or JSP, I'm badly missing a thing to show as how Squeak deals with external databases. Perhaps best way to connect to any DB is to use ODBC which scares me as it relies on FFI http://minnow.cc.gatech.edu/squeak/2424 .NET people have ADO, Perl/Ruby builds on DBI, Javists rely on JDBC, "C" hard workers stick to ODBC and PHPers go almost native though they also have something: http://adodb.sourceforge.net/

So I'm thinking what would be nice to have to show up with more databases Squeak can natively talk to. Right now I consider to do some work on "SqDBC". At first, it would be a package containing ODBC and ODBCEnh as its default database driver. Then I would like to "grow up" PostgreSQL package in the way it would become SqDBC driver (and upgrade it to protocol 3 as well). Then add some connection pooling to SqDBC. I know it looks quite "javish" as their JDBC but I don't know if is there better "natural" approach.

-- Kamil Kukura

--

==== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================= ====

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 Kukura wrote:

[...] 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.

So to summarize, you'd like to see native Squeak connections to more RDB's, and all connections should have a common interface.

I certainly agree that more native drivers is desirable, but the constraint is that the format and meaning of the messages which flow over the socket must be available. I'm not sure whether Oracle, DB2 (UDB?), SQL Server make this information available.

However, a common DB interface may be problematic. It would force inefficiencies based on a perceived advantage of portability across databases. The inefficiencies would be unnecessary format conversions and lost optimization opportunities. I say "perceived" portability because in practice, the SQL is not portable, or some unique database feature is being used. So you pay a price for portability that isn't real.

Aside. Here's a potential optimization opportunity, which would be lost under a common interface. The row of the result set of the PostgreSQL client has a #rawData method, which returns whatever the backend sent. Since the backend returns numbers as ASCII strings, you can completely avoid two conversions if the raw value is piped straight to the display.

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.

Cursors was the reason I looked a version 3, but then I realized that "CURSOR" support is done in the SQL, so was already supported in version 2. The other reason to want v3 was to avoid reading a huge result set, which might consume too much memory. But the "LIMIT" keyword may give a good enough solution.

What you're describing as cursor support in resultsets, I think is refering to the new v3 protocol changes which pulls the result rows from the server a few at a time (instead of one big chunk).

--yanni

On Aug 5, 2004, at 11:30 AM, lex@cc.gatech.edu wrote:

Kamil Kukura kamk@volny.cz wrote:

...

When trying to attract web developers from environments such as PHP, ASP or JSP, I'm badly missing a thing to show as how Squeak deals with external databases. Perhaps best way to connect to any DB is to use ODBC which scares me as it relies on FFI http://minnow.cc.gatech.edu/squeak/2424

FFI seems the proper way to talk to ODBC, and ODBC seems like a direct way to get portable database access.

Is fear the only reason not to use FFI, or is there a technical problem as well? Have you tried it? Maybe we just need to smooth the process of getting everything set up?

In this case there is actually a sound technical reason not to use FFI, which is that FFI can only support blocking calls, and you really don't want the VM blocking on something as I/O bound as a database query. It means you effectively can't use ODBC in a web setting, or anywhere that you are going to have lots of concurrent queries. It's useful for batch work (massaging/importing/exporting data) but that's about it.

The right thing to do would be to write a plugin that either used an async interface to ODBC (I can't imagine it doesn't provide one), or in the worst case spawns a separate thread for each query.