Re: [fw-db] Comments on Zend_Db_Adapter_Sqlsrv

Ralph Schindler-2 wrote:
>
> Andrew, thanks for the detailed input!
>
>
>> Zend_Db_Adapter_Sqlsrv
>> 1) I see some references to Oracle and things like tnsnames.ora still in
>> the
>> comments.
>
> I will remove these pronto. Sounds like I need to really read the
> comments that are in there instead of speed-reading them :)
>

I'll admit I spotted them pretty quickly simply because the differences were
highlighted when I ran WinMerge to compare this class to my own. :-)

Ralph Schindler-2 wrote:
>
>> 2) In _connect(), I think it would be more efficient for the adapter to
>> throw an exception on any driver options that are not supported by the
>> DLL
>> rather than passing them off to sqlsrv_connect() and letting it return an
>> error.
>
> Well, the issue here is that we cant know what constants are valid as
> driver options (I guess we could make a list, but then the adapter would
> have to maintain that list).
>
> The issue is that if we wanted to throw an exception, we'd have to
> supress any errors coming out of sqlsrv_connect() function. Considering
> we dont fully know ALL of the different errors that could be thrown out
> of that function, its probably best to not supress them.
>
> Ideally, if you were using Zend_Config, you would be able to have a
> section such that only the specific driver options for SQL Server
> extension are passed to sqlsrv_connect().
>
> Does that make sense?
>

I just made a coded the options listed here into an array:
http://msdn.microsoft.com/en-us/library/cc296161%28SQL.90%29.aspx

Personally, to maintain portability I think I'd prefer simply ignoring
values other than these over raising exceptions. I realize this would mean
that the code would have to be updated every time the list was updated by
Microsoft, but I imagine the current options would be pretty stable over
future releases.

Ralph Schindler-2 wrote:
>
>> 4) The implementation of limit() looks like it uses a pretty common
>> technique I have seen in other algorithms, but I think it contains a
>> slight
>> flaw regarding the last "page" in the result set.
>> ...
>> with CTEs, etc. On large tables, it can be the difference between queries
>> that finish in seconds and queries that finish in hours.)
>
> I guess this is two part. One is that if you think the behavior of
> limit() is wrong, lets try and get a test script going that will produce
> the bad behavior, that way i can unit test it, and also see if we have
> bad logic inside other adapters as well.
>

Really, the only test variable for this issue is the data itself. I guess I
could script out a very simple table that could be used to test against.

Ralph Schindler-2 wrote:
>
> Secondly though, I dont know nearly enough about 2005 and 2008
> differences to be able to say that one method is better than another
> with regards to who limit() works. Perhaps you have a proposal here?
>

I don't from first-hand experience yet either. (We're still using 2000 at
work.) I just offered this based on several discussions I have followed on
the concept of paging recordsets at http://www.sqlservercentral.com.

Ralph Schindler-2 wrote:
>
>> Zend_Db_Statement_Sqlsrv
>> 1) I like the addition of the class constants for the parameter
>> directions.
>> Perhaps the other constants should be added as well? A couple of them
>> probably have to be implemented as static functions, rather than members
>> of
>> that enumeration array though. :-\
>
> Hmm, could you explain a little more here?
>

This page has an enumeration of all the constants provided by the library.
http://msdn.microsoft.com/en-us/library/cc296183%28SQL.90%29.aspx

Whereas all the other db adapters in ZF only accept a 1-dimensional array of
parameters, the Sqlsrv driver accepts an array where any or all of those
parameters can be expanded from a single scalar value to an array of up to 4
elements that describe not only the parameter's value and direction, but
also the PHP datatype, and the SQL Server datatype. It's somewhat
troublesome in that using these pretty much breaks the ability to easily
switch to a different adapter for a different database, but I've had cases
where queries would generate errors if I did not use them.

These are already defined as constants in PHP, but since it's not a core PHP
library they are not included in code completion for editors like Zend
Studio. This is solved by the inclusion of the parameter direction constants
that are already defined in this class, so defining the rest seems
beneficial to me.

Andrew
--
View this message in context: http://www.nabble.com/Comments-on-Zend_Db_Adapter_Sqlsrv-tp24725644p24738002.html
Sent from the Zend DB mailing list archive at Nabble.com.