Roman Rokytskyy wrote:

>Ok, I think I agree on this one when we talk about the engine plugins.
>But what is your suggestion for something like UDFs, at least of the
>same level of complexity?
>
>

I originally designed Interbase to run without a configuration file.
Eventually, we had to throw in the towel. Vulcan (and I believe FB 2.0)
now has an elegant, extensible configuration file system that we can and
should exploit.

The think I most dislike about configuration data in the database is
transportability -- the environment in which a backup is restore is not
necessarily where it was created, and things may very well be in
different places. Requiring a user to mimic one system on another to be
able to restore a database doesn't strike me as user (or dba) friendly.

>
>
>>Second, Vulcan already has a set abstract class
>>definitions for JDBC-type objects that form the basis for internal
>>SQL. These should service as the basis for communication between the
>>engine and an external engine.
>>
>>
>
>I expected this "complaint", the only excuse is that this thing was
>designed and the first prototype implemented at the same time you
>started to code Vulcan.
>
>

No. The IscDbc interface was actually implemented before Interbase was
released open source. The idea behind the ODBC driver was it would be
defined against the abstract IscDbc layer, and IscDbc would make JDBC
semantics into open source Interbase. So it wasn't prototyped in
Vulcan, it was put into production almost 5 years ago. The internal
version, faithful to the original interface definition, is layered on
the CStatement/DStatement objects that from the internal SQL interface.

>But let's look into the future:
>
>How would it work for a simple external procedure written in C++ just
>because of some complicated computation? And what about Delphi? Don't
>we have the same problem we had when we were talking about the public
>OO API and entry point names in the DLLs?
>
>

It's the easiest to use database interface I've seen. It is defined as
a C++ object, so a client must be compiled with the same compiler as the
engine, but this is pretty much unavoidable for any dynamically loadable
engine library.

>I have to admit that the paper does not address the issue as well. So,
>my question here is - should we address external procedures that have
>an API complexity similar to current UDFs?
>
>
>

We want to design a simple, extensible, supportable interface between
the engine and external procedures. Any external procedure is going to
need to execute SQL statements in user context (security, transaction,
etc). Exporting a Connection object addresses all of these.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376