Feel free to log it in the issue tracker here:
https://code.google.com/p/h2database/issues/list
On 2013-10-03 04:42, Gili wrote:
Ping.
Can we at least open an issue to track this? I don't want this to fall
through the cracks.
Gili
--
You received this message because you are subscribed to
Done: https://code.google.com/p/h2database/issues/detail?id=511
Gili
On Thursday, October 3, 2013 2:43:17 AM UTC-4, Noel Grandin wrote:
Feel free to log it in the issue tracker here:
https://code.google.com/p/h2database/issues/list
On 2013-10-03 04:42, Gili wrote:
Ping.
Can we at
Ping.
Can we at least open an issue to track this? I don't want this to fall
through the cracks.
Gili
On Tuesday, July 30, 2013 8:11:33 PM UTC-4, Gili wrote:
Hi Thomas,
Good thing you asked for the updated test, because I now see a huge
performance difference:
Multiple
Hi,
In your test case, you didn't actually *execute* the statement. So it was
prepare a statement versus do nothing
I think a more realistic use case is: (a) prepare, bind the values, and
execute a simple statement, versus (b) just bind the values and execute it.
Regards,
Thomas
On Mon,
Hi,
In your test case, you didn't actually *execute* the statement. So it was
prepare a statement versus do nothing. Well, if the difference in time
is so small, then I guess it doesn't make much sense to support this
feature.
So, instead of continuing to discuss this back and forth, let's just
On 29/07/2013 4:53 PM, Thomas Mueller wrote:
Hi,
In your test case, you didn't actually *execute* the statement. So it
was prepare a statement versus do nothing. Well, if the difference
in time is so small, then I guess it doesn't make much sense to
support this feature.
That was by
Hi,
That would allow the Trigger instances to create and cache
PreparedStatements in their init() method.
Yes, if you look at the FullTextTrigger class (package org.h2.fulltext),
you can already cache the prepared statements, using this system session.
Regards,
Thomas
On Thu, Jul 18, 2013
On Sat, Jul 20, 2013 at 3:11 PM, Thomas Mueller
thomas.tom.muel...@gmail.com wrote:
That would allow the Trigger instances to create and cache
PreparedStatements in their init() method.
Yes, if you look at the FullTextTrigger class (package org.h2.fulltext), you
can already cache the
Hi,
but that can lead to deadlocks ...
e.g. see this previous discussion:
As part of that discussion, I wrote: I suggest to use PreparedStatement,
and always create a new PreparedStatement (for each invokation of the
trigger). Internally, the database caches a low-level part of a
On 2013-07-17 19:51, cowwoc wrote:
I am referring to the fact that currently if I want to process N
rows, you need to create N * PreparedStatements (one per row inside
fire()) as opposed to once at the beginning of the transaction. You
are right that this needs to be benchmarked.
One
On 18/07/2013 3:13 AM, Noel Grandin wrote:
On 2013-07-17 19:51, cowwoc wrote:
I am referring to the fact that currently if I want to process N
rows, you need to create N * PreparedStatements (one per row inside
fire()) as opposed to once at the beginning of the transaction. You
are right
Hi,
Hm, it's interesting, but I'm not quite sure if the change is worth it.
What are the pain points?
ability to clean up resources when a trigger is dropped (not just when
the database is closed)
There are already method Trigger.remove() and Trigger.close(). Your
interface only has close().
Hi Thomas,
On 17/07/2013 12:35 PM, Thomas Mueller wrote:
Hi,
Hm, it's interesting, but I'm not quite sure if the change is worth
it. What are the pain points?
ability to clean up resources when a trigger is dropped (not just
when the database is closed)
There are already method
Hi,
I'd like to propose a new Trigger interface (attached) with the following
benefits:
-
- Simplified init() method: Users can pull as little or as much data as
they'd like from class Metadata.
- Performance benefit for triggers that process multiple rows:
PreparedStatements
14 matches
Mail list logo
