On 27/07/2011 05:23, Roman Rokytskyy wrote:
> Jim,
>
>> Would it be possible and desirable to have FreePascal as an embedded
>> stored procedure/trigger language in some future release of Firebird?
>> (I
>> can't recall this having been brought up before, so I just start the
>> ball rolling).
> I did not check the current state of Java "plugin", but originally it
> was not planned to change Firebird's DDL to be able to write something
> like this:
>
> CREATE PROCEDURE divide(a INTEGER, b INTEGER) RETURNS INTEGER LANGUAGE
> JAVA AS
> {
> if (b == 0)
> throw new MySuperException();
> else
> return a / b;
> };
>
> Instead it was supposed to be something like this (syntax might differ
> now):
>
> CREATE EXTERNAL PROCEDURE bla LANGUAGE JAVA EXTERNAL NAME
> 'org.firebirdsql.HelloWorld.sayHelloWorld';
>
> This means that Java procedures were supposed to be compiled
> externally. We have discussed the idea of compiling them on-the-fly and
> store them in the database, but if I remember correctly, no decision was
> made.
The support in the engine for non-PSQL bodies was implemented, and I had
a very small test who does it in the Java plugin. It was more or less as
following:
CREATE PROCEDURE proc EXTERNAL ENGINE JAVA ENTRYPOINT
'mytest.JavaText.javaText'
AS
Q'{
public static void proc()
{
...
}
}'
The idea with Q'{ ... }' is that single quotes are allowed in the text
without escapes. It may also be Q'[ ... ]', Q'( ... )' or Q'$ ... $', etc
In the example, the engine don't need to known anything more. The
responsible to compile the body is the entrypoint.
> That should be solved the same way it is solved for Java. In few
> words, the shared library would get few function pointers during
> initialization (therefore, you would need to have an "init" entry
> point in DLL) from which it would be able to fetch database API.
> Previously that was a list of isc_XXXX entry points plus two
> additional functions to fetch db_handle and tr_handle for the current
> context. I guess Adriano made this API object-oriented now, but the
> idea should be the same.
The external routines receives the handles from the engine, it it can
just use fbclient functions with them.
>> 3.4 FreePascal will need to use the Firebird memory manager. Using
>> various memory managers is fortunately already possible in FPC.
> Most likely yes, for Java that was not a big issue.
Should neither be a issue.
>> 3.5 Most importantlY: it will probably require a lot of work on both
>> ends to get this done. Fortunately, both Firebird and FPC have an
>> active
>> developer community with good communication and bug tracker systems,
>> so
>> this helps.
> I guess the first version would be pretty easy to get implemented. The
> biggest issue for the user acceptance I see the extending of the DDL
> language, so that one can create a single DB script, from which the
> procedures would be compiled, stored in the DB, could be backup-ed and
> restored. Then security - when I created procedures on one host, backup
> the DB and restore it on a different host, how do I ensure that the
> restrictions of that host apply? Am I able to have some kind of a
> sandbox for directly executable code (in Java I can have a security
> manager that would protect the file or network access)...
>
Should be easy to write it to use binary files. It's just need to make
the new API usable by Pascal and implement some layer to better
integrate with it.
But the API is not finished at the moment.
Adriano
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
