Hi Thomas,
you are who can evaluate this with criterion from your complete and
thorough knowledge of the code.
My opinions are from point of view of a user who has enjoyed and
suffered different extension implementations in many different databases
over the years;
but I take many assumptions about what approach can be harder to implement.
El 23/02/10 16:35, Thomas Mueller escribió:
>> But for an extension stated as a pack of related UDFs and support code
>> , in don't believe that an SPI approach can be used.
>>
> Why not?
>
SPI , as I understand, it's better suited to define "alternative
implementations of some concrete function or characteristic" that is
by nature or convenience pluggable or replaceable,
and limited by interfaces that define what can be replaced and the
contract of how this need to be done to mate with the core.
Table implementations, indexes implementations, transport protocols,
etc. are good candidates for SPI with specialized versions for distinct
uses .
I cant figure out why such a contract or interface will be necessary to
only add new functions.
In the case of an extension as a set of related UDFs only a few
communication and installation facilities are need:
1) Packaging & Installing : Automation of alias creation and
persistence of definitions as database objects.
2) Extend the VARIABLES possibilities as more generic object-holder
accessible from SQL and UDF as a bus between they for collaboration .
THIS IS THE CENTRAL POINT and main limitation of what can be done
right now.
>> I think that we are talking of two different things:
>>
>> 1) Plug-ins: SPI candidate with tight relation to core central functions.
>> 2) Extensions: Addons of UDF sets with minimal core compromise that
>> must to be part of database itself.
>>
>> Plugins can be database configuration components , on the other hand
>> Extensions must to be database's objects.
>>
> I don't see a clear distinction here. Fulltext indexes are also
> 'database objects' in a way, yet they are implemented as User Defined
> Functions (UDFs).
>
All of this can be implemented as UDFs or with what ever be the best
implementation option ; but since they are different in purpose and
scope it's better to design with that in mind.
Main distinction it's that extensions are mostly to ADD collateral
functions and don't has the hassle to "REPLACE" core functionality ,
even critical functions that need to be contained and directed in some
way by interfaces that define the insertion points for plugins (what
core functions are 3er party provided).
>> If someone create a database and define a view that use and UDF ; then
>> create a backup and send to another place;
>> all need components to maintain that view operative must to be in the
>> backup as any other database object.
>>
> Yes. For CREATE ALIAS ... AS ..., the source code of the function is
> actually stored in the database. Currently there is no way to create a
> function using the bytecode (store the bytecode in the database). This
> feature could be added. I will add a feature request for:
>
> "User defined functions: allow to store the bytecode (of just the
> class, or the jar file of the extension) in the database."
>
This is a great starting point for consistency and portability ; but at
the same time will be necessary some definition / installation command
or tool.
And if we add a simple jar layout to automate alias creation in the same
process , then we can namely call that "an extension" ! :-)
What do you think about simply to use a database subdirectory for
deploy the extensions jars ; and advance over installation first.
Backup only need to include that directory ( until store bytecode can be
done ) to get portability in it's simplest form.
It's a shorter path to cover all the way: packaging, deploy and
activation of an extension , that can be perfected later.
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.
