X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FStorage%2FDBI%2FMSSQL.pm;h=fedec7fa423533f1b36c0e65a3d61ee765b92f96;hb=0777ad33930b2c09258f9752e4e76c27ca75f347;hp=2db2af7fbad59f277773c47131659cbcb574f7b9;hpb=edbb5df16458258554431bddb3b4df98a526999d;p=dbsrgits%2FDBIx-Class.git diff --git a/lib/DBIx/Class/Storage/DBI/MSSQL.pm b/lib/DBIx/Class/Storage/DBI/MSSQL.pm index 2db2af7..fedec7f 100644 --- a/lib/DBIx/Class/Storage/DBI/MSSQL.pm +++ b/lib/DBIx/Class/Storage/DBI/MSSQL.pm @@ -3,7 +3,7 @@ package DBIx::Class::Storage::DBI::MSSQL; use strict; use warnings; -use base qw/DBIx::Class::Storage::DBI::AmbiguousGlob DBIx::Class::Storage::DBI/; +use base qw/DBIx::Class::Storage::DBI/; use mro 'c3'; use List::Util(); @@ -178,6 +178,33 @@ sub _execute { sub last_insert_id { shift->_identity } +# +# MSSQL is retarded wrt ordered subselects. One needs to add a TOP +# to *all* subqueries, but one also can't use TOP 100 PERCENT +# http://sqladvice.com/forums/permalink/18496/22931/ShowThread.aspx#22931 +# +sub _select_args_to_query { + my $self = shift; + + my ($sql, $prep_bind, @rest) = $self->next::method (@_); + + # see if this is an ordered subquery + my $attrs = $_[3]; + if ( scalar $self->_parse_order_by ($attrs->{order_by}) ) { + $self->throw_exception( + 'An ordered subselect encountered - this is not safe! Please see "Ordered Subselects" in DBIx::Class::Storage::DBI::MSSQL + ') unless $attrs->{unsafe_subselect_ok}; + my $max = 2 ** 32; + $sql =~ s/^ \s* SELECT \s/SELECT TOP $max /xi; + } + + return wantarray + ? ($sql, $prep_bind, @rest) + : \[ "($sql)", @$prep_bind ] + ; +} + + # savepoint syntax is the same as in Sybase ASE sub _svp_begin { @@ -205,14 +232,35 @@ sub build_datetime_parser { sub sqlt_type { 'SQLServer' } -sub _sql_maker_opts { - my ( $self, $opts ) = @_; +sub _get_mssql_version { + my $self = shift; + + my $data = $self->_get_dbh->selectrow_hashref('xp_msver ProductVersion'); - if ( $opts ) { - $self->{_sql_maker_opts} = { %$opts }; + if ($data->{Character_Value} =~ /^(\d+)\./) { + return $1; + } else { + $self->throw_exception(q{Your ProductVersion's Character_Value is missing or malformed!}); } +} + +sub sql_maker { + my $self = shift; - return { limit_dialect => 'Top', %{$self->{_sql_maker_opts}||{}} }; + unless ($self->_sql_maker) { + unless ($self->{_sql_maker_opts}{limit_dialect}) { + my $version = eval { $self->_get_mssql_version; } || 0; + + $self->{_sql_maker_opts} = { + limit_dialect => ($version >= 9 ? 'RowNumberOver' : 'Top'), + %{$self->{_sql_maker_opts}||{}} + }; + } + + my $maker = $self->next::method (@_); + } + + return $self->_sql_maker; } 1; @@ -260,6 +308,54 @@ $table_name ON>. Unfortunately this operation in MSSQL requires the C privilege, which is normally not included in the standard write-permissions. +=head2 Ordered Subselects + +If you attempted the following query (among many others) in Microsoft SQL +Server + + $rs->search ({}, { + prefetch => 'relation', + rows => 2, + offset => 3, + }); + +You may be surprised to receive an exception. The reason for this is a quirk +in the MSSQL engine itself, and sadly doesn't have a sensible workaround due +to the way DBIC is built. DBIC can do truly wonderful things with the aid of +subselects, and does so automatically when necessary. The list of situations +when a subselect is necessary is long and still changes often, so it can not +be exhaustively enumerated here. The general rule of thumb is a joined +L relationship with limit/group +applied to the left part of the join. + +In its "pursuit of standards" Microsft SQL Server goes to great lengths to +forbid the use of ordered subselects. This breaks a very useful group of +searches like "Give me things number 4 to 6 (ordered by name), and prefetch +all their relations, no matter how many". While there is a hack which fools +the syntax checker, the optimizer may B. +Testing has determined that while such breakage does occur (the test suite +contains an explicit test which demonstrates the problem), it is relative +rare. The benefits of ordered subselects are on the other hand too great to be +outright disabled for MSSQL. + +Thus compromise between usability and perfection is the MSSQL-specific +L C. +It is deliberately not possible to set this on the Storage level, as the user +should inspect (and preferrably regression-test) the return of every such +ResultSet individually. The example above would work if written like: + + $rs->search ({}, { + unsafe_subselect_ok => 1, + prefetch => 'relation', + rows => 2, + offset => 3, + }); + +If it is possible to rewrite the search() in a way that will avoid the need +for this flag - you are urged to do so. If DBIC internals insist that an +ordered subselect is necessary for an operation, and you believe there is a +differnt/better way to get the same result - please file a bugreport. + =head1 AUTHOR See L.