Re: [Firebird-devel] Database dialect and BIGINT in metadata
On Wed, Oct 31, 2012 at 2:51 AM, Adriano dos Santos Fernandes adrian...@gmail.com wrote: Hi! RDB$TRIGGERS.RDB$TRIGGER_TYPE was extended to BIGINT in v3, to support DDL triggers. It was difficult to found what was going wrong with CORE-3964, but then I found it. First, INI_init checks DBB_DB_SQL_dialect_3 which works on database creation, but on opening, it's set only in PAG_header (called after INI_init). But, anyway, I don't think treating a metadata field created with a type on a dialect is going to work after that dialect is changed and the type is interpreted as another one. Also, in no way that field could be interpreted as a double, as it has bits who changes (on conversion from/to SINT64) dues to double imprecision. I have no idea what to do (well, actually I have a very easy and good one, you know, it's to wipe dialect 1/2). I'd hate to split a single field in two to support something which should be removed +10 years ago. Dialect 1/2 logic was for supporting migration of interbase 5 to firebird 1.0 I hope that clients had the time to migrate -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
I have no idea what to do (well, actually I have a very easy and good one, you know, it's to wipe dialect 1/2). I'd hate to split a single field in two to support something which should be removed +10 years ago. Dialect 1/2 logic was for supporting migration of interbase 5 to firebird 1.0 I hope that clients had the time to migrate They haven't Paul -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On Wed, 31 Oct 2012 08:41:39 +0100, Paul Beach pbe...@ibphoenix.com wrote: I have no idea what to do (well, actually I have a very easy and good one, you know, it's to wipe dialect 1/2). I'd hate to split a single field in two to support something which should be removed +10 years ago. Dialect 1/2 logic was for supporting migration of interbase 5 to firebird 1.0 I hope that clients had the time to migrate They haven't Don't you mean: they didn't use that time ;) IMHO: Dropping dialect 1 and 2 should be done with Firebird 3. People still depending on dialect 1 will then be stuck on Firebird 2.5 until they migrate to dialect 3. I think that is a better option than keep dragging support for legacy compatibility. Mark -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On Wed, 31 Oct 2012 08:41:39 +0100, Paul Beach pbe...@ibphoenix.com wrote: I have no idea what to do (well, actually I have a very easy and good one, you know, it's to wipe dialect 1/2). I'd hate to split a single field in two to support something which should be removed +10 years ago. Dialect 1/2 logic was for supporting migration of interbase 5 to firebird 1.0 I hope that clients had the time to migrate They haven't Don't you mean: they didn't use that time ;) IMHO: Dropping dialect 1 and 2 should be done with Firebird 3. People still depending on dialect 1 will then be stuck on Firebird 2.5 until they migrate to dialect 3. I think that is a better option than keep dragging support for legacy compatibility. +1. Firebird 3 might be a good milestone to ditch dialect 3 support. Regards, Thomas -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 12:29, Thomas Steinmaurer wrote: IMHO: Dropping dialect 1 and 2 should be done with Firebird 3. People still depending on dialect 1 will then be stuck on Firebird 2.5 until they migrate to dialect 3. I think that is a better option than keep dragging support for legacy compatibility. +1. Firebird 3 might be a good milestone to ditch dialect 3 support. So far our rule was to declare some feature deprecated in version N and remove it in version N+1. What you suggest looks a bit more aggressive than our users might expect. That said, I'm against the idea in general ;-) Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 12:50, Thomas Steinmaurer wrote: That said, I'm against the idea in general ;-) Sorry, I had intended to write: That said, I'm NOT against the idea in general as it should obviously be wiped out sooner rather than later. But this is exactly the case when my personal humble opinion conflicts with the management one. But let's hear other opinions as well, I'm not a dictator ;-) Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Dmitry, 31.10.2012 12:50, Thomas Steinmaurer wrote: That said, I'm against the idea in general ;-) Sorry, I had intended to write: That said, I'm NOT against the idea in general as it should obviously be wiped out sooner rather than later. But this is exactly the case when my personal humble opinion conflicts with the management one. But let's hear other opinions as well, I'm not a dictator ;-) Deprecating dialects in Fb3 will not hurt anyone but at the same time deliver a message. Then you can postpone the decision to wipe them in the next release or later. -- Nando Dessena -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 13:12, Nando Dessena wrote: Deprecating dialects in Fb3 will not hurt anyone but at the same time deliver a message. Then you can postpone the decision to wipe them in the next release or later. No objections here, it just doesn't resolve the original problem Adriano is facing. Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 10/31/12 13:02, Dmitry Yemanov wrote: 31.10.2012 12:50, Thomas Steinmaurer wrote: That said, I'm against the idea in general ;-) Sorry, I had intended to write: That said, I'm NOT against the idea in general as it should obviously be wiped out sooner rather than later. But this is exactly the case when my personal humble opinion conflicts with the management one. But let's hear other opinions as well, I'm not a dictator ;-) Certainly, removing dialects support will make development simpler in some aspects. But I'm afraid simple solution here does not mean correct. Let's make dialects 1 2 deperectaed in FB3 and get rid of them in next version. Returning to initial problem. Do we suppose to create /*for example*/ trigger on create table or alter exception or drop role? If yes, bitmask encoding in int64 makes sense. If not and all of this just to have beautiful implementation of trigger for any ddl, probably better encode ddl trigger type in a byte and use additional check in all DDL for any ddl statement trigger. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 13:15, Dimitry Sibiryakov wrote: I wonder why you don't allow to use BIGINT in dialect 1... It was an old (FB1.5 time) decision to avoid some new features in Dialect 3, especially those that old clients may be not prepared to deal with. However, I must admit that that rule was not strictly followed (but I don't remember any other new datatypes added in v2.x either). Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 31/10/2012 07:21, Alex Peshkoff wrote: Returning to initial problem. Do we suppose to create /*for example*/ trigger on create table or alter exception or drop role? If yes, bitmask encoding in int64 makes sense. This is what it does: ddl event ::= ANY DDL STATEMENT | ddl event item [{OR ddl event item}...] ddl event item ::= CREATE TABLE | ALTER TABLE | DROP TABLE | CREATE PROCEDURE ... Adriano -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 10/31/12 13:39, Adriano dos Santos Fernandes wrote: On 31/10/2012 07:21, Alex Peshkoff wrote: Returning to initial problem. Do we suppose to create /*for example*/ trigger on create table or alter exception or drop role? If yes, bitmask encoding in int64 makes sense. This is what it does: ddl event ::= ANY DDL STATEMENT |ddl event item [{ORddl event item}...] ddl event item ::= CREATE TABLE | ALTER TABLE | DROP TABLE | CREATE PROCEDURE ... I understand very well that it's a dirty hack (the only excuse is that dialect 1 is a hack itself), but what about having 2 32-bit fields in ODS12? In ODS13 we will remove that hack. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 31/10/2012 08:17, Alex Peshkoff wrote: On 10/31/12 13:39, Adriano dos Santos Fernandes wrote: On 31/10/2012 07:21, Alex Peshkoff wrote: Returning to initial problem. Do we suppose to create /*for example*/ trigger on create table or alter exception or drop role? If yes, bitmask encoding in int64 makes sense. This is what it does: ddl event ::= ANY DDL STATEMENT |ddl event item [{ORddl event item}...] ddl event item ::= CREATE TABLE | ALTER TABLE | DROP TABLE | CREATE PROCEDURE ... I understand very well that it's a dirty hack (the only excuse is that dialect 1 is a hack itself), but what about having 2 32-bit fields in ODS12? In ODS13 we will remove that hack. I'd prefer to hack on allowing BIGINT on dialect 1 than do this and deal with its consequences (gbak, isql, third party clients) later. Adriano -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Hi, Well, if removing dialect 1 in FB 3.0 is NOT out of question, I'm strongly for its removal (not just deprecation) in 3.0. While some may object that it's: a) violation of our deprecation policy. b) not advance enough notification to give users time to adapt. I would like point out that: a) There is no project manifest or development contract at our website that would codify such deprecation policy. It's just convenient routine we decided to follow. So we're not bound to follow it to the letter, as there is no such letter and never was. b) If we will announce the removal of dialect 1 support now, users of dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to adapt their applications (for early adoption) and about 5-7 years as final deadline (when support of last FB version having dialect 1 would be discontinued by *project*). IMHO plenty of time. We should also take into account the impact factor of such move: a) It's mostly about pre-IB 6.0 applications that were not adapted to dialect 3 since then. How many such apps do you think it's still out there? Up to 0.01% ? b) All new applications since IB 6.0 / FB 1.0 are dialect 3 applications, with very very few exception (if there are any at all). So negative impact would be to very small fraction of FB users, while positive impact would affect the rest. Over all 12 years of FB development it became clear that *remaining* dialect 1 users simply can't switch at all (old legacy app, they certainly switch with new app. versions), so giving them another 2 years inserting deprecation version before removal will not help them in any significant way. So in my opinion it's ok to announce the removal of dialect 1 in 3.0 NOW, and do it. Especially when 3.0 is (and was) presented for long time as Firebird reborn version (new ODS, new API, new architecture etc.) and a potential deal-breaker for legacy stuff. best regards Pavel Cisar IBPhoenix Dne 31.10.2012 10:02, Dmitry Yemanov napsal(a): Sorry, I had intended to write: That said, I'm NOT against the idea in general as it should obviously be wiped out sooner rather than later. But this is exactly the case when my personal humble opinion conflicts with the management one. But let's hear other opinions as well, I'm not a dictator ;-) -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 14:17, Alex Peshkoff wrote: what about having 2 32-bit fields in ODS12? In ODS13 we will remove that hack I don't think we can remove system fields at all, at least without breaking an unknown number of applications. And requiring users to decode the trigger type based on either one or two fields depending on ODS sounds absolutely crazy. Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 14:29, Adriano dos Santos Fernandes wrote: I'd prefer to hack on allowing BIGINT on dialect 1 So far it looks like a lesser evil. Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 11:36, Pavel Cisar wrote: So negative impact would be to very small fraction of FB users, while positive impact would affect the rest. Could you tell more about this positive impact?.. -- WBR, SD. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Pavel Cisar wrote: b) If we will announce the removal of dialect 1 support now, users of dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to adapt their applications (for early adoption) and about 5-7 years as final deadline (when support of last FB version having dialect 1 would be discontinued by*project*). IMHO plenty of time. One would think so - but I'm still running systems first installed in the late 90's ;) They work just fine still and the customers will not let me change them. The current schemas are still compatible with the data from the last century. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On Wed, 31 Oct 2012 13:02:50 +0400, Dmitry Yemanov firebi...@yandex.ru wrote: 31.10.2012 12:50, Thomas Steinmaurer wrote: That said, I'm against the idea in general ;-) Sorry, I had intended to write: That said, I'm NOT against the idea in general as it should obviously be wiped out sooner rather than later. But this is exactly the case when my personal humble opinion conflicts with the management one. But let's hear other opinions as well, I'm not a dictator ;-) IMHO dialect 1 could already be considered deprecated since Interbase 6.0/Firebird 1.0. Providing a new dialect (3) and a dialect to migrate (2) is - to me - a clear sign of deprecation. Mark -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On Wed, 31 Oct 2012 14:39:13 +0400, Dmitry Yemanov firebi...@yandex.ru wrote: 31.10.2012 14:17, Alex Peshkoff wrote: what about having 2 32-bit fields in ODS12? In ODS13 we will remove that hack I don't think we can remove system fields at all, at least without breaking an unknown number of applications. And requiring users to decode the trigger type based on either one or two fields depending on ODS sounds absolutely crazy. But to the original problem: Why not just declare it as a NUMERIC(27,0), as I believe that is the equivalent to BIGINT, or doesn't that apply to dialect 1? Also didn't Firebird internally already have 64 bit fields (eg DOUBLE, ISC_QUAD), or are all those also artefacts of dialect 3? Mark -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 10/31/12 14:39, Dmitry Yemanov wrote: 31.10.2012 14:29, Adriano dos Santos Fernandes wrote: I'd prefer to hack on allowing BIGINT on dialect 1 So far it looks like a lesser evil. what about char(8) octets? Last try :-) -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Dne 31.10.2012 11:46, Lester Caine napsal(a): Pavel Cisar wrote: b) If we will announce the removal of dialect 1 support now, users of dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to adapt their applications (for early adoption) and about 5-7 years as final deadline (when support of last FB version having dialect 1 would be discontinued by*project*). IMHO plenty of time. One would think so - but I'm still running systems first installed in the late 90's ;) They work just fine still and the customers will not let me change them. The current schemas are still compatible with the data from the last century. But the important question here is whether you plan to switch these systems to run on FB 3.0 or not? If you plan to do that and they're actually untouchable, what benefit you expect from the transition to FB 3.0? regards Pavel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 14:51, Mark Rotteveel wrote: But to the original problem: Why not just declare it as a NUMERIC(27,0), as I believe that is the equivalent to BIGINT, or doesn't that apply to dialect 1? NUMERIC(18) is the maximum we can offer. And yes, it's different between dialects 1 and 3. It's backed by double precision in the former case, exactly because int64 is not available in dialect 1. Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Dne 31.10.2012 11:40, Dimitry Sibiryakov napsal(a): 31.10.2012 11:36, Pavel Cisar wrote: So negative impact would be to very small fraction of FB users, while positive impact would affect the rest. Could you tell more about this positive impact?.. For example: 1. Cleaner code - less potential for bugs. 2. Resources spent on backward compatibility could be spent on something else. 3. New interfaces could be simpler without dialects (if they're not D3-only already). Less hassles with old APIs as dialect would be (optional) ignored. regards --Pavel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
That said, I'm NOT against the idea in general as it should obviously be wiped out sooner rather than later. But this is exactly the case when my personal humble opinion conflicts with the management one. But let's hear other opinions as well, I'm not a dictator ;-) Dmitry I think we should keep dialect 1 at any cost! And I'd also like to see a FB3 version for ZX81. Poul Dige PS. Both statements are jokes :) Lets move forward, FB3 will be a great time to get rid of previous sins! As FB2.5 works great, it will not harm anyone to make FB3 a basis for future demands instead of a crippled version only due to backwards compatibility. If it makes the code base simpler, our coders will be more efficient - and probably happier - too! -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 15:32, Thomas Steinmaurer wrote: Management = Firebird Admin List? Nope, I meant just another part of my responsibilities ;-) Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 14:36, Pavel Cisar wrote: a) It's mostly about pre-IB 6.0 applications that were not adapted to dialect 3 since then. How many such apps do you think it's still out there? Up to 0.01% ? b) All new applications since IB 6.0 / FB 1.0 are dialect 3 applications, with very very few exception (if there are any at all). So negative impact would be to very small fraction of FB users I would disagree about the number of D1 users. For example, quite a few customers are not going to move to D3 only because of the overflow issues in the numeric arithmetics. We claim it to be addressed in Firebird 3, but there may be other preventing reasons as well. Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Over all 12 years of FB development it became clear that *remaining* dialect 1 users simply can't switch at all (old legacy app, they certainly switch with new app. versions), so giving them another 2 years inserting deprecation version before removal will not help them in any significant way. I hope to be wrong and that changed, but AFAIR, the legacy dialects are never removed mainly because BroadView systems are not prepared for it, and they are FF sponsors. Ok, money is involved, but I'm sorry, but this can't be the primarily argument to disallow moving forward. Other sponsors might think differently ... Yes, I'm PRO moving forward and I'm not a sponsor and yes, I have legacy D1 databases out there. Regards, Thomas -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 15:32, Thomas Steinmaurer wrote: Management = Firebird Admin List? Nope, I meant just another part of my responsibilities ;-) Ah, ok. I guess you have a bunch of hats for different roles in your garderobe then. ;-) Regards, Thomas -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Dne 31.10.2012 12:26, Alex Peshkoff napsal(a): On 10/31/12 15:03, Pavel Cisar wrote: Let me answer. As a minimum - shared pages cache and i.e. better SMP support. But only if you need both of them at the same time, individually they're provided by pre-3.0 versions. Anyway, this is just potential benefit, I was asking what this application *really* need that only 3.0 can provide in situation that it works just fine for last twelve years :) regards --Pavel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 10/31/12 15:45, Pavel Cisar wrote: Dne 31.10.2012 12:26, Alex Peshkoff napsal(a): On 10/31/12 15:03, Pavel Cisar wrote: Let me answer. As a minimum - shared pages cache and i.e. better SMP support. But only if you need both of them at the same time, individually they're provided by pre-3.0 versions. This combination provides serious performance increase. Anyway, this is just potential benefit, I was asking what this application *really* need that only 3.0 can provide in situation that it works just fine for last twelve years :) I do not think that all mentioned apps are unchanged for that 12 years. Complexity grows, though basis remains the same. And with growing complexity better performance on same HW is what one *really* needs. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Pavel Cisar wrote: Pavel Cisar wrote: b) If we will announce the removal of dialect 1 support now, users of dialect 1 planning to switch to FB 3.0 will have at least 1.5 years to adapt their applications (for early adoption) and about 5-7 years as final deadline (when support of last FB version having dialect 1 would be discontinued by*project*). IMHO plenty of time. One would think so - but I'm still running systems first installed in the late 90's;) They work just fine still and the customers will not let me change them. The current schemas are still compatible with the data from the last century. But the important question here is whether you plan to switch these systems to run on FB 3.0 or not? If you plan to do that and they're actually untouchable, what benefit you expect from the transition to FB 3.0? I was just point out that 5-7 years is not such a long time these days. Some of the machines are stuck with W2k so they are 'frozen' and while replacing hardware IS becoming a problem, I can probably keep them going another 10 years. We will have to address a move at some point but HOPEFULLY office refits will dictate that before the software does :) The new hardware creates reports that used to be a half hour job in seconds ... so there is little incentive to spend too much time moving stuff over. Even on the FB2.5 sites running 50+ users I'm not seeing more than perhaps 20 minutes 'work' in 24 hours of 'idle' time. All this used to run on a '286' so was any need to 'upgrade' at all? The 'job' has not changed in now coming on 20 years. How we do it has changed, and what is reported changes, but at the end of the day is getting a web page up in 3 seconds rather than 4 a productivity advantage? You still have to talk to the client and type in data. A one hour interview results in a few seconds of data to save. Oh for the days when I NEED a networked database ... Perhaps I'll start earning some money as well :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 31/10/2012 10:12, Mark Rotteveel wrote: Databases and applications still using dialect 1 should simply take the effort now to switch, or remain left behind on Firebird 2.5 max. It is the consequence of a decision to continue to use a legacy option. Continuing support for dialect 1 in Firebird and creating workarounds to that end just because we don't want to leave anyone behind is - IMHO - a waste of effort and time that the Firebird project could better spend on other things. I agree. I hate to need to adapt to new software versions, and some libraries I use requires a lot of changes as they evolve. But in many of Firebird tickets I have assigned to me, I just can't do anything. There is just no way to fix them without any form of incompatibility. Adriano -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On Wed, Oct 31, 2012 at 2:18 PM, Adriano dos Santos Fernandes adrian...@gmail.com wrote: On 31/10/2012 10:12, Mark Rotteveel wrote: Databases and applications still using dialect 1 should simply take the effort now to switch, or remain left behind on Firebird 2.5 max. It is the consequence of a decision to continue to use a legacy option. Continuing support for dialect 1 in Firebird and creating workarounds to that end just because we don't want to leave anyone behind is - IMHO - a waste of effort and time that the Firebird project could better spend on other things. I agree. I hate to need to adapt to new software versions, and some libraries I use requires a lot of changes as they evolve. But in many of Firebird tickets I have assigned to me, I just can't do anything. There is just no way to fix them without any form of incompatibility. I see that 3.0 is in feature freeze mode . maybe is time for 3.5 branch or the next-gen branch where you can solve some of the agresive changes and bugs -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
31.10.2012 17:42, marius adrian popa wrote: I see that 3.0 is in feature freeze mode No, it's not. Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On Wed, Oct 31, 2012 at 6:51 AM, Mark Rotteveel m...@lawinegevaar.nlwrote: Also didn't Firebird internally already have 64 bit fields (eg DOUBLE, ISC_QUAD), or are all those also artefacts of dialect 3? InterBase was developed on MicroVaxen which had a 64-bit integer datatype. So from V1, there was support for what was called QUAD. Contemporary Intel and Motorola processors did not support the type, so it was dropped for those versions. While adding features to dialect 1 seems absurd, I think you'll find that some major supporters of Firebird are still running dialect 1 databases because they maintain internal precision during arithmetic better than dialect 3. For reasons beyond me the Borland developers felt that the precision of the input and output parameters had to constrain the precision during a computation - leading to lots of dropped bits that could have been preserved. Cheers, Ann -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_octFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Workaround for CORE-3964 - RDB$TRIGGERS with BIGINT and dialect 1
As an immediate workaround for subj., I propose to let BIGINT (and DATEand TIME) to be passed for dialect 1 clients. Thechanges just transform something that is currently an error into something that may be unexpected (SQL_INT64) but will work for good clients. Arithmetics will not be changed: -- Create database on dialect 3 isql create table t1 (n1 numeric(12,3)); insert into t1 values (1.23); insert into t1 values (10.23); insert into t1 values (3.567); commit; exit; -- Change database and client to dialect 1 (with new semantics) gfix -sql_dialect 1 zz.fdb isql -sql_dialect 1 zz.fdb set sqlda_display on; select n1, n1 / 2 from t1; OUTPUT SQLDA version: 1 sqln: 20 sqld: 2 01: sqltype: 581 INT64 Nullable sqlscale: -3 sqlsubtype: 1 sqllen: 8 : name: (2)N1 alias: (2)N1 : table: (2)T1 owner: (6)SYSDBA 02: sqltype: 481 DOUBLENullable sqlscale: 0 sqlsubtype: 0 sqllen: 8 : name: (6)DIVIDE alias: (6)DIVIDE : table: (0) owner: (0) N1 DIVIDE = === 1.230 0.6150 10.230 5.115 3.567 1.7835000 -- Test with current dialect 1 Statement failed, SQLSTATE = 42S22 Dynamic SQL Error -SQL error code = -206 -Column unknown -N1 -Client SQL dialect 1 does not support reference to BIGINT datatype Adriano PS: patch is attached. diff --git a/src/dsql/ExprNodes.cpp b/src/dsql/ExprNodes.cpp index 09c1655..04943b0 100644 --- a/src/dsql/ExprNodes.cpp +++ b/src/dsql/ExprNodes.cpp @@ -5012,19 +5012,6 @@ ValueExprNode* FieldNode::internalDsqlPass(DsqlCompilerScratch* dsqlScratch, Rec // Intercept any reference to a field with datatype that // did not exist prior to V6 and post an error - if (dsqlScratch-clientDialect = SQL_DIALECT_V5 field - (field-fld_dtype == dtype_sql_date || - field-fld_dtype == dtype_sql_time || field-fld_dtype == dtype_int64)) - { - ERRD_post(Arg::Gds(isc_sqlerr) Arg::Num(-206) - Arg::Gds(isc_dsql_field_err) - Arg::Gds(isc_random) Arg::Str(field-fld_name) - Arg::Gds(isc_sql_dialect_datatype_unsupport) - Arg::Num(dsqlScratch-clientDialect) - Arg::Str(DSC_dtype_tostring(static_castUCHAR(field-fld_dtype; - return NULL; - } - // CVC: Stop here if this is our second or third iteration. // Anyway, we can't report more than one ambiguity to the status vector. // AB: But only if we're on different scope level, because a @@ -5339,28 +5326,6 @@ void FieldNode::setParameterName(dsql_par* parameter) const // Generate blr for a field - field id's are preferred but not for trigger or view blr. void FieldNode::genBlr(DsqlCompilerScratch* dsqlScratch) { - // For older clients - generate an error should they try and - // access data types which did not exist in the older dialect. - if (dsqlScratch-clientDialect = SQL_DIALECT_V5) - { - switch (dsqlField-fld_dtype) - { - case dtype_sql_date: - case dtype_sql_time: - case dtype_int64: - ERRD_post(Arg::Gds(isc_sqlerr) Arg::Num(-804) - Arg::Gds(isc_dsql_datatype_err) - Arg::Gds(isc_sql_dialect_datatype_unsupport) - Arg::Num(dsqlScratch-clientDialect) - Arg::Str(DSC_dtype_tostring(static_castUCHAR(dsqlField-fld_dtype; - break; - - default: - // No special action for other data types - break; - } - } - if (dsqlIndices) dsqlScratch-appendUChar(blr_index); diff --git
Re: [Firebird-devel] Database dialect and BIGINT in metadata
Ann, InterBase was developed on MicroVaxen which had a 64-bit integer datatype. So from V1, there was support for what was called QUAD. Contemporary Intel and Motorola processors did not support the type, so it was dropped for those versions. Can we conclude that no client app existing these days should be able to deal with blr_quad / dtype_quad? This sounds as a good cleanup possibility. Dmitry -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Workaround for CORE-3964 - RDB$TRIGGERS with BIGINT and dialect 1
N1 DIVIDE = === 1.230 0.6150 10.230 5.115 3.567 1.7835000 -- Test with current dialect 1 Statement failed, SQLSTATE = 42S22 Dynamic SQL Error -SQL error code = -206 -Column unknown -N1 -Client SQL dialect 1 does not support reference to BIGINT datatype In that case thre is nothing more to talk about. From the first letter I've got a feeling that adding such support can beak things. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_octFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 31-10-2012 22:23, Leyne, Sean wrote: Over all 12 years of FB development it became clear that *remaining* dialect 1 users simply can't switch at all (old legacy app, they certainly switch with new app. versions), so giving them another 2 years inserting deprecation version before removal will not help them in any significant way. I hope to be wrong and that changed, but AFAIR, the legacy dialects are never removed mainly because BroadView systems are not prepared for it, and they are FF sponsors. This is completely incorrect. My words were not meant to be interpreted as a critic, just a mater of fact as I see it. P.S. we have advocated/argued just like any other participants in this list. Yes, I know. But sponsor words has weight (even that being not a thing FF sells), like any member contributor of any kind in the project. Adriano -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Database dialect and BIGINT in metadata
On 31-10-2012 22:23, Leyne, Sean wrote: Over all 12 years of FB development it became clear that *remaining* dialect 1 users simply can't switch at all (old legacy app, they certainly switch with new app. versions), so giving them another 2 years inserting deprecation version before removal will not help them in any significant way. I hope to be wrong and that changed, but AFAIR, the legacy dialects are never removed mainly because BroadView systems are not prepared for it, and they are FF sponsors. This is completely incorrect. My words were not meant to be interpreted as a critic, just a mater of fact as I see it. P.S. we have advocated/argued just like any other participants in this list. Yes, I know. But sponsor words has weight (even that being not a thing FF sells), like any member contributor of any kind in the project. If it was not the case that other project teams members (Dmitry Y and Ann H) have acknowledged that there are significant issues with migration due to Borland's Dialect 3 implementation/rules, then I would agree that sponsor $$$ could be a factor. But without a general consensus, the issue is not moving forward because is it viewed as a bad idea as it would compromise too many existing installs/users. (a case of usability trumping coding elegance) Sean -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel