Hi Sergi,
>> Maybe with a new command like: * LOAD_EXTENSION some_jar_fullpath*
>>
> The bad thing in such approach that each time database created you
> will need run initialization script like
> LOAD_EXTENSION some_ext1.jar;
> LOAD_EXTENSION some_ext2.jar;
> LOAD_EXTENSION some_ext3.jar;
> etc...
>
I'm thinking in a persistent effect of that command , implemented and
known by the core and stored in a specific system table in
INFORMATION_SCHEMA.
Let say something like:
CREATE EXTENSION ext_id_name ext_jar_fullpath;
DROP EXTENSION ext_id_name ext_jar_fullpath;
On CREATE EXTENSION the core must to do;
1) Check availability of referenced jar and previous definition of ext_id
2) Copy the referenced jar into a "*./plugins*" subdirectory of
database directory to assert the jar availability and to be included on
database backups.
3) Load referenced jar that is not in classpath ( some way like:
http://www.javaworld.com/javaworld/javatips/jw-javatip70.html)
4) Process "create-plugin.sql" included in the jar for CREATE ALIAS
automation (can be used some jar manifest attributes to support this)
5) Update system table in INFORMATION_SCHEMA with new extension and ALIASes
On database start , all plugins on ./dbdir/plugins/*.jar , are actived
and dynamically loaded as in above step (3).
On drop extension: remove the jar on /plugins , drop alias , delete
definition on INFORMATION_SCHEMA.
> In addition better to have system property in which we will list all
> the classnames of plugins
> which should be instantiated and initialized for each new database.
>
Yes can be a way, but nothing of this goes to a database backup, only
the ALIAS definition , and you don't have any guaranty about
extension-jar availability.
If you restore a backup on other host , you restore ALIASES that can't work.
> By the way. I'm thinking about pluggable table implementations. Like
> this
> CREATE TABLE T1
> (ID INT, NAME VARCHAR)
> ENGINE "com.aaa.MegaCoolTableFactory"
> this class will have factory method which will return
> org.h2.table.Table instance.
> Thoughts, suggestions
This will be nice, but I really don't know what effort mean this, and
what will be Thomas's opinion.
For now we should concentrate on outlining a proposal to for basic
building blocks of an ordered implementation of extensions / plugins in
such a way that has minimal impact and dependencies with H2 core.
And as Thomas stated , UDF's are the preferred way for extensions.
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.
