Menu
▾
▴
firebird-devel
|
From: Nickolay S. <sk...@bs...> - 2002-11-22 16:18:02
|
Hello, All ! I'm fixing bugs in SQLDA parameter mapping. I even fixed them in fact. For those who don't remember, current order of SQLDA parameter in select statements and subqueries is: FROM-CLAUSE, FIRST-CLAUSE, SKIP-CLAUSE, WHERE-CLAUSE, GROUP_BY-CLAUSE, SELECT-LIST, ORDER_BY-CLAUSE, HAVING-CLAUSE Redundant parameters are generated for fields in ORDER_BY-CLAUSE and GROUP_BY-CLAUSE accessed by index (but not in order_by-clause of union). I.e. number and order of parameters doesn't match SQL source string which order is: FIRST-CLAUSE, SKIP-CLAUSE, SELECT-LIST, FROM-CLAUSE, WHERE-CLAUSE, GROUP_BY-CLAUSE, HAVING-CLAUSE, ORDER_BY-CLAUSE. This inconsistency makes usage of parameters really painful experience. There are tools that rely on this incorrect behavior while generating dynamic SQL. It seems that popular ones like IBExpert are among of them. Supporting both new and older behavior is difficult and ill-formed, but usage of new semantics will break compatibility with some of existing applications. What I'm going to do is to test my fix some more and commit it to CVS as is. Suggestions ? -- Best regards, Nickolay Samofatov mailto:sk...@bs... |
|
From: Claudio V. C. <cv...@us...> - 2002-11-23 02:51:58
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Nickolay > Samofatov > Sent: Viernes 22 de Noviembre de 2002 12:19 > > This inconsistency makes usage of parameters really painful experience. > > There are tools that rely on this incorrect behavior while generating > dynamic SQL. It seems that popular ones like IBExpert are among of > them. IBO has code to overcome those bugs, too. > Supporting both new and older behavior is difficult and ill-formed, > but usage of new semantics will break compatibility with some of > existing applications. > > What I'm going to do is to test my fix some more and commit it to CVS > as is. Suggestions ? You'll break several applications. Can't you make that code conditional at run-time? C. -- Claudio Valderrama C. Consultant, SW developer. www.cvalde.com - www.firebirdSql.org |
|
From: Nickolay S. <sk...@bs...> - 2002-11-23 14:09:53
|
Hello, Claudio ! Saturday, November 23, 2002, 6:50:19 AM, you wrote: >> >> This inconsistency makes usage of parameters really painful experience. >> >> There are tools that rely on this incorrect behavior while generating >> dynamic SQL. It seems that popular ones like IBExpert are among of >> them. > IBO has code to overcome those bugs, too. Is this code already able to handle correct order of parameters ? I.e. is this code parameter order independent ? >> Supporting both new and older behavior is difficult and ill-formed, >> but usage of new semantics will break compatibility with some of >> existing applications. >> >> What I'm going to do is to test my fix some more and commit it to CVS >> as is. Suggestions ? > You'll break several applications. Can't you make that code conditional at > run-time? I can make add a copy of older pass1_rse and pass1_sort to the server. But this code is not very static and changes often. My experience tells me it means that non-default variant will die soon. What about introducing correct behavior in Alpha 5 and if there will be many complaints add bug-emulation layer ? I think it is really difficult to say now how many applications strongly depend on older buggy behavior. Public testing will tell exactly that. -- Best regards, Nickolay Samofatov mailto:sk...@bs... |
|
From: Claudio V. C. <cv...@us...> - 2002-11-24 02:34:10
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Nickolay > Samofatov > Sent: Sabado 23 de Noviembre de 2002 10:11 > > > IBO has code to overcome those bugs, too. > > Is this code already able to handle correct order of parameters ? > I.e. is this code parameter order independent ? Jason handles almost any combination, based on his experience, so I wouldn't be surprised if other tools do the same, relying on the current misbehavior. > I can make add a copy of older pass1_rse and pass1_sort to the server. > But this code is not very static and changes often. Fine. Leave the old code as it's now. No more fixes. If someone wants the improvements, the new code should be used. Also, the old code can be thought as IB-compatible. C. |
|
From: Nickolay S. <sk...@bs...> - 2002-11-24 10:39:44
|
Hello, Claudio ! Sunday, November 24, 2002, 6:32:49 AM, you wrote: > Jason handles almost any combination, based on his experience, so I wouldn't > be surprised if other tools do the same, relying on the current misbehavior. >> I can make add a copy of older pass1_rse and pass1_sort to the server. >> But this code is not very static and changes often. > Fine. Leave the old code as it's now. No more fixes. If someone wants the > improvements, the new code should be used. Also, the old code can be thought > as IB-compatible. I developed another bug solution because of your suggestions that we need to to handle both behaviors - parameter ordering based on pass1 order (current FB1/IB behavior) and parameter ordering based on lexer order. It allows to have no modifications in current pass1 logic and hide all difference in MAKE_parameter code. Supporing both behaviors should not be a problem now. There will be configuration parameter. > C. -- Best regards, Nickolay mailto:sk...@bs... |
|
From: Dmitry Y. <di...@us...> - 2002-11-24 10:47:06
|
Nickolay, > I developed another bug solution because of your suggestions that we > need to to handle both behaviors - parameter ordering based on pass1 > order (current FB1/IB behavior) and parameter ordering based on lexer > order. It allows to have no modifications in current pass1 logic and > hide all difference in MAKE_parameter code. > Supporing both behaviors should not be a problem now. > There will be configuration parameter. To me it seems to be the best solution, thanks. Dmitry |
|
From: <psc...@in...> - 2002-11-25 12:19:34
|
On 22 Nov 2002 at 23:50, Claudio Valderrama C. wrote: > > -----Original Message----- > > From: fir...@li... > > [mailto:fir...@li...]On Behalf Of > > Nickolay Samofatov Sent: Viernes 22 de Noviembre de 2002 12:19 > > > > This inconsistency makes usage of parameters really painful > > experience. > > > > There are tools that rely on this incorrect behavior while > > generating dynamic SQL. It seems that popular ones like IBExpert are > > among of them. > > IBO has code to overcome those bugs, too. > > > > Supporting both new and older behavior is difficult and ill-formed, > > but usage of new semantics will break compatibility with some of > > existing applications. > > > > What I'm going to do is to test my fix some more and commit it to > > CVS as is. Suggestions ? > > You'll break several applications. Can't you make that code > conditional at run-time? > Perhaps put that code into FB 1.5, but leave 1.0 as is, since 1.5 is still alpha, applications will have time to adjust. |
|
From: Martijn T. <m.t...@up...> - 2002-11-25 12:33:53
|
> > > This inconsistency makes usage of parameters really painful > > > experience. > > > > > > There are tools that rely on this incorrect behavior while > > > generating dynamic SQL. It seems that popular ones like IBExpert are > > > among of them. > > > > IBO has code to overcome those bugs, too. > > > > > > > Supporting both new and older behavior is difficult and ill-formed, > > > but usage of new semantics will break compatibility with some of > > > existing applications. > > > > > > What I'm going to do is to test my fix some more and commit it to > > > CVS as is. Suggestions ? > > > > You'll break several applications. Can't you make that code > > conditional at run-time? > > > > Perhaps put that code into FB 1.5, but leave 1.0 as is, since 1.5 is still alpha, > applications will have time to adjust. I have a hard time understanding this - there are simply enough apps that would like increased stability and performance just by replacing the db-engine (to v1.5). Even more, ALL tools need to be adjusted for this! And they still need to support Firebird 1 as well... any ideas on that? With regards, Martijn Tonies InterBase Workbench - the developer tool for InterBase http://www.upscene.com Firebird Workbench - the developer tool for Firebird http://www.upscene.com Upscene Productions http://www.upscene.com "This is an object-oriented system. If we change anything, the users object." |
|
From: Nickolay S. <sk...@bs...> - 2002-11-25 12:44:14
|
Hello, Martijn ! Monday, November 25, 2002, 3:36:01 PM, you wrote: >> > > This inconsistency makes usage of parameters really painful >> > > experience. >> > > > I have a hard time understanding this - there are simply enough apps that > would > like increased stability and performance just by replacing the db-engine (to > v1.5). > Even more, ALL tools need to be adjusted for this! And they still need to > support > Firebird 1 as well... any ideas on that? I already wrote, there will be a configuration parameter in FB 1.5 to enable older parameter ordering behavior. Older behavior will become available in FB1.5 as soon configuration manager will be ready for that (probably in next few days). > Martijn Tonies -- Best regards, Nickolay Samofatov mailto:sk...@bs... |
|
From: Martijn T. <m.t...@up...> - 2002-11-25 12:48:36
|
> >> > > This inconsistency makes usage of parameters really painful > >> > > experience. > >> > > > > > I have a hard time understanding this - there are simply enough apps that > > would > > like increased stability and performance just by replacing the db-engine (to > > v1.5). > > > Even more, ALL tools need to be adjusted for this! And they still need to > > support > > Firebird 1 as well... any ideas on that? > > I already wrote, there will be a configuration parameter in FB 1.5 to > enable older parameter ordering behavior. Older behavior will become > available in FB1.5 as soon configuration manager will be ready for that > (probably in next few days). (not having followed anything about the configuration manager) Via system views? (that would be nice!) :) -- Martijn |
|
From: Thomas M. <tm...@bs...> - 2002-11-25 15:18:09
|
You should be able to query the client and ask it which version of the engine you are talking to. Then you know which way to process the params. Martijn Tonies wrote: >>>>This inconsistency makes usage of parameters really painful >>>>experience. >>>> >>>>There are tools that rely on this incorrect behavior while >>>>generating dynamic SQL. It seems that popular ones like IBExpert are >>>>among of them. >>>> >>>> >>>IBO has code to overcome those bugs, too. >>> >>> >>> >>> >>>>Supporting both new and older behavior is difficult and ill-formed, >>>>but usage of new semantics will break compatibility with some of >>>>existing applications. >>>> >>>>What I'm going to do is to test my fix some more and commit it to >>>>CVS as is. Suggestions ? >>>> >>>> >>>You'll break several applications. Can't you make that code >>>conditional at run-time? >>> >>> >>> >>Perhaps put that code into FB 1.5, but leave 1.0 as is, since 1.5 is still >> >> >alpha, > > >>applications will have time to adjust. >> >> > >I have a hard time understanding this - there are simply enough apps that >would >like increased stability and performance just by replacing the db-engine (to >v1.5). > >Even more, ALL tools need to be adjusted for this! And they still need to >support >Firebird 1 as well... any ideas on that? > > >With regards, > >Martijn Tonies >InterBase Workbench - the developer tool for InterBase >http://www.upscene.com > >Firebird Workbench - the developer tool for Firebird >http://www.upscene.com > >Upscene Productions >http://www.upscene.com > >"This is an object-oriented system. >If we change anything, the users object." > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Firebird-devel mailing list >Fir...@li... >https://lists.sourceforge.net/lists/listinfo/firebird-devel > > > -- Thomas Miller Delphi Client/Server Certified Developer BSS Accounting & Distribution Software BSS Enterprise Accounting FrameWork http://www.bss-software.com |
|
From: Jason W. <jwh...@ib...> - 2002-11-25 19:03:40
|
Please keep in mind this makes it so that everyone would have to upgrade to a new version of IBO and recompile their applications. This may not be a bid deal to some people but it could be a show-stopper for others. Jason Wharton CPS - Mesa AZ http://www.ibobjects.com -- We may not have it all together -- -- But together we have it all -- "Thomas Miller" <tm...@bs...> wrote in message news:3DE...@bs...... > You should be able to query the client and ask it which version of the > engine you are > talking to. Then you know which way to process the params. > |
|
From: Thomas M. <tm...@bs...> - 2002-11-25 19:10:29
|
True, but I really don't like the idea of leaving a bug out there just because it would be inconvenient. This needs to be done on a major version and not back updated. Jason Wharton wrote: >Please keep in mind this makes it so that everyone would have to upgrade to >a new version of IBO and recompile their applications. This may not be a bid >deal to some people but it could be a show-stopper for others. > >Jason Wharton >CPS - Mesa AZ >http://www.ibobjects.com > >-- We may not have it all together -- >-- But together we have it all -- > > >"Thomas Miller" <tm...@bs...> wrote in message >news:3DE...@bs...... > > >> You should be able to query the client and ask it which version of the >>engine you are >>talking to. Then you know which way to process the params. >> >> >> > > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Get the new Palm Tungsten T >handheld. Power & Color in a compact size! >http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en >_______________________________________________ >Firebird-devel mailing list >Fir...@li... >https://lists.sourceforge.net/lists/listinfo/firebird-devel > > > -- Thomas Miller Delphi Client/Server Certified Developer BSS Accounting & Distribution Software BSS Enterprise Accounting FrameWork http://www.bss-software.com |
|
From: Claudio V. C. <cv...@us...> - 2002-11-26 02:39:22
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Thomas > Miller > Sent: Lunes 25 de Noviembre de 2002 11:02 > > You should be able to query the client and ask it which version of the > engine you are > talking to. Then you know which way to process the params. I requested the behavior to be configurable. Nickolay agreed as I understand. In this case, I'm not sure if the engine version is going to help. Maybe there's a way to read the config params other than resorting to the Services API? ;-) C. |
|
From: Nickolay S. <sk...@bs...> - 2002-11-26 12:28:33
|
Hello, Claudio ! Tuesday, November 26, 2002, 6:37:51 AM, you wrote: >> You should be able to query the client and ask it which version of the >> engine you are >> talking to. Then you know which way to process the params. > I requested the behavior to be configurable. Nickolay agreed as I > understand. In this case, I'm not sure if the engine version is going to > help. > Maybe there's a way to read the config params other than resorting to the > Services API? > ;-) Check for correct parameter order is simple. Issue query: -- select (select 'test' from rdb$database where 0=?) from rdb$database where 1=? -- with first parameter 0 and second 1. If you get a record you can depend on that parameter order and count ALWAYS matches SQL source string. Otherwise you'll have to resort to older tricks to workaround IB/FB1 bugs. What exactly were you talking about when describing parameter duplication ? If queries like this, when two extra paramters (of 4 total) were generated: -- select (select 'test' from rdb$database where 0=?) from rdb$database where 1=? group by 1 order by 1 -- than yes, I fixed this too. Lexer (parse.y), not pass1 compiler performs actiual parameter numbering and identification now. > C. -- Best regards, Nickolay Samofatov mailto:sk...@bs... |
|
From: Jason W. <jwh...@ib...> - 2002-11-25 19:11:59
|
What I would really appreciate is at the same time if you made it so that input parameters could pass in a name and that this name would appear in the SQLVAR record when doing the prepare/describe. It would also be great if you could define a SQLType for a parameter in the statement and have this be taken into consideration rather than an exception raised. While you are in the parameters thing, just as well tidy up all the issues so that there is a simple check in code for all the new features that are needed. Reason I ask for the handling of names for input parameters is because then I wouldn't have to care much what order the input parameters are in. The server would tell me their names and they could be in any order it wanted. Also, let me give you a beware, when you have a column of a query defined using an inline select that has an input parameter and then in the order by clause you refer to that column by number the input parameter of the inline select gets repeated automatically. Ideally it would be nice if you consolidated that to reuse instead of duplicating. Thanks, Jason Wharton CPS - Mesa AZ http://www.ibobjects.com -- We may not have it all together -- -- But together we have it all -- "Nickolay Samofatov" <sk...@bs...> wrote in message news:932...@bs...... > Hello, All ! > > I'm fixing bugs in SQLDA parameter mapping. I even fixed them in fact. > For those who don't remember, current order of SQLDA parameter in > select statements and subqueries is: > FROM-CLAUSE, FIRST-CLAUSE, SKIP-CLAUSE, WHERE-CLAUSE, GROUP_BY-CLAUSE, > SELECT-LIST, ORDER_BY-CLAUSE, HAVING-CLAUSE > Redundant parameters are generated for fields in ORDER_BY-CLAUSE and > GROUP_BY-CLAUSE accessed by index (but not in order_by-clause of union). > > I.e. number and order of parameters doesn't match SQL source string > which order is: > FIRST-CLAUSE, SKIP-CLAUSE, SELECT-LIST, FROM-CLAUSE, WHERE-CLAUSE, > GROUP_BY-CLAUSE, HAVING-CLAUSE, ORDER_BY-CLAUSE. > > This inconsistency makes usage of parameters really painful experience. > > There are tools that rely on this incorrect behavior while generating > dynamic SQL. It seems that popular ones like IBExpert are among of > them. > > Supporting both new and older behavior is difficult and ill-formed, > but usage of new semantics will break compatibility with some of > existing applications. > > What I'm going to do is to test my fix some more and commit it to CVS > as is. Suggestions ? > > -- > Best regards, > Nickolay Samofatov mailto:sk...@bs... |
|
From: Nickolay S. <sk...@bs...> - 2002-11-25 20:06:53
|
Hello, Jason ! Monday, November 25, 2002, 10:10:33 PM, you wrote: > What I would really appreciate is at the same time if you made it so that > input parameters could pass in a name and that this name would appear in the > SQLVAR record when doing the prepare/describe. It would also be great if you > could define a SQLType for a parameter in the statement and have this be > taken into consideration rather than an exception raised. > While you are in the parameters thing, just as well tidy up all the issues > so that there is a simple check in code for all the new features that are > needed. > Reason I ask for the handling of names for input parameters is because then > I wouldn't have to care much what order the input parameters are in. The > server would tell me their names and they could be in any order it wanted. Not in Firebird 1.5. No XSQLDA structure changes were planned in Firebird 1.5 and it is already feature-closed as I understand. You may add this as feature request for Firebird 2.0. There is a planned change of XSQLDA structure in this version. > Also, let me give you a beware, when you have a column of a query defined > using an inline select that has an input parameter and then in the order by > clause you refer to that column by number the input parameter of the inline > select gets repeated automatically. Ideally it would be nice if you > consolidated that to reuse instead of duplicating. Already fixed for all cases (group by and order by by ordinal). Fix is very general and applies to all DSQL constructs (it uses lexer order instead of pass1 order to process parameters). -- Best regards, Nickolay mailto:sk...@bs... |
|
From: Claudio V. C. <cv...@us...> - 2002-11-26 02:39:44
|
> -----Original Message----- > From: fir...@li... > [mailto:fir...@li...]On Behalf Of Nickolay > Samofatov > Sent: Lunes 25 de Noviembre de 2002 16:03 > > > Also, let me give you a beware, when you have a column of a > query defined > > using an inline select that has an input parameter and then in > the order by > > clause you refer to that column by number the input parameter > of the inline > > select gets repeated automatically. Ideally it would be nice if you > > consolidated that to reuse instead of duplicating. > > Already fixed for all cases (group by and order by by ordinal). Fix is > very general and applies to all DSQL constructs (it uses lexer order > instead of pass1 order to process parameters). So, no more silly param duplication in sub-selects, too? C. |
|
From: Jason W. <jwh...@ib...> - 2002-11-26 22:15:41
|
> > Reason I ask for the handling of names for input parameters is because then > > I wouldn't have to care much what order the input parameters are in. The > > server would tell me their names and they could be in any order it wanted. > > Not in Firebird 1.5. No XSQLDA structure changes were planned in > Firebird 1.5 and it is already feature-closed as I understand. > You may add this as feature request for Firebird 2.0. > There is a planned change of XSQLDA structure in this version. Absolutely no change to the structure would be necessary. You would just fill in the information the same as is done for field columns. Since right now the information is left blank everyone is ignoring them for parameters anyway so this would not break any applications to go ahead and pass this information through. Thanks, Jason Wharton CPS - Mesa AZ http://www.ibobjects.com -- We may not have it all together -- -- But together we have it all -- |
|
From: Dimitry S. <SD...@to...> - 2002-11-26 07:56:53
|
On 25 Nov 2002 at 23:03, Nickolay Samofatov wrote: >> Reason I ask for the handling of names for input parameters is >> because then I wouldn't have to care much what order the input >> parameters are in. The server would tell me their names and they >> could be in any order it wanted. > >Not in Firebird 1.5. No XSQLDA structure changes were planned in >Firebird 1.5 and it is already feature-closed as I understand. Names of input parameters don't require XSQLDA changing. Every XSQLVAR already contains place for two names - sqlname and aliasname. Filling them may be tricky (requires parser change and even may be network protocol) but useful. SY, Dimitry Sibiryakov. |
×
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