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
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
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
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.
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
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
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
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
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
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
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
-
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
