|Subject||Re: [Firebird-Architect] Re: Java Stored Procedures|
> > For me it is *not* a priority, but adding a RDB$JAVA table, withHaving the source code stored is a "plus" in my book.
> > name, source and bytecode would be an option. If the plugin cannot
> > find the class, it looks it up in this table. If found, it moves the
> > code into a classpath directory and tries again. If the name is not
> > in the table either, or the code blob is null it reports 'not
> > found'.
> It can be implemented even more easier if we consider the classloader
> hierarchy in Java. This can be implemented at the same time when
> dynamic deployment is implemented.
> > The create statement would take source and compile it using an
> > external java compiler.
> You can use compiler from the JDK in the tools.jar.
> > If the compile fails, it stores a NULL in the
> > code blob.
> Why not to throw an error and do not store anything there?
I'll opt for "invalid objects" again, like in Oracle. I like that. It's
also easier with regard to dependencies.
> > It would need to clear the relevant class from the cacheWhich can be "xcopied" as well.
> > directory of course.
> With classloader hierarchy this is not needed, Java can load classes
> from any input stream, and BLOB is as good as file system or network
> > The big advantage of such a setup would be that databases remain
> > self-contained ("xcopy installable").
> Questionable, since the compiled class often relies on the external
> libraries, which are located on the file system.
> So we would need toImplement the SQL standard for blob values then...
> invent something like CREATE JAVA LIBRARY to be able to store .jar in
> the database. This however has an issue that you cannot use it from
> isql, since you cannot specify binary BLOB content in DSQL. And so on.
X' < hex values > '
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Database development questions? Check the forum!