Subject RE: [IB-Architect] Extending SP lang. to ISQL
Author Claudio Valderrama C.
> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Lunes 15 de Mayo de 2000 13:22
> At 11:35 AM 5/15/00 -0400, Dalton Calford wrote:
> >
> >BUT, I do want to see certain enhancements added to the SP language.


> There are open source JVMs available under InterBase compatible
> licenses that could be integrated with the engine.
> I suggest we spend a little time talking about Java integration
> issues.
> Jim Starkey

I will speak for myself and only for a few people more that I know

If Java is going to be bundled into the engine, please ensure the
implementation is lean and mean; otherwise I prefer the server as it's. The
beauty of IB is being lightweight but powerful at the same time. I still
don't find any other comparable engine. For me, an independent developer in
an underdeveloped country, IB is extremely useful as it is due to my
client's requirements.

There are compatibility issues that I don't know if they apply here between
different versions of Java... or is this due to JVMs only and not to the
language? For example, I participate in an email list at ExcelonCorp only as
a reader and the incompatibilities between Java/JVM versions are the most
cited nightmare. I don't know if this glitch applies in this case. Is there
any chance the future IB's JVM and other JVMs clash in my system? Does the
JVM existence complicate the installation of the IB Server? Can an
ill-installed IB's JVM potentially crash the engine?

If I had to cast a vote, I would say that I prefer the IB's JVM to be
optional and not an imposed feature. To be sincere, I would avoid it likely.
If I happen to write my UDF in C, I have to worry about my own bugs and
memory leaks. If I write it in Java, is there a decent way to ensure the JVM
implementation doesn't leak resources like the BDE? When I need to call a
Java UDF on a 3 million records update, what's the expected performance loss
I should expect compared with C? 3%, 5%, 10%? I don't know the percentage,
hence this is the reason I ask.

Ultimately, what's the value of Java? That I can put the code in a sandbox.
What more? Portability? Not sure. Is the JVM written in Java? Isn't C
already ported to N+1 platforms already? Don't we have C++, Eiffel and
Delphi as robust OO languages? The first two run on several platforms.
Please help me to understand your enthusiasm for Java.

I'm an strong advocate of some extensions to the current sp language. I
don't intend to throw 300 new functions in the engine's core. But there are
some features that would make life easier:
- The ability to have a R/O context variable with the name of the table that
invoked a trigger if some trigger is being called. Of course, if this
trigger modifies another table and this table fires its own trigger, the
variable has to be updated until the second trigger returns... perhaps we
are speaking about a stack.
- The ability to have a R/O variable that gives me the number of records
affected by my last update/delete statement. AFAIK, Oracle, SqlServer,
Sybase and DB2 provide such facility. In IB this is only available in a
client application (and probably in embedded SQL, not sure). I need
sometimes to take a decision immediately after such update/delete statement,
based on the records I touched. Quering again the database for the sp is not
a decent option for performance reasons.
- Some long needed functions, like substr, length and trim.

Personally, I don't see bidireccional cursors as a must, but this is food
for IB-Priorities.

I want to propose something that may be very naive, but anyway:
- Does anybody knows exactly what's all the power of Interbase?
- Does Jim know all the changes and enhancements made to the server while he
was "retired"?
- Does anybody care to document all the hidden but legal tricks that are

Personally I believe that (and excuse me for shouting) PERHAPS THERE ARE
MUCH POWER THAT NEVER WAS DOCUMENTED. Let's avoid wasting hours on reference
implementations or new APIs... how many options or system calls are in limbo
currently? How many facilities have more space for conveying data or are
much more flexible than we know? Maybe some things we want the engine to do
are already in place and only need to be documented or polished a bit.

Just my gen_id(rdb$cents, 2) for now.