Fix typos, closing #89, #91, #92

diff --git a/doc/build/content/sqlconstruction.myt b/doc/build/content/sqlconstruction.myt
index 065ef2bcc89d57c5cfffd4c010b5dfb27c99b3d4..d674e2be1eed3bc42a52ddf5ec3ccdbfb6d68ab5 100644 (file)
--- a/doc/build/content/sqlconstruction.myt
+++ b/doc/build/content/sqlconstruction.myt
@@ -582,7 +582,7 @@ FROM addresses,
                 s = select([users.c.user_id], users.c.user_name.like('p%'))
             
                 # now select all addresses for those users
-                <&formatting.myt:poplink&>addresses.select(addresses.c.address_id.in_(s)).execute()
+                <&formatting.myt:poplink&>addresses.select(addresses.c.user_id.in_(s)).execute()
 <&|formatting.myt:codepopper, link="sql" &>
 SELECT addresses.address_id, addresses.user_id, addresses.street, 
 addresses.city, addresses.state, addresses.zip
@@ -901,9 +901,9 @@ INSERT INTO users (user_name, password) VALUES (:name, :pw)
             # the generated SQL of the insert (i.e. what columns are present)
             # executemany() is used at the DBAPI level
             <&formatting.myt:poplink&>users.insert().execute(
-                {'user_id':7, 'user_name':'jack', 'password':'asdfasdf'}
-                {'user_id':8, 'user_name':'ed', 'password':'asdffcadf'}
-                {'user_id':9, 'user_name':'fred', 'password':'asttf'}
+                {'user_id':7, 'user_name':'jack', 'password':'asdfasdf'},
+                {'user_id':8, 'user_name':'ed', 'password':'asdffcadf'},
+                {'user_id':9, 'user_name':'fred', 'password':'asttf'},
             )
 <&|formatting.myt:codepopper, link="sql" &>
 INSERT INTO users (user_id, user_name, password) 

diff --git a/doc/build/content/unitofwork.myt b/doc/build/content/unitofwork.myt
index 967dc4f7db3cf695561f6b1b3f50b35d5c33c607..3833e9a228d2b4229cbe0a9b8cd1a8050e2225da 100644 (file)
--- a/doc/build/content/unitofwork.myt
+++ b/doc/build/content/unitofwork.myt
@@ -109,7 +109,7 @@
     </&>
     </&>
     <&|doclib.myt:item, name="identity", description="The Identity Map" &>
-    <p>All object instances which are saved to the database, or loaded from the database, are given an identity by the mapper/objectstore.  This identity is available via the _identity_key property attached to each object instance, and is a tuple consisting of the table's class, the SQLAlchemy-specific "hash key" of the table its persisted to, and an additional tuple of primary key values, in the order that they appear within the table definition:</p>
+    <p>All object instances which are saved to the database, or loaded from the database, are given an identity by the mapper/objectstore.  This identity is available via the _instance_key property attached to each object instance, and is a tuple consisting of the table's class, the SQLAlchemy-specific "hash key" of the table its persisted to, and an additional tuple of primary key values, in the order that they appear within the table definition:</p>
     <&|formatting.myt:code&>
         >>> obj._instance_key 
         (<class 'test.tables.User'>, "Table('users',SQLiteSQLEngine(([':memory:'], {})),schema=None)", (7,))
@@ -155,7 +155,7 @@
     </&>
     </&>
     <&|doclib.myt:item, name="import", description="Bringing External Instances into the UnitOfWork" &>
-    <p>The _identity_key attribute is designed to work with objects that are serialized into strings and brought back again.  As it contains no references to internal structures or database connections, applications that use caches or session storage which require serialization (i.e. pickling) can store SQLAlchemy-loaded objects.  However, as mentioned earlier, an object with a particular database identity is only allowed to exist uniquely within the current unit-of-work scope.  So, upon deserializing such an object, it has to "check in" with the current unit-of-work/identity map combination, to insure that it is the only unique instance.  This is achieved via the <span class="codeline">import_instance()</span> function in objectstore:</p>
+    <p>The _instance_key attribute is designed to work with objects that are serialized into strings and brought back again.  As it contains no references to internal structures or database connections, applications that use caches or session storage which require serialization (i.e. pickling) can store SQLAlchemy-loaded objects.  However, as mentioned earlier, an object with a particular database identity is only allowed to exist uniquely within the current unit-of-work scope.  So, upon deserializing such an object, it has to "check in" with the current unit-of-work/identity map combination, to insure that it is the only unique instance.  This is achieved via the <span class="codeline">import_instance()</span> function in objectstore:</p>
     <&|formatting.myt:code&>
         # deserialize an object
         myobj = pickle.loads(mystring)
@@ -164,7 +164,7 @@
         # identity map, then you get back the one from the current session.
         myobj = objectstore.import_instance(myobj)
     </&>
-<p>Note that the import_instance() function will either mark the deserialized object as the official copy in the current identity map, which includes updating its _identity_key with the current application's class instance, or it will discard it and return the corresponding object that was already present.</p>
+<p>Note that the import_instance() function will either mark the deserialized object as the official copy in the current identity map, which includes updating its _instance_key with the current application's class instance, or it will discard it and return the corresponding object that was already present.</p>
     </&>
 
     <&|doclib.myt:item, name="advscope", description="Advanced UnitOfWork Management"&>