Changes and typos

diff --git a/Changes b/Changes
index 483985f..73b8c8a 100644 (file)
--- a/Changes
+++ b/Changes
@@ -13,6 +13,10 @@ Revision history for DBIx::Class
         - 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)

diff --git a/lib/DBIx/Class/Storage/DBI/MSSQL.pm b/lib/DBIx/Class/Storage/DBI/MSSQL.pm
index ea1269a..0331180 100644 (file)
--- a/lib/DBIx/Class/Storage/DBI/MSSQL.pm
+++ b/lib/DBIx/Class/Storage/DBI/MSSQL.pm
@@ -327,8 +327,8 @@ write-permissions.
 
 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 @@ 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 way to express the query - please file a bugreport.
+differnt/better way to get the same result - please file a bugreport.
 
 =head1 AUTHOR