very trivial doc changes

documentation/src/main/asciidoc/introduction/Interacting.adoc

@@ -392,7 +392,7 @@ Hibernate.initialize(book.getAuthors());  // fetch the Authors
 But of course, this code is very inefficient, requiring two trips to the database to obtain data that could in principle be retrieved with just one query.
 
 It's clear from the discussion above that we need a way to request that an association be _eagerly_ fetched using a database `join`, thus protecting ourselves from the infamous N+1 selects.
-One way to do that is by passing an `EntityGraph` to `find()`.
+One way to do this is by passing an `EntityGraph` to `find()`.
 
 [[entity-graph]]
 === Entity graphs and eager fetching
@@ -708,7 +708,7 @@ Here, as before, the classes `Book_` and `Author_` are generated by Hibernate's
 [NOTE]
 // .Injection attacks and criteria queries
 ====
-Notice that we did not bother treating `titlePattern` and `namePattern` as parameters.
+Notice that we didn't bother treating `titlePattern` and `namePattern` as parameters.
 That's safe because, by default, Hibernate automatically and transparently treats strings passed to the `CriteriaBuilder` as JDBC parameters.
 ====
 
@@ -762,7 +762,7 @@ We do.
 [[criteria-definition]]
 === A more comfortable way to write criteria queries
 
-Actually, what makes the JPA criteria API less ergonomic that it should be is the need to call all operations of the `CriteriaBuilder` as instance methods, instead of having them as `static` functions.
+Actually, what makes the JPA criteria API less ergonomic than it should be is the need to call all operations of the `CriteriaBuilder` as instance methods, instead of having them as `static` functions.
 The reason it works this way is that each JPA provider has its own implementation of `CriteriaBuilder`.
 
 // [%unbreakable]