Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34251
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain openlinksw.com from 194.109.164.61 cause and error)
In-Reply-To: <1198612449.20516.65.camel@johannes.nop>
References: <476AAC30.1080200@openlinksw.com> <1198182770.20516.29.camel@johannes.nop>  <476AD553.3040103@openlinksw.com> <1198612449.20516.65.camel@johannes.nop>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <49DDEE45-46B4-488A-8AB5-8C61DB753969@openlinksw.com>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Wed, 26 Dec 2007 01:00:01 +0100
To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>
Subject: Re: [PHP-DEV] Re: Fixed and enhancements for php odbc layer
From: iodbc@openlinksw.com (Patrick van Kleef)

Hi Johannes,

>
>> I have attached 3 diffs as txt files. Each of the files start with a
>> short explanation of what the patch is supposed to do, so it is  
>> easier
>> for anyone else to see what i did.
>
> Tanks, I don't see a problem with these patches, while I don't really
> know ODBC. But three comments:
>
> - In general we try to avoid adding new ini settings, in general
>   they just make life harder, can't these made connection or query
>   flags?

Not easily with the current code i think. I did not want to add  
another API function as this causes much more debate and  
compatibility issues.

The current PHP code hardcodes a dynamic cursor for drivers that can  
handle this. If not then normally the cursor downgrades to a static  
cursor which happens with most of the open source drivers. But some  
of the more advanced drivers are penalised by this behaviour as a  
dynamic cursor is a lot slower than a static cursor. Most  
applications do not need a full dynamic cursor to begin with as they  
go over the record set only once. So this patch just levels the  
playing field while still making sure that very advanced apps can use  
a dynamic cursor if they choose so.


> - The update for "current versions of iODBC": How new is this new
>   version? (Or other way round: how likely will a system break?)
>   Can old versions be detected and rejected from config.m4?
>

The current php code does not enable functionality like  
SQLDriverConnect when using the iODBC driver manager. This function  
has been part of the iODBC driver manager since its first publication  
more than 9 years ago, and creates a nasty incompatibility
between various driver managers. Same goes for the use of  
SQLExtendedFetch.

The result of this is that PHP applications that are written using  
the php odbc_connect code work differently when PHP is compiled on  
Windows or on Unix using iODBC whereas the whole point of the ODBC  
API itself is to be a cross platform solution for data access.


> - I hope these stuff won't break with other odbc flavors :-)

Not that i am aware of, as all ODBC driver managers currently  
implement these types and features and have done so for at least 3 to  
4 years.

If there are libraries that use an ODBC like api but do not have the  
SQLLEN type etc, they cannot be used on 64bit Windows and 64bit Unix  
to begin with, but for 32bit we can just add something like:

	#ifndef SQLLEN
	#define SQLLEN	long
	#endif

towards the end of php_odbc_includes.h to make them work.


>> All three diffs have been made against the PHP_5_2 branch of your CVS
>> tree and should be applied within the ext/odbc directory. Since i cut
>> them in pieces for easy reading, you can expect some warnings about
>> lines, but i checked and all three patches combine fine.
>
> PHP_5_2 is the stable branch, new features should go to HEAD and
> PHP_5_3, while I don't expect big problems with merging these.

I am also in contact with Dan Kalowsky the current maintainer of the  
ext/odbc code and
i leave it up to him to recommend which version can be patches.

Of course i would like to see these patches be adopted as soon as  
possible into the mainstream.



>> If there is any problem, please let me know as i am keen to get  
>> this to
>> work properly.
>>
>> Additionally if there is a list of TODO items for this module, i  
>> will be
>> happy to see if i or my team can be of assistance.
>
> There's no specific todo (I know off) but you might take a look at the
> bug reports, see
> http://bugs.php.net/search.php? 
> boolean=1&limit=20&cmd=display&status=Open&bug_type%5B%5D=ODBC 
> +related for a start.

I will certainly have a look at the list and see what i can do.


Patrick


---
Patrick van Kleef
Maintainer iODBC
OpenLink Software

Web: <http://www.iodbc.org>