New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Current Firebird Driver #201

Closed
lsces opened this Issue Feb 19, 2016 · 31 comments

Comments

Projects
None yet
3 participants
@lsces
Copy link
Contributor

lsces commented Feb 19, 2016

Having been running ADOdb on various projects for coming up on 15 years, it's nice to see some more people developing with it. I have always made the driver available, and the current patch against ADOdb is here http://hg.lsces.org.uk/bw/bitweaver/externals/adodb/rev/b4efbd3bfe07 which in theory I can push over if acceptable.

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Feb 19, 2016

Thanks, that would be great, @dregad , who is currently on holiday, will organize it soon. Our knowledge of firebird is poor, can you shed any light on the current status of firebird as discussed here?

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 19, 2016

The interbase driver in php still works with firebird, but there are a few variations between the current versions of interbase and firebird which may well require forking the two at some point. There are already aliases for the functions so the ADOdb firebird driver has used used fbird_xxx rather than ibase_ since PHP5 came out. Firebird has a heavy international following mainly in the Delphi developer market and a substantial number of heavy systems users have ported from oracle over to firebird to remove licensing costs. In PHP circles it's use is less common, but it does provide a much cleaner way of running regular backups and since the data is fully contained in a single file rsync back to a mirror is a doddle.

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Feb 19, 2016

Interesting, so you're saying this Firebird driver would definitely not work on ibase. Also, have you had a chance to test it with PHP 7

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 19, 2016

http://php7.lsces.org.uk/ ... but it's on a slowish pipe. My main machines are still on PHP5.4 and PHP5.2, but PHP5.6 is on http://php6.lsces.org.uk/ and http://lsces.org.uk/ has 5.4. All three are running the same code ...

Interbase has added different extensions to the sql to those added by firebird, so the things like 'SelectLimit' are slightly different in the firebird driver and how sequences/generators are handled.

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Feb 19, 2016

So if we were to place it in ADOdb version 5.21, which will be released as 5.21-alpha-0.0, and named it as say 'firebird2' (or possibly firebird3 with the upcoming release), would you think that reasonable?

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 20, 2016

On 19/02/16 23:13, Mark Newnham wrote:

So if we were to place it in ADOdb version 5.21, which will be released
as 5.21-alpha-0.0, and named it as say 'firebird2' (or possibly
firebird3 with the upcoming release), would you think that reasonable?

Well in my book, the existing firebird driver is of little use since it
does not have facilities such as affectedrows and the control of
generators I don't think works so we have always supplied the alternate
driver as the supported version.

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

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Feb 20, 2016

So you would recommend simply replacing the existing driver. I notice that firebird extends ibase in the current system. Is that the case in your version?

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 20, 2016

On 20/02/16 13:29, Mark Newnham wrote:

So you would recommend simply replacing the existing driver. I notice
that firebird extends ibase in the current system. Is that the case in
your version?

16 years ago when Firebird was made open source the code base was
virtually identical. Nowadays there are enough differences that it's
safer to split them, and as I say, the fbird_ set of functions would
benefit forking the driver as well in PHP allowing Firebird specific
enhancements to be picked up.

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

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Feb 20, 2016

Perhaps my question was ambiguous: At this point, the class ADODB_firebird extends ADODB_ibase. In your version, is the ibase class still the same, or have you modified that as well.

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 20, 2016

My driver ignores ibase, and could be loaded in addition to the current version, but basically the old driver is NOT fully operational with modern versions of Firebird and there is little point trying to bring it up to date.

Sent from my android device so quoting is crap ... need to kill these painful email clients!

