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=be1c3992a3d56d5078c5a62e31ea1884ff42dc2f;hpb=2dde7fb770ab920c186ed18db544f6e76f90c8b3;p=dbsrgits%2FDBIx-Class.git diff --git a/lib/DBIx/Class/Storage/DBI/MSSQL.pm b/lib/DBIx/Class/Storage/DBI/MSSQL.pm index be1c399..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(); @@ -179,8 +179,9 @@ sub _execute { sub last_insert_id { shift->_identity } # -# MSSQL is retarded wrt ordered subselects. One needs to add a TOP 100% -# to *all* subqueries, do it here. +# 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; @@ -189,8 +190,12 @@ sub _select_args_to_query { # see if this is an ordered subquery my $attrs = $_[3]; - if ( scalar $self->sql_maker->_order_by_chunks ($attrs->{order_by}) ) { - $sql =~ s/^ \s* SELECT \s/SELECT TOP 100 PERCENT /xi; + 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 @@ -235,23 +240,27 @@ sub _get_mssql_version { if ($data->{Character_Value} =~ /^(\d+)\./) { return $1; } else { - $self->throw_exception(q{your MSSQL server doesn't have a version!}); + $self->throw_exception(q{Your ProductVersion's Character_Value is missing or malformed!}); } } -sub _sql_maker_opts { - my ( $self, $opts ) = @_; +sub sql_maker { + my $self = shift; - if ( $opts ) { - $self->{_sql_maker_opts} = { %$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 $version = $self->_get_mssql_version; + my $maker = $self->next::method (@_); + } - return { - limit_dialect => ($version >= 9 ? 'RowNumberOver' : 'Top'), - %{$self->{_sql_maker_opts}||{}} - }; + return $self->_sql_maker; } 1; @@ -299,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.