formatting change

doc/COMMANDS.md

@@ -173,7 +173,8 @@ Path to the optional enums JSON file (generated by your extract-schema call, usu
 Path to your schemas JSON file (generated by extract-schema, usually 'schemas.json').
 
 --strip-prefixes <prefix_list> (optional)
-Set of space-separated prefixes to strip from table names.  So for example, if your table names all start with 'wp_' (ie: 'wp_post'), add 'wp_' here to make your class 'Post' instead of 'WpPost'.
+Set of space-separated prefixes to strip from table names.  So for example, if your table names all 
+start with 'wp_' (ie: 'wp_post'), add 'wp_' here to make your class 'Post' instead of 'WpPost'.
 
 --java-output-dir <path> (required)
 Directory to write the generated class files to.  Usually 'gensrcdko' or similar.
@@ -182,16 +183,26 @@ DO NOT MIX THESE WITH YOUR HAND-WRITTEN CODE!  That will only lead to checking t
 TODO: Your 'build-clean' operation should delete this directory!
 
 --package <package_name> (required)
-The base java package of the generated classes.  For instance, with a base package of 'org.kered.myapp', a schema called 'mydb' and a table 'my_table', the generated class would be 'org.kered.myapp.mydb.MyTable'.
+The base java package of the generated classes.  For instance, with a base package of 
+'org.kered.myapp', a schema called 'mydb' and a table 'my_table', the generated class would be
+'org.kered.myapp.mydb.MyTable'.
 
 --data-source <static_method> (optional, but highly recommended)
-Full path to a static method that will return a DataSource.  For example, 'com.myapp.SomeClass.getDefaultDS()'.  If this is not specified, the datasource needs to be specified some other way.  For example, 'org.kered.dko.Context.getVMContext().setDataSource(someDS).setAutoUndo(false)' will set the default for the entire VM.  Alternatively it can be set per query like 'MyTable.ALL.use(someDS)'.
+Full path to a static method that will return a DataSource.  For example, 'com.myapp.SomeClass.getDefaultDS()'.
+If this is not specified, the datasource needs to be specified some other way.  For example,
+'org.kered.dko.Context.getVMContext().setDataSource(someDS).setAutoUndo(false)' will set the default 
+for the entire VM.  Alternatively it can be set per query like 'MyTable.ALL.use(someDS)'.
 
 --use-detailed-to-string <true|false> (optional; default:false)
-The default toString() implementation wraps toStringSimple() which doesn't show every field, just those it thinks are important for identification.  (Mainly the PK + some column name containing 'name' or 'title'.)  Setting this to true will make toString() wrap toStringDetailed() instead.  Both methods are available on each generated object.
+The default toString() implementation wraps toStringSimple() which doesn't show every field, just 
+those it thinks are important for identification.  (Mainly the PK + some column name containing 
+'name' or 'title'.)  Setting this to true will make toString() wrap toStringDetailed() instead.  
+Both methods are available on each generated object.
 
 --schema-aliases <string> (optional)
-By default, DKOs use the schema name as the last package name.  If you want to change these to your own package name, do so here.  Format is comma separated with 'as'... Like so: 'schema1 as pkg1, schema2 as pkg2, schema3 as pkg3'.
+By default, DKOs use the schema name as the last package name.  If you want to change these to 
+your own package name, do so here.  Format is comma separated with 'as'... Like so: 
+'schema1 as pkg1, schema2 as pkg2, schema3 as pkg3'.
 
 --type-mappings <path_to_file> (optional, usually 'type_mappings.json')
 Please see doc/TYPE_MAPPINGS.md for information on this file.
@@ -200,7 +211,11 @@ Please see doc/TYPE_MAPPINGS.md for information on this file.
 Please see doc/FAKE_FOREIGN_KEYS.md for information on this file.
 
 --callback-package <package_name> (optional)
-DKOs support a variety of pre and post database operations through callbacks.  Specify this parameter for where the generated DKOs should look.  For instance, a schema/table `myapp.product` would generate a class `org.kered.myapp.Product`.  Which if given a callback package of `org.kered.myapp.callbacks` would look for (static) callback methods in `org.kered.myapp.callbacks.ProductCB`.  Supported callbacks are (in a file `ProductCB.java`):
+DKOs support a variety of pre and post database operations through callbacks.  Specify this parameter 
+for where the generated DKOs should look.  For instance, a schema/table `myapp.product` would 
+generate a class `org.kered.myapp.Product`.  Which if given a callback package of 
+`org.kered.myapp.callbacks` would look for (static) callback methods in 
+`org.kered.myapp.callbacks.ProductCB`.  Supported callbacks are (in a file `ProductCB.java`):
   preInsert(Product[] products, DataSource ds)
   postInsert(Product[] products, DataSource ds)
   preUpdate(Product[] products, DataSource ds)