Hi Team,
Thomas has had a look at a first cut of the "embedded Java" code and wanted
to open the discussion
out to include you folks.
In the current version I have tried to do two primary things:
1. Add the ability to embed Java code into the database, instead of forcing
it to be on the classpath.
2. Allowing that code to be easily accessed from a TRIGGER, ALIAS or
AGGREGATE.
I also wanted to:
3. Make writing triggers simple.
4. Put in place something that will be able to be used by other languages in
the future.
I think we can achieve #1 and #2 with what we have now -- and get close to
#3
with a new class "SimpleTrigger" that simply hides the normally-unused
methods
init, close and remove (not DynamicTrigger or DynamicTriggerAdapter) that
the
user could extend. eg:
CREATE CODE MyTriggerCode LANGUAGE JAVA AS
$$
extends SimpleTrigger {
public void fire(Connection conn, Object[] oldRow, Object[] newRow)
throws SQLException {
Integer salary = ((Integer) newRow[0]);
if (salary <= 500) {
newRow[0] = 10000;
}
}
}
$$
... but then I wonder what the Groovy equivalent of this would be. What will
it have to extend?
Perhaps we should follow the Postgres lead, which explicitly tells the back
end what flavour of
code this is. What about a FOR TRIGGER clause which could, behind the
scenes, create a class that
extends "SimpleTrigger" and embeds the provided code within a "fire" method,
and makes "init"
parameters available:
CREATE CODE MyTriggerCode LANGUAGE JAVA FOR TRIGGER AS
$$
Integer salary = ((Integer) newRow[0]);
if ((type == INSERT) && (salary <= 500)) {
newRow[0] = 10000;
}
$$
... then our Groovy equivalent would be something like the following (I have
no idea what the
backend would look like, but I think that's fine at this stage. At least we
don't have any
Java code bleeding into the Groovy trigger)
CREATE CODE MyTriggerCode LANGUAGE GROOVY FOR TRIGGER AS
$$
if (newRow[0] <= 500) {
newRow[0] = 10000
}
$$
Take a look at the Postgres code:
CREATE FUNCTION sal_check() RETURNS trigger AS
$$
BEGIN
IF NEW.salary <= 500 THEN
NEW.salary := 10000;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER sal_check BEFORE INSERT OR UPDATE ON emp
FOR EACH ROW EXECUTE PROCEDURE sal_check();
So, in summary, here's my latest thinking:
1. Remove the DynamicTrigger and DynamicTriggerAdapter logic
2. Rename "CREATE CODE" (and friends) to "CREATE MODULE"
3. Implement " [ FOR { TRIGGER | ALIAS | AGGREGATE } ]" which would build
Java classes appropriate for each command.
The existing logic in TriggerObject, FunctionAlias and UserAggregate
would essentially remain unchanged
(they'll just look for the static methods or interfaces they expect
today).
Note that use of "FOR TRIGGER" etc would be optional. The user could
still write classes that implement
org.h2.api.Trigger if they want to.
4. Implement Groovy etc support later, perhaps by making Java wrapper
classes, meaning we still won't have to
change TriggerObject, FunctionAlias or UserAggregate.
Finally, another question. What about making the "FOR TRIGGER" support even
prettier? Would you be adverse to
syntax like this -- even though it might be a bit slower than the current
syntax:
CREATE CODE MyTriggerCode JAVA FOR TRIGGER AS
$$
if (insert && (new.getInt("salary") <= 500)) {
new.setInt("salary", 10000);
}
$$
Cheers
Kerry
On Mon, Jul 19, 2010 at 3:28 AM, Thomas Mueller <
thomas.tom.muel...@gmail.com> wrote:
> Hi,
>
> Sorry for the delay. And thanks for the patch!
>
> What I don't like is the "magic" that in getTriggerAdapterFireMethod
> and DynamicTrigger and DynamicTriggerAdapter. Is it really required to
> do all that? If somebody wants to write a trigger, I think it's no big
> deal for him to add the lines "public class ... implements
> TriggerAdapter {" and "}". I really wouldn't add the automatic
> detection, because it's hard to maintain, and "too much magic" in my
> view (makes life for the user harder, not easier). Maybe even the
> automatic import is not required (so just copy everything except the
> "package" line).
>
> Should we discuss this in the Google Group?
>
> Regards,
> Thomas
>
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to h2-datab...@googlegroups.com.
To unsubscribe from this group, send email to
h2-database+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
