X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FStorage%2FDBI%2FMSSQL.pm;h=03311809716199c340e4b50580aca2428445caf7;hb=010f82a001cea2c6067fd8a080e29eb3310c2ecb;hp=178a0079698d8b39457b41978b7d4c78742104bb;hpb=e74c68ce64d8fd3c4838ebd8de8d5b580167fa08;p=dbsrgits%2FDBIx-Class.git diff --git a/lib/DBIx/Class/Storage/DBI/MSSQL.pm b/lib/DBIx/Class/Storage/DBI/MSSQL.pm index 178a007..0331180 100644 --- a/lib/DBIx/Class/Storage/DBI/MSSQL.pm +++ b/lib/DBIx/Class/Storage/DBI/MSSQL.pm @@ -191,6 +191,9 @@ 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}) ) { + $self->throw_exception( + 'An ordered subquery encountered. Please see "Ordered Subqueries" in DBIx::Class::Storage::DBI::MSSQL + ') unless $attrs->{unsafe_subquery}; my $max = 2 ** 32; $sql =~ s/^ \s* SELECT \s/SELECT TOP $max /xi; } @@ -305,6 +308,45 @@ $table_name ON>. Unfortunately this operation in MSSQL requires the C privilege, which is normally not included in the standard write-permissions. +=head2 Ordered Subqueries + + # this is deemed unsafe and throws under MSSQL + $rs->search ({}, { + prefetch => 'relation', + rows => 2, + offset => 3, + }); + + # however this should work (but please check what comes back from the db) + $rs->search ({}, { + unsafe_subquery => 1, + prefetch => 'relation', + rows => 2, + offset => 3, + }); + +DBIC can do truly wonderful things with the aid of subqueries, and does so +automatically when necessary. Especially useful are ordered subqueries, +which allow searches like "Give me things number 4 to 6 (ordered by name), and +prefetch all their relations, no matter how many". In its pursuit of standards +Microsft SQL Server goes to great lengths to forbid the use of ordered +subqueries. 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 +subqueries 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. + +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 subquery 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.