-----Original Message-----
From: Mark Newnham notifications@github.com
To: ADOdb/ADOdb ADOdb@noreply.github.com
Cc: Lester Caine lester@lsces.co.uk
Sent: Sat, 20 Feb 2016 18:14
Subject: Re: [ADOdb] Current Firebird Driver (#201)

Perhaps my question was ambiguous: At this point, the class ADODB_firebird extends ADODB_ibase. In your version, is the ibase class still the same, or have you modified that as well.


Reply to this email directly or view it on GitHub:
#201 (comment)

@dregad

This comment has been minimized.

Copy link
Member

dregad commented Feb 22, 2016

@dregad , who is currently on holiday, will organize it soon

@mnewnham I'm back, but I'm not really sure what I'm meant to organize...

Anyway, looking at the discussion and considering the state of the current firebird driver as @lsces describes it, replacing the existing firebase driver sounds like the right way to go.

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Feb 22, 2016

@dregad , just to pull the code, with the appropriate commit descriptions

@dregad

This comment has been minimized.

Copy link
Member

dregad commented Feb 23, 2016

the ADOdb firebird driver has used used fbird_xxx rather than ibase_ since PHP5 came out.

@lsces sorry if I'm asking a stupid question, but I can't find a reference in PHP documentation or on Google for the fbird_xxx functions that are used in your code. Current ADOdb does not have any reference to them either. Am I missing something ?

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 23, 2016

On 23/02/16 08:49, Damien Regad wrote:

the ADOdb firebird driver has used used fbird_xxx rather than ibase_
since PHP5 came out.

@lsces https://github.com/lsces sorry if I'm asking a stupid question,
but I can't find a reference in PHP documentation or on Google for the
|fbird_xxx| functions that are used in your code. Current ADOdb does not
have any reference to them either. Am I missing something ?

http://git.php.net/?p=php-src.git;a=blob;f=ext/interbase/interbase.c;h=b4c253838e7e60428ae6946280702671c17eb014;hb=HEAD

line 380 on ...

But you are right that 'someone' has tidied the information out of the
php manual :( I'm convinced there used to be a section about it, but the
restructuring over the years has lost a LOT of useful data which people
have 'tidied up'.

http://www.janus-software.com/fbmanual/index.php?book=php is an
alternative manual and is more 'firebird orientated' on transactions,
but having used ADOdb for so long, I've only worked direct in the driver
when something has got broken on the php end.

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

@dregad

This comment has been minimized.

Copy link
Member

dregad commented Feb 23, 2016

Thanks for the feedback.

'someone' has tidied the information out of the php manual :(

Hopefully 'someone' will fix it now 😉
https://bugs.php.net/bug.php?id=71650

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 23, 2016

On 23/02/16 13:55, Damien Regad wrote:

Thanks for the feedback.

'someone' has tidied the information out of the php manual :(

Hopefully 'someone' will fix it now 😉
https://bugs.php.net/bug.php?id=71650

We keep discussing forking the a Firebird version of the PHP driver, but
since most of the interface is generic, there has not been a real need.
With Firebird 3 well overdue, it may well benefit from a more targeted
driver, but with some of us still happily running FB1.5 on client sites
there is no pressing need to keep changing things. Firebird had SQL 15
years ago that MySQL is only just thinking about adding, and accessing
the results has not changed.

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

@dregad

This comment has been minimized.

Copy link
Member

dregad commented Feb 24, 2016

Considering that adodb_error_firebird() returns the exact same mapping as adodb_error_ibase(), wouldn't it make sense in the interest of reducing code duplication and memory footprint, to simply have it return adodb_error_ibase(); instead of redefining the array ?

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 24, 2016

On 24/02/16 09:18, Damien Regad wrote:

Considering that |adodb_error_firebird()| returns the exact same mapping
as |adodb_error_ibase()|, wouldn't it make sense in the interest of
reducing code duplication and memory footprint, to simply have it
|return adodb_error_ibase();| instead of redefining the array ?

I've been doing that for many years, but decided that I need to actually
start work on enhancing that side of things. Personally I think that
this is an area that needs more work in general. I ONLY run Firebird on
production machines so don't need any of the other driver error codes
and have trimmed the whole file in the past :)

There are a number of new codes some of which could well be added to
both lists, but I'm only hooked up with the firebird development
process. This area is only really about providing translated versions of
the error text, and most of the time defaulting back to english is
adequate ( it's all I read ), but improving international support is
something I'm only too happy to help with.

http://www.firebirdsql.org/file/documentation/reference_manuals/fblangref25-en/html/fblangref25-appx02-sqlcodes.html
does throw a spanner in the works with the statement that the SQLCODE
may be dropped in future so the whole thing will need reworking anyway.
THAT will be a Firebird developers decision which I will object to, but
is the sort of agro we seem to have to put up with on every project
these days?

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

@dregad

This comment has been minimized.

Copy link
Member

dregad commented Feb 24, 2016

I guess that means the answer to my question is NO ? 😉

@dregad dregad added this to the v5.21 milestone Feb 24, 2016

@dregad dregad self-assigned this Feb 24, 2016

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 24, 2016

Maybe ...
I'm not currently bothered either way, but am currently working on an extended list, and I will cross check with interbase.

Sent from my android device so quoting is crap ... need to kill these painful email clients!

-----Original Message-----
From: Damien Regad notifications@github.com
To: ADOdb/ADOdb ADOdb@noreply.github.com
Cc: Lester Caine lester@lsces.co.uk
Sent: Wed, 24 Feb 2016 12:41
Subject: Re: [ADOdb] Current Firebird Driver (#201)

I guess that means the answer to my question is NO ? 😉


Reply to this email directly or view it on GitHub:
#201 (comment)

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 25, 2016

OK seems that the error handling side of things needs a far bigger overhaul going back to the PHP driver itself. Currently we are using the 'SQLCODE' values which has been deprecated in the SQL standard and replaced by 'SQLSTATE' which is currently used in the odbc error handler and should be standard across all sql databases ;) I'm currently looking once again at switching the fbird_ function set to return the newer code set as SQLCODE will be dropped from a later version of Firebird. The question is if there should currently be a switch to return one or the other at the driver level.
Currently I'm quite happy that we simply add 'firebird' case to the 'interbase on in adodb-error.inc.php as we know what is going on and I think that this will be expanded in general with extra generic error codes linked to the more modern SQLSTATE errors.

@dregad

This comment has been minimized.

Copy link
Member

dregad commented Feb 25, 2016

he question is if there should currently be a switch to return one or the other at the driver level.

Do you mean the ADOdb driver, or the PHP one ?

Currently I'm quite happy that we simply add 'firebird' case

OK then. Will make the change.

@dregad dregad closed this in 041acbb Feb 26, 2016

dregad added a commit that referenced this issue Feb 26, 2016

Firebird driver uses ibase error mappings
This amends previous commit by removing the firebase-specific mapping
which was just a copy/paste of the ibase one, as discussed in
#201 (comment)

Issue #201
@dregad

This comment has been minimized.

Copy link
Member

dregad commented Feb 26, 2016

@lsces let me know if the way I committed this is OK with you.

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Feb 26, 2016

On 26/02/16 10:59, Damien Regad wrote:

@lsces https://github.com/lsces let me know if the way I committed
this is OK with you.

Looking good ... merged with my copy OK ;)

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

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Mar 27, 2016

@lsces , how are you getting on with this?

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Mar 27, 2016

I'm running a version of ADOdb on all my servers now rather than the ported builds and everything seems fine. Not sure about the metaObject stuff as yet. A quick check did not work but I don't have time to investigate. The usual problem in the datadict is Firebird follows the SQL standard for NOT NULL DEFAULT ordering and other database don't.

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Mar 27, 2016

Not sure about the metaObject stuff as yet

This is all prototype right now

The usual problem in the datadict is Firebird follows the SQL standard for NOT NULL DEFAULT ordering and other database don't.

Could you be more specific about this?

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Mar 27, 2016

Quick answer is https://sourceforge.net/p/firebird/mailman/message/34910643/
As long as ADOdb datadict is used properly the variations are compensated for, but I have had problems in the past where projects 'speed up' schema handling and bypass some of the key elements that get the order right. I've just been converting another set of code where the only way to get the order right was to hand edit the setup data for some 50 tables ... until I could create a clean datadict alternative.
As you will see from the thread, there is no plan to allow both alternatives in Firebird (or Interbase) and I was covering these cross database problems in conference sessions 15 years ago :(

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Mar 28, 2016

Ok, I think I understand this, let me have a think about it.

@lsces

This comment has been minimized.

Copy link
Contributor

lsces commented Mar 28, 2016

Mark ... the first few years after I started using PHP5 starting just after it went to release candidate I was also using ADOdb, and presented papers at a number of conferences on the problems of cross database working. I have no problem cross checking these areas, but time as always is the limiting factor :(

@mnewnham

This comment has been minimized.

Copy link
Contributor

mnewnham commented Mar 28, 2016

Perhaps we need to consider a priority order for column attributes that controls what order they are inserted into the addColumn statement, so for example,

'NOT NULL' = priority 0
'DEFAULT' = priority 1,

So no matter what order they are sent in, they will always be appended in the correct order

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment