What I meant is that the reaction for the event is at the client.
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
DS> 27.02.2015 15:08, Carlos H. Cantu wrote:
>> Firebird events needs a listening client.
DS>No. It is not Oracle.
Title: Re: [Firebird-devel] Proposal of new feature: Event triggers
What I said before is: for that single example that I gave, I could achieve a similar result using currently events implementation, if it could be trusted 100%, but I would consider such solution as a workaround.
If a single
No, I don't see. What you want to do, and you agreed, could be done with
the existence ng event mechanism if yiu could figure out why sometimes it
appeared that events weren't being delivered. Instead, your proposing a
whole new class of trigger that would require yet another interface, a
mechani
27.02.2015 15:08, Carlos H. Cantu wrote:
> Firebird events needs a listening client.
No. It is not Oracle.
--
WBR, SD.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and
Title: Re: [Firebird-devel] Proposal of new feature: Event triggers
Jim, as I said before, I'm not proposing a substitute for the currently Firebird events. It is a new feature. Of course, if current events implementation is weak and/or bugged, it would be nice to have it improved or fixed
Carlos, again, why not figure out why events aren't working at your site.
It is a mechanism designed from the beginning to do what you want,
e.g. notify other connections of a database state change.
What you are suggesting will introduce far more problems than it purports
to solve.
If there is is
On 27/02/2015 10:10, Dimitry Sibiryakov wrote:
> 27.02.2015 14:03, Carlos H. Cantu wrote:
>> I have no idea about how context variables was implemented
>> internally, but do you think there is a chance to make them respect
>> the isolation of its transaction when retrieving the values?
>It is n
27.02.2015 14:03, Carlos H. Cantu wrote:
> I have no idea about how context variables was implemented
> internally, but do you think there is a chance to make them respect
> the isolation of its transaction when retrieving the values?
It is not that hard to do, but being out of transaction cont
AP> And this may play bad jokes from stability POV - imagine having old
AP> values in the beginning of some complex request but new one in the end.
Exactly. I have no idea about how context variables was implemented
internally, but do you think there is a chance to make them respect
the isolation
On 02/26/15 21:04, Dmitry Yemanov wrote:
>> But your point raised a doubt here: what is the "isolation" of a
>> USER_SESSION context variable regarding active snapshot transactions?
> Context variables are outside the transaction control, so the new values
> are available immediately.
>
And this
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
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
> 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
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
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
-
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
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
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
---
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
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
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: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
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
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: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
> 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
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!
Alread
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
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
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
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
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: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
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.
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
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
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.
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
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
39 matches
Mail list logo
