C-u 66 C-x f M-q

diff --git a/CHANGES b/CHANGES
index 78112999c1e8451ab9c3f2dfe89ad2c73dcbc955..e2947f0f30eb6707f333102813d01b0f1f608ac9 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -1,50 +1,54 @@
 =======
 CHANGES
 =======
+
 0.4.4
 ------
 - sql
-    - can again create aliases of selects against textual
-      FROM clauses, [ticket:975]
-    - the value of a bindparam() can be a callable, in which 
-      case it's evaluated at statement execution time to
-      get the value.
-      
+    - Can again create aliases of selects against textual FROM
+      clauses, [ticket:975]
+
+    - The value of a bindparam() can be a callable, in which case
+      it's evaluated at statement execution time to get the value.
+
 - orm
     - any(), has(), contains(), attribute level == and != now
       work properly with self-referential relations - the clause
       inside the EXISTS is aliased on the "remote" side to
       distinguish it from the parent table.
-    - your cries have been heard:  removing a pending item
-      from an attribute or collection with delete-orphan 
-      expunges the item from the session; no FlushError is raised.  
-      Note that if you session.save()'ed the pending item 
-      explicitly, the attribute/collection removal still knocks 
-      it out.
-    - fixed potential generative bug when the same Query was
-      used to generate multiple Query objects using join().
-    - added a new "higher level" operator called "of_type()" - 
-      used in join() as well as with any() and has(), qualifies
-      the subclass which will be used in filter criterion, 
-      e.g.: 
-      
+
+    - Your cries have been heard: removing a pending item from an
+      attribute or collection with delete-orphan expunges the item
+      from the session; no FlushError is raised.  Note that if you
+      session.save()'ed the pending item explicitly, the
+      attribute/collection removal still knocks it out.
+
+    - Fixed potential generative bug when the same Query was used
+      to generate multiple Query objects using join().
+
+    - Added a new "higher level" operator called "of_type()": used
+      in join() as well as with any() and has(), qualifies the
+      subclass which will be used in filter criterion, e.g.:
+
         query.filter(Company.employees.of_type(Engineer).
-          any(Engineer.name=='foo')), 
-      
+          any(Engineer.name=='foo'))
+
+        or
+
         query.join(Company.employees.of_type(Engineer)).
           filter(Engineer.name=='foo')
 
-      - preventive code against a potential lost-reference 
-        bug in flush()
-      - expressions used in filter(), filter_by() and others,
-        when they make usage of a clause generated from a
-        relation using the identity of a child object
-        (e.g. filter(Parent.child==<somechild>)), evaluate
-        the actual primary key value of <somechild> at 
-        execution time so that the autoflush step of the
-        Query can complete, thereby populating the PK value
-        of <somechild> in the case that <somechild> was
-        pending.
+      - Preventive code against a potential lost-reference bug in
+        flush().
+
+      - Expressions used in filter(), filter_by() and others, when
+        they make usage of a clause generated from a relation
+        using the identity of a child object
+        (e.g. filter(Parent.child==<somechild>)), evaluate the
+        actual primary key value of <somechild> at execution time
+        so that the autoflush step of the Query can complete,
+        thereby populating the PK value of <somechild> in the case
+        that <somechild> was pending.
 
 0.4.3
 ------