Menu
▾
▴
firebird-devel
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-04 14:22:06
|
Currently user can't create good exception texts and rely on them,
because exceptions generally need more informations. So user need to
throw exceptions passing its complete text [exception e1 'Exception ' ||
info1 || ' at ' || info2]. This lose the ability to create exception
texts and to catch the parameters without parse the formated text.
The exceptions are currently encoded in this way:
isc_except, <number>,
isc_random, <string>
I propose to make parameters directly inside user text exceptions, like
this:
create exception e1 'Exception @1 at @2';
This is easy for user, easy for the engine. Does not need metadata
extensions and is backward compatible.
If that exception is thrown in the legacy way [exception e1] the user
see its original text.
If that exception is thrown in the new way [exception e1 ('foo', 'bar')]
the exception will be see formated. To format it, it will be encoded in
this way:
isc_except, <number>,
isc_random, <string>, <string: foo>, <string: bar>
The formating routine will treat isc_random in especial way, and will
format its string using the others parameters till the status vector end
or the next isc code. As isc_random is currently always generated with
one parameter, no compatibility problem will arise.
Comments?
Adriano
|
|
From: Vlad K. <hv...@us...> - 2010-01-04 15:04:31
|
> Currently user can't create good exception texts and rely on them,
> because exceptions generally need more informations. So user need to
> throw exceptions passing its complete text [exception e1 'Exception ' ||
> info1 || ' at ' || info2]. This lose the ability to create exception
> texts and to catch the parameters without parse the formated text.
>
> The exceptions are currently encoded in this way:
> isc_except, <number>,
> isc_random, <string>
>
> I propose to make parameters directly inside user text exceptions, like
> this:
> create exception e1 'Exception @1 at @2';
>
> This is easy for user, easy for the engine. Does not need metadata
> extensions and is backward compatible.
Why not implement built-in FORMAT function instead ?
Regards,
Vlad
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-04 15:37:49
|
Vlad Khorsun wrote: >> Currently user can't create good exception texts and rely on them, >> because exceptions generally need more informations. So user need to >> throw exceptions passing its complete text [exception e1 'Exception ' || >> info1 || ' at ' || info2]. This lose the ability to create exception >> texts and to catch the parameters without parse the formated text. >> >> The exceptions are currently encoded in this way: >> isc_except, <number>, >> isc_random, <string> >> >> I propose to make parameters directly inside user text exceptions, like >> this: >> create exception e1 'Exception @1 at @2'; >> >> This is easy for user, easy for the engine. Does not need metadata >> extensions and is backward compatible. > > Why not implement built-in FORMAT function instead ? > This does not allow the client (or even in PSQL) to catch the exception parameters, and to define messages right in the exception. FORMAT is useful, and should format the same way exceptions are formated, but does not substitute it. Adriano |
|
From: Vlad K. <hv...@us...> - 2010-01-04 20:06:44
|
>>> Currently user can't create good exception texts and rely on them,
>>> because exceptions generally need more informations. So user need to
>>> throw exceptions passing its complete text [exception e1 'Exception ' ||
>>> info1 || ' at ' || info2]. This lose the ability to create exception
>>> texts and to catch the parameters without parse the formated text.
>>>
>>> The exceptions are currently encoded in this way:
>>> isc_except, <number>,
>>> isc_random, <string>
>>>
>>> I propose to make parameters directly inside user text exceptions, like
>>> this:
>>> create exception e1 'Exception @1 at @2';
>>>
>>> This is easy for user, easy for the engine. Does not need metadata
>>> extensions and is backward compatible.
>>
>> Why not implement built-in FORMAT function instead ?
>>
> This does not allow the client (or even in PSQL) to catch the exception
> parameters,
Here i can understand and even agree :) I have a big doubt users will
parse status-vector looking for parameters, however. They will sooner parse
combined text message as they do now ;) But i agree, it have its own pluses.
> and to define messages right in the exception.
This is i don't understand.
> FORMAT is useful, and should format the same way exceptions are formated,
Agreed.
Regards,
Vlad
PS I think we should not use isc_random with such messages and tweak the engine.
PPS How do you going to handle case when passed arguments not corresponds to the
placeholders in text message ?
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-04 20:14:43
|
Vlad Khorsun wrote: >>>> Currently user can't create good exception texts and rely on them, >>>> because exceptions generally need more informations. So user need to >>>> throw exceptions passing its complete text [exception e1 'Exception ' || >>>> info1 || ' at ' || info2]. This lose the ability to create exception >>>> texts and to catch the parameters without parse the formated text. >>>> >>>> The exceptions are currently encoded in this way: >>>> isc_except, <number>, >>>> isc_random, <string> >>>> >>>> I propose to make parameters directly inside user text exceptions, like >>>> this: >>>> create exception e1 'Exception @1 at @2'; >>>> >>>> This is easy for user, easy for the engine. Does not need metadata >>>> extensions and is backward compatible. >>> Why not implement built-in FORMAT function instead ? >>> >> This does not allow the client (or even in PSQL) to catch the exception >> parameters, > > Here i can understand and even agree :) I have a big doubt users will > parse status-vector looking for parameters, however. They will sooner parse > combined text message as they do now ;) But i agree, it have its own pluses. > >> and to define messages right in the exception. > > This is i don't understand. > If user need to use FORMAT, it will need to pass again the exception template text. The text in the exception (metadata) looses it meaning. >> FORMAT is useful, and should format the same way exceptions are formated, > I had a prototype for FORMAT, so I'll probably do it too. > > PS I think we should not use isc_random with such messages and tweak the engine. > Why not? I think general usage of isc_random is ok. It may be used everywhere exceptions are generated but doesn't need (or can't - think on plugins) insert messages in firebird.msg. > PPS How do you going to handle case when passed arguments not corresponds to the > placeholders in text message ? > The @N will be maintained in the text. It would be unwise to replace an user exception by another one. Adriano |
|
From: Vlad K. <hv...@us...> - 2010-01-04 20:46:59
|
>>> and to define messages right in the exception.
>>
>> This is i don't understand.
>>
> If user need to use FORMAT, it will need to pass again the exception
> template text. The text in the exception (metadata) looses it meaning.
Ok, now i understand.
We can pass exception name into FORMAT_EXCEPTION as first argument
(where format string is passed into usual FORMAT).
Another approach is to extend syntax of EXCEPTION statement :
EXCEPTION <exception_name> [(arg_list) [WITH FORMAT]]
When WITH FORMAT clause is omitted then args go into the status-vector as
you offers, else engine will FORMAT the exception message using args and pass
plain string to the client.
>>> FORMAT is useful, and should format the same way exceptions are formated,
>>
> I had a prototype for FORMAT, so I'll probably do it too.
Very good !
>> PS I think we should not use isc_random with such messages and tweak the engine.
>>
> Why not? I think general usage of isc_random is ok. It may be used
> everywhere exceptions are generated but doesn't need (or can't - think
> on plugins) insert messages in firebird.msg.
isc_random is used where we have no dedicated error code. Ideally we should not
use it at all.
BTW, dedicated error code, say, fb_formatted_string, could also have as first
mandatory parameter count of passed arguments to simplify handling of the rest of
status-vector.
I.e. it will look as :
<fb_formatted_string>
<number> - number of user supplied arguments
<string> - format string
<isc_arg_XXX>, <arg1>,
...
<isc_arg_XXX>, <argN>,
Just an idea.
>> PPS How do you going to handle case when passed arguments not corresponds to the
>> placeholders in text message ?
>>
> The @N will be maintained in the text. It would be unwise to replace an
> user exception by another one.
This is what i wanted to hear :) What if user passed more arguments that defined in
message text ? I hope extra args will be silently ignored ?
Regards,
Vlad
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-05 13:24:04
|
Vlad Khorsun wrote: >> Why not? I think general usage of isc_random is ok. It may be used >> everywhere exceptions are generated but doesn't need (or can't - think >> on plugins) insert messages in firebird.msg. > > isc_random is used where we have no dedicated error code. Ideally we should not > use it at all. > > BTW, dedicated error code, say, fb_formatted_string, could also have as first > mandatory parameter count of passed arguments to simplify handling of the rest of > status-vector. > I have no problem with new error code. > I.e. it will look as : > > <fb_formatted_string> > <number> - number of user supplied arguments > <string> - format string > <isc_arg_XXX>, <arg1>, > ... > <isc_arg_XXX>, <argN>, > > Just an idea. > But it be simple as isc_random. No need to pass more info that should be validated anyway and that will need some handling if does not match the count of passed args. > >>> PPS How do you going to handle case when passed arguments not corresponds to the >>> placeholders in text message ? >>> >> The @N will be maintained in the text. It would be unwise to replace an >> user exception by another one. > > This is what i wanted to hear :) What if user passed more arguments that defined in > message text ? I hope extra args will be silently ignored ? > Yes. Adriano |
|
From: Dmitry Y. <fir...@ya...> - 2010-01-04 21:16:35
|
Vlad Khorsun wrote: >> and to define messages right in the exception. > > This is i don't understand. I believe the point was to have the common part of the text (aka format) to be stored once inside the exception declaration instead of having it duplicated every time you raise that exception and use FORMAT (or manually load from some user table at runtime). Dmitry |
|
From: Vlad K. <hv...@us...> - 2010-01-07 10:54:04
|
>>>> Currently user can't create good exception texts and rely on them,
>>>> because exceptions generally need more informations. So user need to
>>>> throw exceptions passing its complete text [exception e1 'Exception ' ||
>>>> info1 || ' at ' || info2]. This lose the ability to create exception
>>>> texts and to catch the parameters without parse the formated text.
>>>>
>>>> The exceptions are currently encoded in this way:
>>>> isc_except, <number>,
>>>> isc_random, <string>
>>>>
>>>> I propose to make parameters directly inside user text exceptions, like
>>>> this:
>>>> create exception e1 'Exception @1 at @2';
>>>>
>>>> This is easy for user, easy for the engine. Does not need metadata
>>>> extensions and is backward compatible.
>>>
>>> Why not implement built-in FORMAT function instead ?
>>>
>> This does not allow the client (or even in PSQL) to catch the exception
>> parameters,
>
> Here i can understand and even agree :) I have a big doubt users will
> parse status-vector looking for parameters, however. They will sooner parse
> combined text message as they do now ;)
As you already wrote in README.exception_handling :
"client library older than 3.0 will not be able to correctly format exceptions
raised in this new way".
Therefore i ask again to at least think on [optional] ability of server-side
formatting of such messages.
Regards,
Vlad
PS You named new error code as "isc_formatted_exception". Do you see the
ability to use it not only for user exceptions ? I prefer to see more generic name.
Note, this error code is used for formatted string, not for exception itself.
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-07 13:22:19
|
Vlad Khorsun wrote:
>>>>> Currently user can't create good exception texts and rely on them,
>>>>> because exceptions generally need more informations. So user need to
>>>>> throw exceptions passing its complete text [exception e1 'Exception ' ||
>>>>> info1 || ' at ' || info2]. This lose the ability to create exception
>>>>> texts and to catch the parameters without parse the formated text.
>>>>>
>>>>> The exceptions are currently encoded in this way:
>>>>> isc_except, <number>,
>>>>> isc_random, <string>
>>>>>
>>>>> I propose to make parameters directly inside user text exceptions, like
>>>>> this:
>>>>> create exception e1 'Exception @1 at @2';
>>>>>
>>>>> This is easy for user, easy for the engine. Does not need metadata
>>>>> extensions and is backward compatible.
>>>> Why not implement built-in FORMAT function instead ?
>>>>
>>> This does not allow the client (or even in PSQL) to catch the exception
>>> parameters,
>> Here i can understand and even agree :) I have a big doubt users will
>> parse status-vector looking for parameters, however. They will sooner parse
>> combined text message as they do now ;)
>
> As you already wrote in README.exception_handling :
>
> "client library older than 3.0 will not be able to correctly format exceptions
> raised in this new way".
>
> Therefore i ask again to at least think on [optional] ability of server-side
> formatting of such messages.
>
It's currently encoded as:
isc_except, <exception number>,
isc_formatted_exception, <exception message>, <exception parameters>
Where <exception message> is original exception message, hence it will
be what older clients will show.
Do you mean something as:
isc_except, <exception number>,
isc_formatted_exception, <formatted exception message>, <exception
message>, <exception parameters>
Then in this case the client will not need any change because text of
this exception is "@1", and the user still can catch all relevant info.
Seems to work well.
> PS You named new error code as "isc_formatted_exception". Do you see the
> ability to use it not only for user exceptions ?
I see no mention of "user" in the constant. :-)
> I prefer to see more generic name.
> Note, this error code is used for formatted string, not for exception itself.
>
It's still an exception, it's in the status vector. isc_formatted_string
looks confusing to me, meaning something like error types (and not
codes). But I see no problem to describe it as the feature name
(isc_parameterized_exception).
Adriano
|
|
From: Vlad K. <hv...@us...> - 2010-01-07 14:20:31
|
>> As you already wrote in README.exception_handling :
>>
>> "client library older than 3.0 will not be able to correctly format exceptions
>> raised in this new way".
>>
>> Therefore i ask again to at least think on [optional] ability of server-side
>> formatting of such messages.
>>
> It's currently encoded as:
> isc_except, <exception number>,
> isc_formatted_exception, <exception message>, <exception parameters>
>
> Where <exception message> is original exception message, hence it will
> be what older clients will show.
Hmm, i not tried it but will older client understand isc_formatted_exception
and parse status-vector after it ?
> Do you mean something as:
> isc_except, <exception number>,
> isc_formatted_exception, <formatted exception message>, <exception
> message>, <exception parameters>
>
> Then in this case the client will not need any change because text of
> this exception is "@1", and the user still can catch all relevant info.
> Seems to work well.
I mean that if exception message is formatted by the engine it will be
passed to the client using isc_random, i.e. as before. Probably the best
approach is to format message at the engine if client is old and let it
be formatted by client if client is new.
>> PS You named new error code as "isc_formatted_exception". Do you see the
>> ability to use it not only for user exceptions ?
>
> I see no mention of "user" in the constant. :-)
>
>> I prefer to see more generic name.
>> Note, this error code is used for formatted string, not for exception itself.
>>
> It's still an exception, it's in the status vector. isc_formatted_string
> looks confusing to me, meaning something like error types (and not
> codes). But I see no problem to describe it as the feature name
> (isc_parameterized_exception).
I'd said isc_except is exception, all other is its parameters :) I'm not going
to insist but i'd like to not use "exception" word for this new error code.
Regards,
Vlad
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-08 14:19:09
|
Vlad Khorsun wrote: >>> As you already wrote in README.exception_handling : >>> >>> "client library older than 3.0 will not be able to correctly format exceptions >>> raised in this new way". >>> >>> Therefore i ask again to at least think on [optional] ability of server-side >>> formatting of such messages. >>> >> It's currently encoded as: >> isc_except, <exception number>, >> isc_formatted_exception, <exception message>, <exception parameters> >> >> Where <exception message> is original exception message, hence it will >> be what older clients will show. > > Hmm, i not tried it but will older client understand isc_formatted_exception > and parse status-vector after it ? > >> Do you mean something as: >> isc_except, <exception number>, >> isc_formatted_exception, <formatted exception message>, <exception >> message>, <exception parameters> >> >> Then in this case the client will not need any change because text of >> this exception is "@1", and the user still can catch all relevant info. >> Seems to work well. > I did this changed, it looks well, but since new code is introduced the older clients needs at least v3 firebird.msg. If we don't want this, the message shall be encoded with isc_random. Currently, no special handling for isc_formatted_exception has necessary. We can also add isc_formatted_exception to firebird.msg of 2.0, 2.1 and 2.5 now, so next versions will be able to understand these exceptions. This look the better way to go for me. Adriano |
|
From: Vlad K. <hv...@us...> - 2010-01-08 19:36:24
|
> I did this changed,
In README.exception_handling you wrote :
=============
The status vector is generated using that codes combination:
isc_except, <exception number>,
isc_formatted_exception, <formatted exception message>,
<defined exception message>, <exception parameters>
Since new error code (isc_formatted_exception) is used, it's necessary that the client is v3.0
or at least uses firebird.msg from v3.0 so that it can translate the status vector to string.
=============
Why include both <formatted exception message> and <defined exception message> ?
Why not use isc_random for <formatted exception message> ?
> it looks well, but since new code is introduced the
> older clients needs at least v3 firebird.msg.
Do you think that someone will update firebird.msg but not fbclient.dll ?
What benefit for users of old client your last commit gives ?
> If we don't want this, the
> message shall be encoded with isc_random. Currently, no special handling
> for isc_formatted_exception has necessary.
>
> We can also add isc_formatted_exception to firebird.msg of 2.0, 2.1 and
> 2.5 now, so next versions will be able to understand these exceptions.
> This look the better way to go for me.
Sometime you make me think that you read only what you want to read, not
what others wrote :( Does you read my idea about syntax support ? Does you read
another idea about to fill status-vector depending of client version ?
Regards,
Vlad
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-08 19:51:46
|
Vlad Khorsun wrote: >> I did this changed, > > In README.exception_handling you wrote : > > ============= > The status vector is generated using that codes combination: > isc_except, <exception number>, > isc_formatted_exception, <formatted exception message>, > <defined exception message>, <exception parameters> > > Since new error code (isc_formatted_exception) is used, it's necessary that the client is v3.0 > or at least uses firebird.msg from v3.0 so that it can translate the status vector to string. > > ============= > > Why include both <formatted exception message> and <defined exception message> ? > Why not use isc_random for <formatted exception message> ? > You first insisted on use something different than isc_random. Now you insist the contrary? Just nitpicking or what? Both are included because the original message template may be interesting to the client code as well the parameters. >> it looks well, but since new code is introduced the >> older clients needs at least v3 firebird.msg. > > Do you think that someone will update firebird.msg but not fbclient.dll ? > What benefit for users of old client your last commit gives ? > Features that depend on updated client requires client updation or may not function totally correctly. *Any* new error message requires update of firebird.msg in the client, if you not know. Now the thing just works (of course, depending on message in firebird.msg). Any version since 2.0 may display the error message. No new semantics is inserted in the status vector, just ordinary parameters so any tool have no problem to understand it. >> If we don't want this, the >> message shall be encoded with isc_random. Currently, no special handling >> for isc_formatted_exception has necessary. >> >> We can also add isc_formatted_exception to firebird.msg of 2.0, 2.1 and >> 2.5 now, so next versions will be able to understand these exceptions. >> This look the better way to go for me. > > Sometime you make me think that you read only what you want to read, not > what others wrote :( Does you read my idea about syntax support ? Does you read > another idea about to fill status-vector depending of client version ? > I will not store isc_random in the status vector if client is < 3.0 and isc_formatted_exception when >= 3.0. It's not how things should work. If it's decided that should be isc_random, I change it to isc_random. If it's decided to insert the error code in others versions I will do. If nothing is decided I'll do nothing. Period. Adriano |
|
From: Vlad K. <hv...@us...> - 2010-01-08 20:27:40
|
> Vlad Khorsun wrote:
>>> I did this changed,
>>
>> In README.exception_handling you wrote :
>>
>> =============
>> The status vector is generated using that codes combination:
>> isc_except, <exception number>,
>> isc_formatted_exception, <formatted exception message>,
>> <defined exception message>, <exception parameters>
>>
>> Since new error code (isc_formatted_exception) is used, it's necessary that the client is v3.0
>> or at least uses firebird.msg from v3.0 so that it can translate the status vector to string.
>>
>> =============
>>
>> Why include both <formatted exception message> and <defined exception message> ?
>> Why not use isc_random for <formatted exception message> ?
>>
> You first insisted on use something different than isc_random. Now you
> insist the contrary? Just nitpicking or what?
First, where do you see i *insist* on something ? Second, i think old thing should
be done as before, so - isc_random for old style error mesage, new error code for
new style error message.
> Both are included because the original message template may be
> interesting to the client code as well the parameters.
It seems overkill for me to include both messages into same status-vector.
Old client can't understand new (defined) message and new client not needed old
(formatted) message.
>>> it looks well, but since new code is introduced the
>>> older clients needs at least v3 firebird.msg.
>>
>> Do you think that someone will update firebird.msg but not fbclient.dll ?
>> What benefit for users of old client your last commit gives ?
>>
> Features that depend on updated client requires client updation or may
> not function totally correctly.
What about old feature - exception without parameters ? Seems it works as
before, with isc_random ?
> *Any* new error message requires update
> of firebird.msg in the client, if you not know.
Therefore i offers way to preserve backward compatibility, if you know what is it.
Could you answer on my simple question : what benefit for users of old client
your last commit gives ? Why it is better than your previous commit ? Is it make
old clients more happy ? Maybe new client have some additional benefits ?
> Now the thing just works (of course, depending on message in
> firebird.msg). Any version since 2.0 may display the error message. No
> new semantics is inserted in the status vector, just ordinary parameters
> so any tool have no problem to understand it.
Dependancy on firebird.msg makes all this efforts NULL. So i see no sence to do
it in the way you did.
>>> If we don't want this, the
>>> message shall be encoded with isc_random. Currently, no special handling
>>> for isc_formatted_exception has necessary.
>>>
>>> We can also add isc_formatted_exception to firebird.msg of 2.0, 2.1 and
>>> 2.5 now, so next versions will be able to understand these exceptions.
>>> This look the better way to go for me.
We never did it before. And i don't think it is good to leave gap in error messages
numbers. Also it will add nothing to the currently installed clients.
>> Sometime you make me think that you read only what you want to read, not
>> what others wrote :( Does you read my idea about syntax support ? Does you read
>> another idea about to fill status-vector depending of client version ?
>>
> I will not store isc_random in the status vector if client is < 3.0 and
> isc_formatted_exception when >= 3.0.
Why ? Probably you have really good argument to not do it ? I want to know it too.
I do not insist on it, just want to know what you know.
> It's not how things should work.
Surely, you and only you know how things should work :)
Regards,
Vlad
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-08 22:03:19
|
Vlad Khorsun wrote: >> Vlad Khorsun wrote: >>>> I did this changed, >>> In README.exception_handling you wrote : >>> >>> ============= >>> The status vector is generated using that codes combination: >>> isc_except, <exception number>, >>> isc_formatted_exception, <formatted exception message>, >>> <defined exception message>, <exception parameters> >>> >>> Since new error code (isc_formatted_exception) is used, it's necessary that the client is v3.0 >>> or at least uses firebird.msg from v3.0 so that it can translate the status vector to string. >>> >>> ============= >>> >>> Why include both <formatted exception message> and <defined exception message> ? >>> Why not use isc_random for <formatted exception message> ? >>> >> You first insisted on use something different than isc_random. Now you >> insist the contrary? Just nitpicking or what? > > First, where do you see i *insist* on something ? Making me waste my time because I don't did a think the exact way you want (and just that) is something I call insist. > Second, i think old thing should > be done as before, so - isc_random for old style error mesage, new error code for > new style error message. > And where on the earth you see the former exception style has changed? It has not on the initial spec, it has not on some discussion, it has not on the readme (that's the content in a subject called "Parameterized exceptions (FB 3.0)" that you didn't quoted. >> Both are included because the original message template may be >> interesting to the client code as well the parameters. > > It seems overkill for me to include both messages into same status-vector. Yes? But for me it "not seems", and I want to include it there. Applications can call a function called "gds__msg_lookup" and get the exception template message for error codes. I want same functionality for parameterized exceptions, i.e., application can get the message template string as well the parameters. > Old client can't understand new (defined) message and new client not needed old > (formatted) message. > In your opinion. >>>> it looks well, but since new code is introduced the >>>> older clients needs at least v3 firebird.msg. >>> Do you think that someone will update firebird.msg but not fbclient.dll ? >>> What benefit for users of old client your last commit gives ? >>> >> Features that depend on updated client requires client updation or may >> not function totally correctly. > > What about old feature - exception without parameters ? Seems it works as > before, with isc_random ? > You said above as it don't, so please point me why it don't. >> *Any* new error message requires update >> of firebird.msg in the client, if you not know. > > Therefore i offers way to preserve backward compatibility, if you know what is it. > Yes, looks like you didn't understand the code and/or the spec. > Could you answer on my simple question : what benefit for users of old client > your last commit gives ? Why it is better than your previous commit ? Is it make > old clients more happy ? Maybe new client have some additional benefits ? > This is already answered, but I hope you understood now reading that message and the initial spec again. >> Now the thing just works (of course, depending on message in >> firebird.msg). Any version since 2.0 may display the error message. No >> new semantics is inserted in the status vector, just ordinary parameters >> so any tool have no problem to understand it. > > Dependancy on firebird.msg makes all this efforts NULL. So i see no sence to do > it in the way you did. > Thanks, you so kindly. :-) >>>> If we don't want this, the >>>> message shall be encoded with isc_random. Currently, no special handling >>>> for isc_formatted_exception has necessary. >>>> >>>> We can also add isc_formatted_exception to firebird.msg of 2.0, 2.1 and >>>> 2.5 now, so next versions will be able to understand these exceptions. >>>> This look the better way to go for me. > > We never did it before. And i don't think it is good to leave gap in error messages > numbers. Also it will add nothing to the currently installed clients. > Perhaps you missed gaps has inserted to Claudio be able to manage his uncommitted changes recently? Or because when bug fixes backported requires new messages? It will of course add ability to a recent client see correct messages when connecting to new server. BTW, we'd better always update firebird.msg to older clients understand the most recent server major version or implement general code-to-string translation in the server. >>> Sometime you make me think that you read only what you want to read, not >>> what others wrote :( Does you read my idea about syntax support ? Does you read >>> another idea about to fill status-vector depending of client version ? >>> >> I will not store isc_random in the status vector if client is < 3.0 and >> isc_formatted_exception when >= 3.0. > > Why ? Probably you have really good argument to not do it ? I want to know it too. > I do not insist on it, just want to know what you know. > >> It's not how things should work. > > Surely, you and only you know how things should work :) > When I see request to encode the same exception in two different ways depending on the client version, given the fact that the status vector is supposed to be read by applications, I'm sure I shouldn't hear... :-) Adriano |
|
From: Dmitry Y. <fir...@ya...> - 2010-01-11 09:53:26
|
All, I'll try to comment to a few different messages at once. I'm not sure I remember all the proposed details (they're somewhat hidden inside the flame wars), so I'll be basically expressing my own opinion. Checking the client library version looks like a good solution, but it's not related to the things being discussed at all. This way we may speak about sending whatever GDS error code as isc_random if the client msg-version mismatches the server one. This resolves the backward compatibility for all possible new error codes as a whole. Implementing this just for the parametrized exceptions makes very little sense to me. The currently existing exception functionality must preserve the isc_except error code with its format (using isc_random). The formatted exception may either reuse the same error code and send the already formatted error message to the client or use the new isc_formatted_exception error code with the format text and the arguments and leave it up to the client to format the message. The answer depends on whether we care about older clients handling the exceptions thrown in a new way or not. Sending the formatted exception in both ways looks like an overkill to me. I don't buy the argument of using gds__msg_lookup() to get the message template text, as I don't know anyone needing this (and I'm not sure this routine is ever documented). Dmitry |
|
From: Dimitry S. <sd...@ib...> - 2010-01-11 10:05:06
|
11.01.2010 10:53, Dmitry Yemanov wrote: > The formatted exception may either reuse the same error code and send > the already formatted error message to the client or use the new > isc_formatted_exception error code with the format text and the > arguments and leave it up to the client to format the message. The > answer depends on whether we care about older clients handling the > exceptions thrown in a new way or not. I would vote for sending formatted exception always as a new error code. It is logical from POV of application programmer who prefer to parse status vector to extract parameters instead of parsing ready text for the same purpose. -- SY, SD. |
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-11 13:58:15
|
Dmitry Yemanov wrote: > All, > > I'll try to comment to a few different messages at once. I'm not sure I > remember all the proposed details (they're somewhat hidden inside the > flame wars), so I'll be basically expressing my own opinion. > > Checking the client library version looks like a good solution, but it's > not related to the things being discussed at all. This way we may speak > about sending whatever GDS error code as isc_random if the client > msg-version mismatches the server one. This resolves the backward > compatibility for all possible new error codes as a whole. Implementing > this just for the parametrized exceptions makes very little sense to me. > Exceptions are not meant to be always formatted by the client library, so changing codes depending on client version is non sense for me. You'll kill applications that parse the status vector to try to understand specific situations. > The currently existing exception functionality must preserve the > isc_except error code with its format (using isc_random). > Of course. > The formatted exception may either reuse the same error code and send > the already formatted error message to the client or use the new > isc_formatted_exception error code with the format text and the > arguments and leave it up to the client to format the message. The > answer depends on whether we care about older clients handling the > exceptions thrown in a new way or not. > This is the two ways I had did, and I can say the later is much better. It just works without client support. > Sending the formatted exception in both ways looks like an overkill to > me. I don't buy the argument of using gds__msg_lookup() to get the > message template text, as I don't know anyone needing this (and I'm not > sure this routine is ever documented). I never understand why this project don't want flexibility to the user. Can you explain? :-) Adding the template string does not add extra logic to the application. It just must start getting the arguments one element next. Since this is new feature and nobody know how to use it without read the documentation, there is nothing wrong with this. Additional string in the status vector will not make the application slower or consume all it memory. On the other hand, if the user want the string it will need to catch the error number and issue a query against rdb$exceptions. Considering that the original exception may even be thrown when starting a transaction (in a trigger), user need to start a transaction just for this. What a amount of work to do after an exception because the FB devs didn't want to include an useful string for nothing. This string may be important, just like exception name and arguments. It may be logged and searched for. It may be used to implement localization of exceptions by texts on the client. You may say these things can be implemented in different ways and I agree, but I see no sense in hide a piece of information that may be difficult (under the circumstances of an exception to be retrieved). There may be problem with length of status vectors, but I'd rather fix that. It was big problem for Java exceptions with they long stack traces. Looks like recently the internal limit has been increased or some architecture difference has changed. It showed truncated exception messages under Windows SS and worked correctly in Linux SC. Adriano |
|
From: Claudio V. C. <cv...@us...> - 2010-01-11 14:25:32
|
> -----Original Message----- > From: Adriano dos Santos Fernandes [mailto:adr...@gm...] > Sent: Lunes, 11 de Enero de 2010 10:32 > > There may be problem with length of status vectors, but I'd rather fix > that. It was big problem for Java exceptions with they long stack > traces. Looks like recently the internal limit has been increased or > some architecture difference has changed. It showed truncated > exception > messages under Windows SS and worked correctly in Linux SC. Maybe this is related to the internal circular buffers used for exceptions? C. |
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-11 14:32:05
|
Claudio Valderrama C. wrote: >> -----Original Message----- >> From: Adriano dos Santos Fernandes [mailto:adr...@gm...] >> Sent: Lunes, 11 de Enero de 2010 10:32 >> >> There may be problem with length of status vectors, but I'd rather fix >> that. It was big problem for Java exceptions with they long stack >> traces. Looks like recently the internal limit has been increased or >> some architecture difference has changed. It showed truncated >> exception >> messages under Windows SS and worked correctly in Linux SC. > > Maybe this is related to the internal circular buffers used for exceptions? > It's certainly in this change that things became better, but I don't remember if just because the limit for each string has increased. Adriano |
|
From: Dmitry Y. <fir...@ya...> - 2010-01-11 14:38:43
|
Adriano, > Exceptions are not meant to be always formatted by the client library, > so changing codes depending on client version is non sense for me. > You'll kill applications that parse the status vector to try to > understand specific situations. Valid point, thanks. > I never understand why this project don't want flexibility to the user. > Can you explain? :-) I'm against the flexibility which is added just for the sake of flexibility. We need to address particular user needs, preferably expressed publicly (e.g. via the tracker) and by more than a single person. I don't think we should develop a LEGO thingy to please the every possible fantasy of our users ;-) > On the other hand, if the user want the string it will need to catch the > error number and issue a query against rdb$exceptions. Considering that > the original exception may even be thrown when starting a transaction > (in a trigger), user need to start a transaction just for this. What a > amount of work to do after an exception because the FB devs didn't want > to include an useful string for nothing. We have exactly the same situation in the API. Users may need various information being available during prepare. We provide some subset via XSQLDA, but the rest should be retrieved via isc_dsql_sql_info(). In many cases it means an extra rountrip. And IMO this is perfectly okay. I don't think we should deliver (in advance) whatever information the client may wish. And I'm still not convinced regarding its usefulness, sorry. Dmitry |
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-11 15:17:01
|
Dmitry Yemanov wrote:
> information being available during prepare. We provide some subset via
> XSQLDA, but the rest should be retrieved via isc_dsql_sql_info().
Do not think this API is a model to discuss good architecture :-),
although this has nothing to do with the topic.
> In many cases it means an extra rountrip. And IMO this is perfectly okay.
I'd say the cost x benefit is so high. There was better way to do it in
the start.
> I don't think we should deliver (in advance) whatever information the
> client may wish.
>
When it offers a flexibility (allowing, well, requiring) you to pass a
output SQLDA in each fetch, it need to parse it and create messages at
every function call. Seems the reason that Dimitry S. says DSQL queries
are much slower than BLR ones.
In GDS_DSQL_FETCH, this piece should be slow:
USHORT blr_length, msg_type, msg_length;
if (UTLD_parse_sqlda(status, &dasup, &blr_length, &msg_type,
&msg_length, dialect, sqlda, DASUP_CLAUSE_select))
{
return status[1];
}
And in the function start:
if (!sqlda)
{
status_exception::raise(Arg::Gds(isc_dsql_sqlda_err));
}
I think we can allow DSQL_FETCH to be called with NULL sqlda when
DSQL_EXECUTE2 has been called with a non-null out_sqlda. In this case we
don't need to reparse it at every fetch.
And when the API allows you to be flexible and didn't it by default, it
makes queries that need (for example, the update count) to do another
roundtrip. Certainly a bad designed thing, hiding some bytes in most
queries but making the not-so-uncommon case much more slower.
This one I don't see a good way to fix without introduce new calls.
I had prototyped client PreparedStatement/ResultSet class that works
with the message API. It's much raw yet, but I believe it can be faster
than the SQLDA API due to the first issue.
Adriano
|
|
From: Dmitry Y. <fir...@ya...> - 2010-01-15 09:48:15
|
Adriano,
> When it offers a flexibility (allowing, well, requiring) you to pass a
> output SQLDA in each fetch, it need to parse it and create messages at
> every function call. Seems the reason that Dimitry S. says DSQL queries
> are much slower than BLR ones.
>
> In GDS_DSQL_FETCH, this piece should be slow:
> USHORT blr_length, msg_type, msg_length;
> if (UTLD_parse_sqlda(status,&dasup,&blr_length,&msg_type,
> &msg_length, dialect, sqlda, DASUP_CLAUSE_select))
> {
> return status[1];
> }
>
> And in the function start:
> if (!sqlda)
> {
> status_exception::raise(Arg::Gds(isc_dsql_sqlda_err));
> }
>
> I think we can allow DSQL_FETCH to be called with NULL sqlda when
> DSQL_EXECUTE2 has been called with a non-null out_sqlda. In this case we
> don't need to reparse it at every fetch.
Perhaps we could also allow DSQL_FETCH to be called with NULL sqlda if
any prior DSQL_FETCH calls were with non-null sqlda. In other words, we
should just cache the most recently used non-null output sqlda and use
it when user specifies null output SQLDA. I agree it would be an useful
improvement.
Another related thing (from memory, so I may be imprecise) could be to
still parse the (non-null) output sqlda but don't recreate the output
message every time. Just compare the current sqlda with the priorly used
one and reuse the last message if sqlda hasn't changed.
Dmitry
|
|
From: Adriano d. S. F. <adr...@gm...> - 2010-01-15 13:07:22
|
Dmitry Yemanov wrote:
> Adriano,
>
>> When it offers a flexibility (allowing, well, requiring) you to pass a
>> output SQLDA in each fetch, it need to parse it and create messages at
>> every function call. Seems the reason that Dimitry S. says DSQL queries
>> are much slower than BLR ones.
>>
>> In GDS_DSQL_FETCH, this piece should be slow:
>> USHORT blr_length, msg_type, msg_length;
>> if (UTLD_parse_sqlda(status,&dasup,&blr_length,&msg_type,
>> &msg_length, dialect, sqlda, DASUP_CLAUSE_select))
>> {
>> return status[1];
>> }
>>
>> And in the function start:
>> if (!sqlda)
>> {
>> status_exception::raise(Arg::Gds(isc_dsql_sqlda_err));
>> }
>>
>> I think we can allow DSQL_FETCH to be called with NULL sqlda when
>> DSQL_EXECUTE2 has been called with a non-null out_sqlda. In this case we
>> don't need to reparse it at every fetch.
>
> Perhaps we could also allow DSQL_FETCH to be called with NULL sqlda if
> any prior DSQL_FETCH calls were with non-null sqlda. In other words, we
> should just cache the most recently used non-null output sqlda and use
> it when user specifies null output SQLDA. I agree it would be an useful
> improvement.
>
Also possible.
> Another related thing (from memory, so I may be imprecise) could be to
> still parse the (non-null) output sqlda but don't recreate the output
> message every time.
...
> Just compare the current sqlda with the priorly used
> one and reuse the last message if sqlda hasn't changed.
>
I thought on storing the last sqlda value and comparing it with the passed one, and totally skip the UTLD call.
It would make applications faster automatically, but there will be a potential problem, if the user pass the same sqlda with something changed. I don't think users are doing that, but is something valid currently.
Do you mean the same thing? If not, I didn't understood the "still parse ... but don't recreate ..." part.
Adriano
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X