I would like to start a discussion to propose the implementation of
"Event triggers" (for the lack of a better name for now).
Those special triggers would be associated to an EVENT, not to a
TABLE. When the associated event is fired in any of the active
attachments, all the active attachments "int
On 26/02/2015 10:29, Carlos H. Cantu wrote:
> I would like to start a discussion to propose the implementation of
> "Event triggers" (for the lack of a better name for now).
>
> Those special triggers would be associated to an EVENT, not to a
> TABLE. When the associated event is fired in any of th
On 26/02/2015 10:29, Carlos H. Cantu wrote:
>
> Those special triggers would be associated to an EVENT, not to a
> TABLE. When the associated event is fired in any of the active
> attachments, all the active attachments "interested" in that event
> would run the trigger.
>
>
But this intrigues me.
26.02.2015 16:55, Adriano dos Santos Fernandes wrote:
> For example, there is example UDR who waits for an event, blocking the
> calling.
I don't think Carlos wants to block the caller. Also, if the caller
dies, notifications will be lost until someone notices that and
reconnects and restarts t
I'll give you a real example that could justify this need:
In my ERP, I store some global configuration data in a config table.
In several triggers, I need to keep reading this config table to get
some values and use in IF's, etc. For batch operations, triggers will
be executed several times. A mu
DY> 26.02.2015 16:55, Adriano dos Santos Fernandes wrote:
>> For example, there is example UDR who waits for an event, blocking the
>> calling.
DY> I don't think Carlos wants to block the caller.
Yep, no blocking at all.
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.
On 26/02/2015 11:11, Dmitry Yemanov wrote:
> 26.02.2015 16:55, Adriano dos Santos Fernandes wrote:
>
>> For example, there is example UDR who waits for an event, blocking the
>> calling.
> I don't think Carlos wants to block the caller.
That is just the example currently done. It should be adapted
26.02.2015 15:18, Carlos H. Cantu wrote:
> PS: I could do something similar at the client side, using the
> currently Firebird events, but unfortunately, they cannot be trusted.
What do you mean?
--
WBR, SD.
--
Di
On 26/02/2015 11:18, Carlos H. Cantu wrote:
> I'll give you a real example that could justify this need:
>
> In my ERP, I store some global configuration data in a config table.
> In several triggers, I need to keep reading this config table to get
> some values and use in IF's, etc. For batch oper
DS> 26.02.2015 15:18, Carlos H. Cantu wrote:
>> PS: I could do something similar at the client side, using the
>> currently Firebird events, but unfortunately, they cannot be trusted.
DS>What do you mean?
In my practical experience with the currently implementation of FB
events (I use them fo
Adriano,
I never measured, but I assume it should be fast, specially if the
page is in the cache. But reading the same thing endless times in a
batch operation looks like a waste of resources. I'm sure reading a
context variable is much simpler/fast than the whole mechanism
involved in running a s
Could you describe what you are actually trying to do rather than how a
possible solution might work? It's a lot easier to work from an actual
problem than to reverse engineer from a murky proposal.
On Thursday, February 26, 2015, Carlos H. Cantu
wrote:
> I would like to start a discussion to
Title: Re: [Firebird-devel] Proposal of new feature: Event triggers
Could you describe what you are actually trying to do rather than how a possible solution might work? It's a lot easier to work from an actual problem than to reverse engineer from a murky proposal.
Hi Jim!
Already did i
> From: Carlos H. Cantu
> In my ERP, I store some global configuration data in a config table.
> In several triggers, I need to keep reading this config table to get
> some values and use in IF's, etc. For batch operations, triggers will
> be executed several times. A much better/efficient approac
26.02.2015 15:49, Carlos H. Cantu wrote:
> In my practical experience with the currently implementation of FB
> events (I use them for internal messenger in my ERP), it happened
> several times that some attachments didn't get notified when the event
> was fired. It is like, in the same local netwo
DS>I can tell you why: a bug in event handling code in your application. It
took me quite
DS> a few time to realize how event notification works and write event handling
code properly,
DS> but since then I received only one or two reports about problems with them.
Nevertheless,
DS> if your a
26.02.2015 15:57, Carlos H. Cantu wrote:
> I never measured, but I assume it should be fast, specially if the
> page is in the cache. But reading the same thing endless times in a
> batch operation looks like a waste of resources. I'm sure reading a
> context variable is much simpler/fast than the
26.02.2015 18:03, Dimitry Sibiryakov wrote:
> IIRC, tests by Pavel Zotov shown that using of context variables is,
> actually, slower
> that reading from a single row table.
Wrong, at least for FB3.
Dmitry
--
Dive in
The goal is to send notification from one connection to other
connection(s) without roundrip to client using current event
mechanism.
On 2015.02.26. 15:56, James Starkey
wrote:
Could you describe what you are actually trying to do
rather than how a p
26.02.2015 18:10, Carlos H. Cantu wrote:
> DS> IIRC, tests by Pavel Zotov shown that using of context variables is,
> actually, slower
> DS> that reading from a single row table.
>
> If so, I would say something seems to be really wrong.
Simple test shows that context variables are 2x faster on
If there's a bug, the correct response to to fix it, not invent yet another
feature to work around the bug.
A correctly code application should get events. The mechanism is designed
to eliminate race conditions. But if you don't understand how it's
supposed to work, it's straightforward to write
DS>IIRC, tests by Pavel Zotov shown that using of context variables is,
actually, slower
DS> that reading from a single row table.
If so, I would say something seems to be really wrong.
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
---
26.02.2015 17:18, Carlos H. Cantu wrote:
> When any user changes some sensitive config data, I would like that
> all the attachments to "refresh" its session context variables, to
> reflect the new values.
How fast do you need them to refresh? Immediately is a wrong asnwer, as
events are asynchr
Title: Re: [Firebird-devel] Proposal of new feature: Event triggers
If there's a bug, the correct response to to fix it, not invent yet another feature to work around the bug.
I never intended the new proposed feature to substitute the currently events mechanism. It would work in a differe
DY> Simple test shows that context variables are 2x faster on v2.5 and 4x
DY> faster in v3.0.
Good to know! Thanks for sharing this information.
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
-
On 26/02/2015 12:23, Ivan Přenosil wrote:
>> From: Adriano dos Santos Fernandes
>> Is it really fast?
>>
>> If your config table has a single row with each "variable" as a column,
>> it should be frequently cached.
> Yes, it is really fast. I use context variables not because somebody
> tell me to
> From: Adriano dos Santos Fernandes
> Is it really fast?
>
> If your config table has a single row with each "variable" as a column,
> it should be frequently cached.
Yes, it is really fast. I use context variables not because somebody
tell me to do so, but because I actually compared the solut
DY> How fast do you need them to refresh? Immediately is a wrong asnwer, as
DY> events are asynchronous. Is it OK to see outdated context variables for
DY> some [supposedly short but generally unpredictable] time?
Since everything would be done inside the server, I suppose the delay
would be reall
26.02.2015 20:43, Carlos H. Cantu wrote:
> Since everything would be done inside the server, I suppose the delay
> would be really short, so acceptable.
I just wanted you to confirm that some delay is acceptable, i.e. it's
not "business critical" to shortly see old values after they were updated
29 matches
Mail list logo
