[Bast-commits] r8269 - in DBIx-Class/0.08/branches/mssql_limit_regression: . lib/DBIx/Class/Storage/DBI

[ribasushi at dev.catalyst.perl.org]

Author: ribasushi
Date: 2010-01-09 10:36:36 +0000 (Sat, 09 Jan 2010)
New Revision: 8269

Modified:
   DBIx-Class/0.08/branches/mssql_limit_regression/Changes
   DBIx-Class/0.08/branches/mssql_limit_regression/lib/DBIx/Class/Storage/DBI/MSSQL.pm
Log:
Changes and typos

Modified: DBIx-Class/0.08/branches/mssql_limit_regression/Changes
===================================================================
--- DBIx-Class/0.08/branches/mssql_limit_regression/Changes	2010-01-09 10:26:46 UTC (rev 8268)
+++ DBIx-Class/0.08/branches/mssql_limit_regression/Changes	2010-01-09 10:36:36 UTC (rev 8269)
@@ -13,6 +13,10 @@
         - Fix regression in context sensitiveness of deployment_statements
         - Fix regression resulting in overcomplicated query on
           search_related from prefetching resultsets
+        - Better isolation of RNO-limited queries from the rest of a
+          prefetching resultset
+        - New MSSQL specific resultset attribute to allow hacky ordered
+          subquery suppot
 
 0.08115 2009-12-10 09:02:00 (CST)
         - Real limit/offset support for MSSQL server (via Row_Number)

Modified: DBIx-Class/0.08/branches/mssql_limit_regression/lib/DBIx/Class/Storage/DBI/MSSQL.pm
===================================================================
--- DBIx-Class/0.08/branches/mssql_limit_regression/lib/DBIx/Class/Storage/DBI/MSSQL.pm	2010-01-09 10:26:46 UTC (rev 8268)
+++ DBIx-Class/0.08/branches/mssql_limit_regression/lib/DBIx/Class/Storage/DBI/MSSQL.pm	2010-01-09 10:36:36 UTC (rev 8269)
@@ -327,8 +327,8 @@
 
 DBIC can do truly wonderful things with the aid of subqueries, and does so
 automatically when necessary. Especially useful are ordered subqueries,
-which allow things like "Give me things number 4 to 6 (ordered by name), and
-prefetch all their relationss, no matter how many". In its pursuit of standards
+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<still elect to break the subquery>. Testing has determined that while
@@ -345,7 +345,7 @@
 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 way to express the query - please file a bugreport.
+differnt/better way to get the same result - please file a bugreport.
 
 =head1 AUTHOR