I change the subject "Re: Linked Tables feature request" for this specific.
>> It maybe be better remove it from the core of h2 and pass it to an extension
>> module (h2-linked.jar) , as the "contrib" of other databases.
>>
> The question is what is the 'right'
> abstraction, and how does the extension module system look like.
> Currently I think it's user defined functions, but there should be a
> better way to integrate them.
>
UDFs are a natural way to make lightweight extensions of core
functionality and , as in Postgres contrib,
can be simple sets of related UDFs by problem domain or use , as an sql
text file with an additional .jar for the code if it's needed.
Maybe with a new command like: * LOAD_EXTENSION some_jar_fullpath*
that jar contains code and a sql text file inside for automation of
ALIASs creation - all contained in the same jar .
Another advantage of this approach can/would be bypass the requirement
of adding extension jars to the classpath.
If don't like create a new command , can be used some system property or
environment variable to hold the list of extensions jars to be loaded
at startup.
This approach organize and empower actual UDFs implementation, but it's
equally or more important to define a public set of core internal
classes or methods (or api)
to be exposed and documented for UDF usage , as the "legal" contact
points with the H2's core.
This set of exposed core components can be a simple form of public
interface to create extensions.
I think that we need one more artifact to create extensions to mate with
the core with minimal interdependence.
We need a name-space and map to hold and reference objects accesible
from both UDFs and the core ( and SQL).
It can be an extension of actual SET @ , to define variables visible
at sql level by name and within the UDF through utility class:
In UDFs;
VariableType objectVarValue = new VariableType( someJavaObject ,
VariableType.SOME_SUPPORTED_VAR_TYPE );
UnfencedVariablesSpace.getReference().put( "varname",
objectVarValue );
VariableType objectVarValue =
UnfencedVariablesSpace.getReference().get( "varname" );
Object someJavaObject = objectVarValue.getWrappedObject();
And in SQL:
SET @VARNAME = expresion;
call SETVAR( 'varname', expresion );
call GETVAR( 'varname' );
I hope some of this helps, but if not just throw it away and forget it.
regards,
Dario
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
