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.*;
>
> 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
<mailto: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-database@googlegroups.com
<mailto:h2-database@googlegroups.com>.
>> To unsubscribe from this group, send email to
>> h2-database+unsubscr...@googlegroups.com
<mailto:h2-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-database@googlegroups.com
<mailto:h2-database@googlegroups.com>.
> To unsubscribe from this group, send email to
> h2-database+unsubscr...@googlegroups.com
<mailto:h2-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-database@googlegroups.com
<mailto:h2-database@googlegroups.com>.
To unsubscribe from this group, send email to
h2-database+unsubscr...@googlegroups.com
<mailto:h2-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.
--
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.
