Re: H2 embedded Java suggestion
Hi, It just eases the deployment of some whose deployment software has difficulties in deploying java classes into h2's classpath. Yes, that's the main problem in my view. Writing triggers or stored procedures in other databases doesn't require the user to manually copy binary files onto the filesystem of the database server -- that's *weird* and, IMHO, ugly. I agree, there should be a way to add classes using the source code or by uploading the jar file. 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.
Re: H2 embedded Java suggestion
Hi Thomas, Are you happy, enough, with the following -- as described in an earlier email: 1. Use this syntax to define a code module: CREATE MODULE WIBBLE AS $$ import java.sql.*; public class MyNotWibbleCode ... $$ but the classname is completely irrelevent -- we just use whatever methods we happen to find defined within the 'module'. 2. When referring to a module in, for example, CREATE TRIGGER, it's the MODULE name, not the classname. CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL WIBBLE 3. No support for packages. Internally all classes live in the existing org.h2.dynamic package used for user-defined classes. 4. No support for uploading jars (at least not yet). I'm not sure I like the idea, or the potential associated JVM byte-code version issues. ... if so then I'll finish up the code and we can all get on with the rest of our lives. This horse has been flogged! Thanks Kerry On Thu, Aug 26, 2010 at 6:10 AM, Thomas Mueller thomas.tom.muel...@gmail.com wrote: Hi, It just eases the deployment of some whose deployment software has difficulties in deploying java classes into h2's classpath. Yes, that's the main problem in my view. Writing triggers or stored procedures in other databases doesn't require the user to manually copy binary files onto the filesystem of the database server -- that's *weird* and, IMHO, ugly. I agree, there should be a way to add classes using the source code or by uploading the jar file. 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.comh2-database%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/h2-database?hl=en. -- 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.
Re: H2 embedded Java suggestion
Hi,
I think it's somewhat unlogical (at least inconsistent) that a module
doesn't have a name when you create it, but has a name when you drop
it. I would prefer it having a name in both cases. The name doesn't
need to match the class name.
You have used an unnamed package. Does this mean the package name can
be specified in the source code. First I thought that's a bit
dangerous, but it's probably not a problem (it's not a bigger security
risk) and more logical that way.
By the way, did you see
http://h2database.com/javadoc/org/h2/tools/TriggerAdapter.html ? It's
very similar to SimpleTrigger - only it uses result sets instead of
arrays. Maybe we should add a second TriggerAdapter with arrays?
Regards,
Thomas
On Thu, Aug 5, 2010 at 6:25 AM, Kerry Sainsbury ke...@fidelma.com wrote:
Hi Thomas,
How do you like this example. It's very simple. Basically you copy and paste
Java code and call it a MODULE. The class can then be called from whatever
wants it (and I can easily implement my simpler trigger idea just by putting
in a SimpleTrigger class that I can extend in another module. Note there
is no need to name a module, as we can just use the class name:
CREATE MODULE AS
$$
import java.sql.*;
import org.h2.api.Trigger;
public abstract class SimpleTrigger implements Trigger {
public void init(Connection conn, String schemaName, String
triggerName, String tableName, boolean before, int type) throws SQLException
{
}
public abstract void fire(Connection conn, Object[] oldRow,
Object[] newRow) throws SQLException;
public void close() throws SQLException {
}
public void remove() throws SQLException {
}
}
$$
CREATE MODULE AS
$$
import java.sql.*;
public class MyTrigger extends SimpleTrigger {
public void fire(Connection conn, Object[] oldRow, Object[] newRow)
throws SQLException {
newRow[0] = ((String)newRow[0]).toUpperCase();
}
}
$$
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL MyTrigger
DROP TRIGGER TRIG_INS
DROP MODULE MyTrigger
DROP MODULE SimpleTrigger
What do you think?
Cheers
Kerry
On Thu, Jul 22, 2010 at 8:02 AM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
I think the
CREATE CODE MyTriggerCode LANGUAGE JAVA FOR TRIGGER AS
is very verbose. What about:
CREATE TRIGGER ... AS?
That's similar syntax as CREATE ALIAS ... AS.
H2 only supports Java currently, so there is no reason to require
JAVA. Once other languages are supported it can still be added as an
option.
However I'm not sure if it makes sense to provide shortcut to directly
register a trigger as source code *snippet* (that is, only the fire
method). I think it's no problem to require the source code of the
*complete* class in this case. If you write short static function,
then the current CREATE ALIAS ... AS source is handy (I used it many
times). But if you write a trigger, you anyway do that in the IDE,
meaning you anyway have the source code of the complete class
somewhere. Because you want to use auto-complete of the IDE, and so
forth. Triggers are almost never as simple as a Java function.
I think if we want to support CREATE CODE then this should be only
used to add classes to the internal classpath of H2. Independent of
for what those classes are used (trigger, aggregate, function
alias,...), and therefore without any magic to adopt to the right type
/ add missing glue code. Even without automatically adding import
statements. Those classes can then be used for many things. For
example a class that contains multiple public static methods plus a
trigger (or even multiple triggers using inner classes). Or it could
even contain multiple classes, or a jar file (which would be stored in
the database). Instead of CREATE CODE what about CREATE MODULE or
CREATE LIBRARY? There could be a module / library for MySQL helper
functions, for PostgreSQL helper functions, and so on. Like a Apache
HTTP module. There should be an way to auto-start, maybe using a
method in the loaded library.
Existing features could then be retro-fitted as modules / libraries.
For example fulltext search.
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.
--
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
Re: H2 embedded Java suggestion
Hi Thomas,
On Thu, Aug 19, 2010 at 5:35 AM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
I think it's somewhat unlogical (at least inconsistent) that a module
doesn't have a name when you create it, but has a name when you drop
it. I would prefer it having a name in both cases. The name doesn't
need to match the class name.
I did start with naming the module at create time, but it seemed silly to
define a name in two places, eg:
CREATE MODULE WIBBLE AS
$$
import java.sql.*;
public class Wibble
...
$$
Is it desirable that module vs class name could be different? DON'T REPEAT
YOURSELF was shouting in my ear.
What name would you expect to use when used as part of, for example, CREATE
TRIGGER -- module or classname? If classname, then do you also want the
package name to be required? (Currently I've not got support for packages --
they go into the existing org.h2.dynamic package used for user-defined
classes)
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL WIBBLE
--- Am I calling a module or a classname?
Perhaps the classname is completely irrelevent -- we just use whatever class
we happen to find defined within the 'module'?
You have used an unnamed package. Does this mean the package name can
be specified in the source code. First I thought that's a bit
dangerous, but it's probably not a problem (it's not a bigger security
risk) and more logical that way.
As above -- I'm thinking that there doesn't need to be any support for
packages.
By the way, did you see
http://h2database.com/javadoc/org/h2/tools/TriggerAdapter.html ? It's
very similar to SimpleTrigger - only it uses result sets instead of
arrays.
I know TriggerAdapter well -- it's just that a ResultSet isn't very good at
letting you change values :-)
Maybe we should add a second TriggerAdapter with arrays?
As you know, I support anything that reduces the code required to write a
simple trigger!
Cheers
Kerry
Regards,
Thomas
On Thu, Aug 5, 2010 at 6:25 AM, Kerry Sainsbury ke...@fidelma.com wrote:
Hi Thomas,
How do you like this example. It's very simple. Basically you copy and
paste
Java code and call it a MODULE. The class can then be called from
whatever
wants it (and I can easily implement my simpler trigger idea just by
putting
in a SimpleTrigger class that I can extend in another module. Note
there
is no need to name a module, as we can just use the class name:
CREATE MODULE AS
$$
import java.sql.*;
import org.h2.api.Trigger;
public abstract class SimpleTrigger implements Trigger {
public void init(Connection conn, String schemaName, String
triggerName, String tableName, boolean before, int type) throws
SQLException
{
}
public abstract void fire(Connection conn, Object[] oldRow,
Object[] newRow) throws SQLException;
public void close() throws SQLException {
}
public void remove() throws SQLException {
}
}
$$
CREATE MODULE AS
$$
import java.sql.*;
public class MyTrigger extends SimpleTrigger {
public void fire(Connection conn, Object[] oldRow, Object[]
newRow)
throws SQLException {
newRow[0] = ((String)newRow[0]).toUpperCase();
}
}
$$
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL
MyTrigger
DROP TRIGGER TRIG_INS
DROP MODULE MyTrigger
DROP MODULE SimpleTrigger
What do you think?
Cheers
Kerry
On Thu, Jul 22, 2010 at 8:02 AM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
I think the
CREATE CODE MyTriggerCode LANGUAGE JAVA FOR TRIGGER AS
is very verbose. What about:
CREATE TRIGGER ... AS?
That's similar syntax as CREATE ALIAS ... AS.
H2 only supports Java currently, so there is no reason to require
JAVA. Once other languages are supported it can still be added as an
option.
However I'm not sure if it makes sense to provide shortcut to directly
register a trigger as source code *snippet* (that is, only the fire
method). I think it's no problem to require the source code of the
*complete* class in this case. If you write short static function,
then the current CREATE ALIAS ... AS source is handy (I used it many
times). But if you write a trigger, you anyway do that in the IDE,
meaning you anyway have the source code of the complete class
somewhere. Because you want to use auto-complete of the IDE, and so
forth. Triggers are almost never as simple as a Java function.
I think if we want to support CREATE CODE then this should be only
used to add classes to the internal classpath of H2. Independent of
for what those classes are used (trigger, aggregate, function
alias,...), and therefore without any magic to adopt to the right type
/ add missing glue code. Even without
Re: H2 embedded Java suggestion
I've thought about this a bit more, and wanted to advocate for including the
module name in the CREATE MODULE command, and for ignoring the actual class
name that will exist in the code. Therefore commands like CREATE TRIGGER
will be referring to MODULE names, not classnames.
This is primarily so we *could* in the future, if you wanted to, support
non-Java-based syntax more easily.
Agreed?
Cheers
Kerry
On Thu, Aug 19, 2010 at 8:51 AM, Kerry Sainsbury ke...@fidelma.com wrote:
Hi Thomas,
On Thu, Aug 19, 2010 at 5:35 AM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
I think it's somewhat unlogical (at least inconsistent) that a module
doesn't have a name when you create it, but has a name when you drop
it. I would prefer it having a name in both cases. The name doesn't
need to match the class name.
I did start with naming the module at create time, but it seemed silly to
define a name in two places, eg:
CREATE MODULE WIBBLE AS
$$
import java.sql.*;
public class Wibble
...
$$
Is it desirable that module vs class name could be different? DON'T REPEAT
YOURSELF was shouting in my ear.
What name would you expect to use when used as part of, for example,
CREATE TRIGGER -- module or classname? If classname, then do you also want
the package name to be required? (Currently I've not got support for
packages -- they go into the existing org.h2.dynamic package used for
user-defined classes)
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL WIBBLE
--- Am I calling a module or a classname?
Perhaps the classname is completely irrelevent -- we just use whatever
class we happen to find defined within the 'module'?
You have used an unnamed package. Does this mean the package name can
be specified in the source code. First I thought that's a bit
dangerous, but it's probably not a problem (it's not a bigger security
risk) and more logical that way.
As above -- I'm thinking that there doesn't need to be any support for
packages.
By the way, did you see
http://h2database.com/javadoc/org/h2/tools/TriggerAdapter.html ? It's
very similar to SimpleTrigger - only it uses result sets instead of
arrays.
I know TriggerAdapter well -- it's just that a ResultSet isn't very good at
letting you change values :-)
Maybe we should add a second TriggerAdapter with arrays?
As you know, I support anything that reduces the code required to write a
simple trigger!
Cheers
Kerry
Regards,
Thomas
On Thu, Aug 5, 2010 at 6:25 AM, Kerry Sainsbury ke...@fidelma.com
wrote:
Hi Thomas,
How do you like this example. It's very simple. Basically you copy and
paste
Java code and call it a MODULE. The class can then be called from
whatever
wants it (and I can easily implement my simpler trigger idea just by
putting
in a SimpleTrigger class that I can extend in another module. Note
there
is no need to name a module, as we can just use the class name:
CREATE MODULE AS
$$
import java.sql.*;
import org.h2.api.Trigger;
public abstract class SimpleTrigger implements Trigger {
public void init(Connection conn, String schemaName, String
triggerName, String tableName, boolean before, int type) throws
SQLException
{
}
public abstract void fire(Connection conn, Object[] oldRow,
Object[] newRow) throws SQLException;
public void close() throws SQLException {
}
public void remove() throws SQLException {
}
}
$$
CREATE MODULE AS
$$
import java.sql.*;
public class MyTrigger extends SimpleTrigger {
public void fire(Connection conn, Object[] oldRow, Object[]
newRow)
throws SQLException {
newRow[0] = ((String)newRow[0]).toUpperCase();
}
}
$$
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL
MyTrigger
DROP TRIGGER TRIG_INS
DROP MODULE MyTrigger
DROP MODULE SimpleTrigger
What do you think?
Cheers
Kerry
On Thu, Jul 22, 2010 at 8:02 AM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
I think the
CREATE CODE MyTriggerCode LANGUAGE JAVA FOR TRIGGER AS
is very verbose. What about:
CREATE TRIGGER ... AS?
That's similar syntax as CREATE ALIAS ... AS.
H2 only supports Java currently, so there is no reason to require
JAVA. Once other languages are supported it can still be added as an
option.
However I'm not sure if it makes sense to provide shortcut to directly
register a trigger as source code *snippet* (that is, only the fire
method). I think it's no problem to require the source code of the
*complete* class in this case. If you write short static function,
then the current CREATE ALIAS ... AS source is handy (I used it many
times). But if you write a trigger, you anyway do that in the IDE,
meaning
Re: H2 embedded Java suggestion
OMG!
Are you seriously planning to support some other languages?
I mean ... wtf?!?
Seriously, you guys are arguing about syntax sugaring.
And it is no shame to place the name in a natural place from sql point
of view.
What you are dong is mixing two languages so it is clear that there can
arise the doubling-effect.
What I am really wondering is the real benefit of this embedded syntax.
I mean it does not bring anything new.
It just eases the deployment of some whose deployment software has
difficulties in deploying java classes into h2's classpath.
But maybe there is a use case I have not considered.
- rami
On 19.8.2010 2:56, Kerry Sainsbury wrote:
I've thought about this a bit more, and wanted to advocate for
including the module name in the CREATE MODULE command, and for
ignoring the actual class name that will exist in the code. Therefore
commands like CREATE TRIGGER will be referring to MODULE names,
not classnames.
This is primarily so we /could/ in the future, if you wanted to,
support non-Java-based syntax more easily.
Agreed?
Cheers
Kerry
On Thu, Aug 19, 2010 at 8:51 AM, Kerry Sainsbury ke...@fidelma.com
mailto:ke...@fidelma.com wrote:
Hi Thomas,
On Thu, Aug 19, 2010 at 5:35 AM, Thomas Mueller
thomas.tom.muel...@gmail.com
mailto:thomas.tom.muel...@gmail.com wrote:
Hi,
I think it's somewhat unlogical (at least inconsistent) that a
module
doesn't have a name when you create it, but has a name when
you drop
it. I would prefer it having a name in both cases. The name
doesn't
need to match the class name.
I did start with naming the module at create time, but it seemed
silly to define a name in two places, eg:
CREATE MODULE WIBBLE AS
$$
import java.sql.*;
public class Wibble
...
$$
Is it desirable that module vs class name could be different?
DON'T REPEAT YOURSELF was shouting in my ear.
What name would you expect to use when used as part of, for
example, CREATE TRIGGER -- module or classname? If classname,
then do you also want the package name to be required? (Currently
I've not got support for packages -- they go into the existing
org.h2.dynamic package used for user-defined classes)
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL
WIBBLE --- Am I calling a module or a classname?
Perhaps the classname is completely irrelevent -- we just use
whatever class we happen to find defined within the 'module'?
You have used an unnamed package. Does this mean the package
name can
be specified in the source code. First I thought that's a bit
dangerous, but it's probably not a problem (it's not a bigger
security
risk) and more logical that way.
As above -- I'm thinking that there doesn't need to be any support
for packages.
By the way, did you see
http://h2database.com/javadoc/org/h2/tools/TriggerAdapter.html
? It's
very similar to SimpleTrigger - only it uses result sets
instead of
arrays.
I know TriggerAdapter well -- it's just that a ResultSet isn't
very good at letting you change values :-)
Maybe we should add a second TriggerAdapter with arrays?
As you know, I support anything that reduces the code required to
write a simple trigger!
Cheers
Kerry
Regards,
Thomas
On Thu, Aug 5, 2010 at 6:25 AM, Kerry Sainsbury
ke...@fidelma.com mailto:ke...@fidelma.com wrote:
Hi Thomas,
How do you like this example. It's very simple. Basically
you copy and paste
Java code and call it a MODULE. The class can then be
called from whatever
wants it (and I can easily implement my simpler trigger idea
just by putting
in a SimpleTrigger class that I can extend in another
module. Note there
is no need to name a module, as we can just use the class name:
CREATE MODULE AS
$$
import java.sql.*;
import org.h2.api.Trigger;
public abstract class SimpleTrigger implements Trigger {
public void init(Connection conn, String
schemaName, String
triggerName, String tableName, boolean before, int type)
throws SQLException
{
}
public abstract void fire(Connection conn,
Object[] oldRow,
Object[] newRow) throws SQLException;
public void close() throws SQLException {
}
public void remove() throws SQLException {
}
}
$$
CREATE MODULE AS
$$
import java.sql.*;
Re: H2 embedded Java suggestion
Hi rami,
On Thu, Aug 19, 2010 at 12:47 PM, Rami Ojares rami.oja...@gmail.com wrote:
OMG!
Are you seriously planning to support some other languages?
No, but it might be nice one day :-)
Seriously, you guys are arguing about syntax sugaring.
Yes, but doesn't that matter?
What I am really wondering is the real benefit of this embedded syntax.
I mean it does not bring anything new.
It just eases the deployment of some whose deployment software has
difficulties in deploying java classes into h2's classpath.
Easing deployment is the something new, and is valuable for some people.
Writing triggers or stored procedures in other databases doesn't require the
user to manually copy binary files onto the filesystem of the database
server -- that's *weird* and, IMHO, ugly.
Mind you, I think stored procedures are ugly anyway, but I guess Java ones
are less ugly than bizarre proprietary languages.
Anyway, thanks for the feedback!
Cheers
Kerry
But maybe there is a use case I have not considered.
- rami
On 19.8.2010 2:56, Kerry Sainsbury wrote:
I've thought about this a bit more, and wanted to advocate for including
the module name in the CREATE MODULE command, and for ignoring the actual
class name that will exist in the code. Therefore commands like CREATE
TRIGGER will be referring to MODULE names, not classnames.
This is primarily so we *could* in the future, if you wanted to, support
non-Java-based syntax more easily.
Agreed?
Cheers
Kerry
On Thu, Aug 19, 2010 at 8:51 AM, Kerry Sainsbury ke...@fidelma.comwrote:
Hi Thomas,
On Thu, Aug 19, 2010 at 5:35 AM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
I think it's somewhat unlogical (at least inconsistent) that a module
doesn't have a name when you create it, but has a name when you drop
it. I would prefer it having a name in both cases. The name doesn't
need to match the class name.
I did start with naming the module at create time, but it seemed silly to
define a name in two places, eg:
CREATE MODULE WIBBLE AS
$$
import java.sql.*;
public class Wibble
...
$$
Is it desirable that module vs class name could be different? DON'T REPEAT
YOURSELF was shouting in my ear.
What name would you expect to use when used as part of, for example,
CREATE TRIGGER -- module or classname? If classname, then do you also want
the package name to be required? (Currently I've not got support for
packages -- they go into the existing org.h2.dynamic package used for
user-defined classes)
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL WIBBLE
--- Am I calling a module or a classname?
Perhaps the classname is completely irrelevent -- we just use whatever
class we happen to find defined within the 'module'?
You have used an unnamed package. Does this mean the package name can
be specified in the source code. First I thought that's a bit
dangerous, but it's probably not a problem (it's not a bigger security
risk) and more logical that way.
As above -- I'm thinking that there doesn't need to be any support for
packages.
By the way, did you see
http://h2database.com/javadoc/org/h2/tools/TriggerAdapter.html ? It's
very similar to SimpleTrigger - only it uses result sets instead of
arrays.
I know TriggerAdapter well -- it's just that a ResultSet isn't very good
at letting you change values :-)
Maybe we should add a second TriggerAdapter with arrays?
As you know, I support anything that reduces the code required to write a
simple trigger!
Cheers
Kerry
Regards,
Thomas
On Thu, Aug 5, 2010 at 6:25 AM, Kerry Sainsbury ke...@fidelma.com
wrote:
Hi Thomas,
How do you like this example. It's very simple. Basically you copy and
paste
Java code and call it a MODULE. The class can then be called from
whatever
wants it (and I can easily implement my simpler trigger idea just by
putting
in a SimpleTrigger class that I can extend in another module. Note
there
is no need to name a module, as we can just use the class name:
CREATE MODULE AS
$$
import java.sql.*;
import org.h2.api.Trigger;
public abstract class SimpleTrigger implements Trigger {
public void init(Connection conn, String schemaName, String
triggerName, String tableName, boolean before, int type) throws
SQLException
{
}
public abstract void fire(Connection conn, Object[] oldRow,
Object[] newRow) throws SQLException;
public void close() throws SQLException {
}
public void remove() throws SQLException {
}
}
$$
CREATE MODULE AS
$$
import java.sql.*;
public class MyTrigger extends SimpleTrigger {
public void fire(Connection conn, Object[] oldRow, Object[]
newRow)
throws SQLException {
newRow[0] = ((String)newRow[0]).toUpperCase();
}
Re: H2 embedded Java suggestion
Hi,
Thanks! I will have a look and reply in about one week.
Regards,
Thomas
On Thursday, August 5, 2010, Kerry Sainsbury ke...@fidelma.com wrote:
Hi Thomas,
How do you like this example. It's very simple. Basically you copy and paste
Java code and call it a MODULE. The class can then be called from whatever
wants it (and I can easily implement my simpler trigger idea just by putting
in a SimpleTrigger class that I can extend in another module. Note there is
no need to name a module, as we can just use the class name:
CREATE MODULE AS
$$
import java.sql.*;
import org.h2.api.Trigger;
public abstract class SimpleTrigger implements Trigger {
public void init(Connection conn, String schemaName, String
triggerName, String tableName, boolean before, int type) throws SQLException {
}
public abstract void fire(Connection conn, Object[] oldRow,
Object[] newRow) throws SQLException;
public void close() throws SQLException {
}
public void remove() throws SQLException {
}
}
$$
CREATE MODULE AS
$$
import java.sql.*;
public class MyTrigger extends SimpleTrigger {
public void fire(Connection conn, Object[] oldRow, Object[] newRow)
throws SQLException {
newRow[0] = ((String)newRow[0]).toUpperCase();
}
}
$$
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL MyTrigger
DROP TRIGGER TRIG_INS
DROP MODULE MyTrigger
DROP MODULE SimpleTrigger
What do you think?
Cheers
Kerry
On Thu, Jul 22, 2010 at 8:02 AM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
I think the
CREATE CODE MyTriggerCode LANGUAGE JAVA FOR TRIGGER AS
is very verbose. What about:
CREATE TRIGGER ... AS?
That's similar syntax as CREATE ALIAS ... AS.
H2 only supports Java currently, so there is no reason to require
JAVA. Once other languages are supported it can still be added as an
option.
However I'm not sure if it makes sense to provide shortcut to directly
register a trigger as source code *snippet* (that is, only the fire
method). I think it's no problem to require the source code of the
*complete* class in this case. If you write short static function,
then the current CREATE ALIAS ... AS source is handy (I used it many
times). But if you write a trigger, you anyway do that in the IDE,
meaning you anyway have the source code of the complete class
somewhere. Because you want to use auto-complete of the IDE, and so
forth. Triggers are almost never as simple as a Java function.
I think if we want to support CREATE CODE then this should be only
used to add classes to the internal classpath of H2. Independent of
for what those classes are used (trigger, aggregate, function
alias,...), and therefore without any magic to adopt to the right type
/ add missing glue code. Even without automatically adding import
statements. Those classes can then be used for many things. For
example a class that contains multiple public static methods plus a
trigger (or even multiple triggers using inner classes). Or it could
even contain multiple classes, or a jar file (which would be stored in
the database). Instead of CREATE CODE what about CREATE MODULE or
CREATE LIBRARY? There could be a module / library for MySQL helper
functions, for PostgreSQL helper functions, and so on. Like a Apache
HTTP module. There should be an way to auto-start, maybe using a
method in the loaded library.
Existing features could then be retro-fitted as modules / libraries.
For example fulltext search.
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.
--
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.
--
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.
Re: H2 embedded Java suggestion
Hi Thomas,
How do you like this example. It's very simple. Basically you copy and paste
Java code and call it a MODULE. The class can then be called from whatever
wants it (and I can easily implement my simpler trigger idea just by putting
in a SimpleTrigger class that I can extend in another module. Note there
is no need to name a module, as we can just use the class name:
CREATE MODULE AS
$$
import java.sql.*;
import org.h2.api.Trigger;
public abstract class SimpleTrigger implements Trigger {
public void init(Connection conn, String schemaName, String
triggerName, String tableName, boolean before, int type) throws SQLException
{
}
public abstract void fire(Connection conn, Object[] oldRow,
Object[] newRow) throws SQLException;
public void close() throws SQLException {
}
public void remove() throws SQLException {
}
}
$$
CREATE MODULE AS
$$
import java.sql.*;
public class MyTrigger extends SimpleTrigger {
public void fire(Connection conn, Object[] oldRow, Object[] newRow)
throws SQLException {
newRow[0] = ((String)newRow[0]).toUpperCase();
}
}
$$
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL MyTrigger
DROP TRIGGER TRIG_INS
DROP MODULE MyTrigger
DROP MODULE SimpleTrigger
What do you think?
Cheers
Kerry
On Thu, Jul 22, 2010 at 8:02 AM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
Hi,
I think the
CREATE CODE MyTriggerCode LANGUAGE JAVA FOR TRIGGER AS
is very verbose. What about:
CREATE TRIGGER ... AS?
That's similar syntax as CREATE ALIAS ... AS.
H2 only supports Java currently, so there is no reason to require
JAVA. Once other languages are supported it can still be added as an
option.
However I'm not sure if it makes sense to provide shortcut to directly
register a trigger as source code *snippet* (that is, only the fire
method). I think it's no problem to require the source code of the
*complete* class in this case. If you write short static function,
then the current CREATE ALIAS ... AS source is handy (I used it many
times). But if you write a trigger, you anyway do that in the IDE,
meaning you anyway have the source code of the complete class
somewhere. Because you want to use auto-complete of the IDE, and so
forth. Triggers are almost never as simple as a Java function.
I think if we want to support CREATE CODE then this should be only
used to add classes to the internal classpath of H2. Independent of
for what those classes are used (trigger, aggregate, function
alias,...), and therefore without any magic to adopt to the right type
/ add missing glue code. Even without automatically adding import
statements. Those classes can then be used for many things. For
example a class that contains multiple public static methods plus a
trigger (or even multiple triggers using inner classes). Or it could
even contain multiple classes, or a jar file (which would be stored in
the database). Instead of CREATE CODE what about CREATE MODULE or
CREATE LIBRARY? There could be a module / library for MySQL helper
functions, for PostgreSQL helper functions, and so on. Like a Apache
HTTP module. There should be an way to auto-start, maybe using a
method in the loaded library.
Existing features could then be retro-fitted as modules / libraries.
For example fulltext search.
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.comh2-database%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
--
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.
Re: H2 embedded Java suggestion
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] = 1;
}
}
}
$$
... 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] = 1;
}
$$
... 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] = 1
}
$$
Take a look at the Postgres code:
CREATE FUNCTION sal_check() RETURNS trigger AS
$$
BEGIN
IF NEW.salary = 500 THEN
NEW.salary := 1;
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, 1);
}
$$
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.
Re: H2 embedded Java suggestion
Rhino Javascript Intepreter - bundled with jdk1.6, and later - the version downloaded from website requires java 1.4 or later - http://www.mozilla.org/rhino/ BeanShell - java interpriter - requires java 1.3, or later for all features - current version (1.3) is really small - http://www.beanshell.org/ Groovy (dynamic scripting language) - http://groovy.codehaus.org/ Brish -- 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.
Re: H2 embedded Java suggestion
Hi, Not exactly sure what you are aiming for, but how about javascript? That's already written and understood with lots of research going into JIT interpreters for it. Yes. There is a Scripting Engine (javax.script) binding for JavaScript in Java 6. There are a few disadvantages: it requires Java 6 (is there a workaround to use it in Java 5?). 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.
Re: H2 embedded Java suggestion
I have no idea. However, with a little extra work you could set it up such that the feature is available on 1.6 but not on earlier versions. Personally, I wouldn't think that is unreasonable. If it is one's choice to live on legacy software then he must accept that there are prices to pay for that choicemeaning he may not get all the new gizmos and doo-dads available on newer platforms. On Jul 2, 2010, at 3:04 AM, Thomas Mueller wrote: Hi, Not exactly sure what you are aiming for, but how about javascript? That's already written and understood with lots of research going into JIT interpreters for it. Yes. There is a Scripting Engine (javax.script) binding for JavaScript in Java 6. There are a few disadvantages: it requires Java 6 (is there a workaround to use it in Java 5?). 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. -- 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.
Re: H2 embedded Java suggestion
Hi, Would it be a good thing if we could store any Java code that could be used within H2, within H2 itself? Yes. I will add a feature requests: - Trigger: allow declaring as source code (like functions). - User defined aggregate: allow declaring as source code (like functions). I'm not so sure about database event listeners. I guess usually they are set when connecting, and you probably don't want to pass the source code within the database URL. And I don't think it's required for other components such as TableEngine and FileSystem. does not require all org.h2.api.Trigger interface methods to be implemented I suggest it should extend the new org.h2.tools.TriggerAdapter. built in procedural language I thought about that as well. I guess at some point it should be supported for compatibility (PL/SQL, Transact-SQL). So a parser is needed. Writing a interpreter or compiler however may not be required. Instead, the parser could generate Java source code. The advantages would be: faster execution speed, smaller H2 jar file, less source code, easier to maintain. The disadvantage is that you need a Java compiler at runtime, but so far this doesn't seem to be a problem for most people. As an alternative to Java source code, the Java 6 scripting engine (javax.script) could be used. creating a whole new programming language There are already quite many programming languages... I would like to avoid that, except for compatibility. 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.
Re: H2 embedded Java suggestion
Not exactly sure what you are aiming for, but how about javascript? That's already written and understood with lots of research going into JIT interpreters for it. On Jun 30, 2010, at 11:36 AM, Thomas Mueller wrote: built in procedural language I thought about that as well. I guess at some point it should be supported for compatibility (PL/SQL, Transact-SQL). So a parser is needed. Writing a interpreter or compiler however may not be required. Instead, the parser could generate Java source code. The advantages would be: faster execution speed, smaller H2 jar file, less source code, easier to maintain. The disadvantage is that you need a Java compiler at runtime, but so far this doesn't seem to be a problem for most people. As an alternative to Java source code, the Java 6 scripting engine (javax.script) could be used. -- 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.
Re: H2 embedded Java suggestion
Hi, I see what you're saying. I guess all I'm offering is another way to package the Java code that H2 already supports. You can add it to the classpath, like you do now, or you can put it inside the database. The functionality is essentially identical. All it really gives you is another deployment option. Creating a whole new programming language is a little outside of the scope of my suggestion, but as Thomas likes to say patches are welcome :-) Cheers Kerry On Thu, Jun 24, 2010 at 6:20 PM, Brish bris...@gmail.com wrote: On Jun 23, 10:41 pm, Kerry Sainsbury ke...@fidelma.com wrote: I certainly cannot see an example of it in those links -- am I missing something? No, you're not missing something. I prefer the way HSQLDB 2.0 does triggers over your suggestion of adding java into the database. The built in procedural language in HSQLDB 2.0 can do what your example does but it's simpler. For more complex scenarios both H2, and HSQLDB can use classes in .jar files in the classpath for the trigger. Some of the advantages of doing it this way are: the JIT compiler applies to the trigger code (performance advantage), debuggable in an IDE, can use other libraries in the classpath instead of being limited to H2 and java classes, etc.. I don't think that adding a .jar file into the classpath is a big deal. Brish -- 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.comh2-database%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/h2-database?hl=en. -- 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.
Re: H2 embedded Java suggestion
So did you decide to keep working on your implementation? On Fri, Jun 25, 2010 at 12:19 PM, Kerry Sainsbury ke...@fidelma.com wrote: Hi, I see what you're saying. I guess all I'm offering is another way to package the Java code that H2 already supports. You can add it to the classpath, like you do now, or you can put it inside the database. The functionality is essentially identical. All it really gives you is another deployment option. Creating a whole new programming language is a little outside of the scope of my suggestion, but as Thomas likes to say patches are welcome :-) Cheers Kerry On Thu, Jun 24, 2010 at 6:20 PM, Brish bris...@gmail.com wrote: On Jun 23, 10:41 pm, Kerry Sainsbury ke...@fidelma.com wrote: I certainly cannot see an example of it in those links -- am I missing something? No, you're not missing something. I prefer the way HSQLDB 2.0 does triggers over your suggestion of adding java into the database. The built in procedural language in HSQLDB 2.0 can do what your example does but it's simpler. For more complex scenarios both H2, and HSQLDB can use classes in .jar files in the classpath for the trigger. Some of the advantages of doing it this way are: the JIT compiler applies to the trigger code (performance advantage), debuggable in an IDE, can use other libraries in the classpath instead of being limited to H2 and java classes, etc.. I don't think that adding a .jar file into the classpath is a big deal. Brish -- 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. -- 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. -- 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.
Re: H2 embedded Java suggestion
I'm just waiting for Thomas to chime in -- but he's super busy, and I'm sure he'll want to think about it before commenting. He's still got an earlier patch of mine to look at, and I don't want to turn into a burden on him, especially as my work is all fairly peripheral to the main engine development. Thomas is also trying to get a new release out this weekend, so I'm sure he's focussed on that. There's no panic :-) Cheers Kerry On Fri, Jun 25, 2010 at 12:30 PM, Erin Drummond erin@gmail.com wrote: So did you decide to keep working on your implementation? On Fri, Jun 25, 2010 at 12:19 PM, Kerry Sainsbury ke...@fidelma.com wrote: Hi, I see what you're saying. I guess all I'm offering is another way to package the Java code that H2 already supports. You can add it to the classpath, like you do now, or you can put it inside the database. The functionality is essentially identical. All it really gives you is another deployment option. Creating a whole new programming language is a little outside of the scope of my suggestion, but as Thomas likes to say patches are welcome :-) Cheers Kerry On Thu, Jun 24, 2010 at 6:20 PM, Brish bris...@gmail.com wrote: On Jun 23, 10:41 pm, Kerry Sainsbury ke...@fidelma.com wrote: I certainly cannot see an example of it in those links -- am I missing something? No, you're not missing something. I prefer the way HSQLDB 2.0 does triggers over your suggestion of adding java into the database. The built in procedural language in HSQLDB 2.0 can do what your example does but it's simpler. For more complex scenarios both H2, and HSQLDB can use classes in .jar files in the classpath for the trigger. Some of the advantages of doing it this way are: the JIT compiler applies to the trigger code (performance advantage), debuggable in an IDE, can use other libraries in the classpath instead of being limited to H2 and java classes, etc.. I don't think that adding a .jar file into the classpath is a big deal. Brish -- 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.comh2-database%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/h2-database?hl=en. -- 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.comh2-database%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/h2-database?hl=en. -- 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.comh2-database%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/h2-database?hl=en. -- 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.
Re: H2 embedded Java suggestion
I would LOVE this to be implemented - it would stop me having to put
the trigger classes on the classpath when using the H2 console (which
is a PITA)
On Thu, Jun 24, 2010 at 2:50 PM, Kerry Sainsbury ke...@fidelma.com wrote:
Hi Folks,
I've been looking at triggers recently and was surprised to see that we
can't define Java code to execute as part of a trigger.
Note that we *can* use Java code, but we can't embed it in the trigger
definition like we can with an ALIAS.
Would it be a good thing if we could store any Java code that could be used
within H2, within H2 itself?
The most flexible option seemed to be a new command. Something like this:
CREATE CODE MyTriggerExample AS
$$
public void fire(Connection conn, Object[] oldRow, Object[] newRow) throws
SQLException {
PreparedStatement prep = conn.prepareStatement(INSERT INTO
TEST_AUDIT(BLAH) VALUES (?));
prep.setInt(1, (Integer)newRow[0] );
prep.execute();
prep.close();
}
$$
followed by
CREATE TRIGGER TRIG_INS BEFORE INSERT ON TEST FOR EACH ROW CALL
MyTriggerExample;
Any code objects would also be able to be used in CREATE AGGREGATE, SET
DATABASE_EVENT_LISTENER, and
CREATE ALIAS commands.
Note that MyTriggerExample above does not require all org.h2.api.Trigger
interface methods to be implemented -- only
include the methods that are required by the end user.
The advantage of this is that triggers etc could be shipped as SQL, rather
than having to be put into a jar file and
included on the CLASSPATH of the H2 server.
I anticipate a single instance of each class being instantiated throughout
the life of the database, so implementation
classes would need to be threadsafe.
What do you think? (Especially Thomas :-)
I've actually got this mostly implemented, but before I spend any more time
on it I thought I'd better see if anybody
thought this added any value -- and if other databases did anything similar
in a nicer way.
Cheers
Kerry
--
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.
--
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.
Re: H2 embedded Java suggestion
Hi Brish, I don't see that HSQLDB supports having the Java within the database for use by triggers. The first link you sent says A trigger action can be written as a Java class that implements the org.hsqldb.Trigger interface and gives and example of a trigger that uses the class: create trigger trigbur before update of c1, c2, c3 on testtrig referencing new row as newrow for each row when (newrow.c2 is not null) call org.hsqldb.test.TriggerClass ... but I don't see how you can define org.hsqldb.test.TriggerClass apart from by putting a compiled Java class on the classpath. I certainly cannot see an example of it in those links -- am I missing something? Thanks Kerry On Thu, Jun 24, 2010 at 4:08 PM, Brish bris...@gmail.com wrote: On Jun 23, 8:50 pm, Kerry Sainsbury ke...@fidelma.com wrote: I've actually got this mostly implemented, but before I spend any more time on it I thought I'd better see if anybody thought this added any value -- and if other databases did anything similar in a nicer way. I prefer the way HSQLDB 2.0 does it: http://hsqldb.org/doc/2.0/guide/triggers-chapt.html http://hsqldb.org/doc/2.0/guide/sqlroutines-chapt.html Brish -- 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.comh2-database%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/h2-database?hl=en. -- 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.
