Re: [Firebird-devel] Database dialect and BIGINT in metadata

2012-10-31 Thread marius adrian popa
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

2012-10-31 Thread Paul Beach
 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

2012-10-31 Thread Mark Rotteveel
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

2012-10-31 Thread Thomas Steinmaurer
 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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Nando Dessena
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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Alex Peshkoff
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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Adriano dos Santos Fernandes
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

2012-10-31 Thread Alex Peshkoff
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

2012-10-31 Thread Adriano dos Santos Fernandes
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

2012-10-31 Thread Pavel Cisar
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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Dimitry Sibiryakov
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

2012-10-31 Thread Lester Caine
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

2012-10-31 Thread Mark Rotteveel
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

2012-10-31 Thread Mark Rotteveel
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

2012-10-31 Thread Alex Peshkoff
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

2012-10-31 Thread Pavel Cisar


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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Pavel Cisar


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

2012-10-31 Thread Poul Dige
 
 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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Thomas Steinmaurer
 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

2012-10-31 Thread Thomas Steinmaurer
 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

2012-10-31 Thread Pavel Cisar


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

2012-10-31 Thread Alex Peshkoff
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

2012-10-31 Thread Lester Caine
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

2012-10-31 Thread Adriano dos Santos Fernandes
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

2012-10-31 Thread marius adrian popa
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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Ann Harrison
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

2012-10-31 Thread Adriano dos Santos Fernandes
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

2012-10-31 Thread Dmitry Yemanov
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

2012-10-31 Thread Александр Пешков

   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

2012-10-31 Thread Adriano dos Santos Fernandes
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

2012-10-31 Thread Leyne, Sean


 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