added command line support for generate-dkos

doc/COMMANDS.md

@@ -79,7 +79,7 @@ This will write out `schemas.json`, which looks like this:
 
 All available options:
 
-```bash
+```
 $ java -jar lib/dko.jar extract-schema --help
 
  Help for command: extract-schema 
@@ -128,3 +128,89 @@ Your database's JDBC URL.  Examples:
   jdbc:sqlite://dirA/dirB/dbfile
   jdbc:oracle:thin:@myhost:1521:orcl
 ```
+
+The Generate DKOs Command
+-------------------------
+
+An example (from `examples/helloworld`):
+
+```bash
+$ cat examples/helloworld/generate-dkos.sh 
+#!/bin/bash
+
+java -jar ../../lib/dko.jar generate-dkos \
+	--schemas schemas.json \
+	--package com.mycompany.dko \
+	--java-output-dir gensrcdko
+```
+
+This will generate these files:
+
+```bash
+$ find examples/helloworld/gensrcdko/
+examples/helloworld/gensrcdko/
+examples/helloworld/gensrcdko/com
+examples/helloworld/gensrcdko/com/mycompany
+examples/helloworld/gensrcdko/com/mycompany/dko
+examples/helloworld/gensrcdko/com/mycompany/dko/_TableToClassMap.java
+examples/helloworld/gensrcdko/com/mycompany/dko/Place.java
+examples/helloworld/gensrcdko/com/mycompany/dko/Person.java
+examples/helloworld/gensrcdko/.timestamp
+```
+
+All available options:
+
+```
+$ java -jar lib/dko.jar generate-dkos --help
+
+ Help for command: generate-dkos 
+---------------------------------
+
+--enums <path> (optional)
+Path to the optional enums JSON file (generated by your extract-schema call, usually 'enums.json').
+
+--schemas <path> (required)
+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'.
+
+--java-output-dir <path> (required)
+Directory to write the generated class files to.  Usually 'gensrcdko' or similar.
+DO NOT CHECK THESE FILES INTO VERSION CONTROL!  They should be a build artifact.
+DO NOT MIX THESE WITH YOUR HAND-WRITTEN CODE!  That will only lead to checking them into VC.
+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'.
+
+--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)'.
+
+--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.
+
+--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'.
+
+--type-mappings <path_to_file> (optional, usually 'type_mappings.json')
+Please see doc/TYPE_MAPPINGS.md for information on this file.
+
+--fake-fks <path_to_file> (optional, usually 'fake_fks.json')
+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`):
+  preInsert(Product[] products, DataSource ds)
+  postInsert(Product[] products, DataSource ds)
+  preUpdate(Product[] products, DataSource ds)
+  postUpdate(Product[] products, DataSource ds)
+  preDelete(Product[] products, DataSource ds)
+  postDelete(Product[] products, DataSource ds)
+  toString(Product product)
+  hashCode(Product product)
+  equals(Product product, Object object)
+  compareTo(Product product1, Product product2)
+These are useful for data checks, automatic field population, etc...
+```
+

doc/FAKE_FOREIGN_KEYS.md

@@ -0,0 +1,24 @@
+
+Fake Foreign Keys
+=================
+
+Usually DKOs use the automatically generated FK relationships extracted from the database.  But sometimes
+those foreign keys aren't actually there.  (Almost always for performance reasons.)   Specifying this file lets
+you add FK relationships to the generated code regardless (for all the `with(FK)` goodness).  The format is 
+JSON, like the following:
+
+```json
+{
+    "fk_name_1":{
+        "reffing": ["my_schema","product"],
+        "reffed": ["my_schema","manufacturer"],
+        "columns": {"manufacturer_id": "id"}
+    },
+}
+```
+
+This will create a FK relationship from the 'reffing' table's `product.manufacturer_id` to the 'reffed' 
+table's `manufacturer.id`.  Compound keys are additional entries in the "columns" map.  
+
+The foreign key names (`fk_name_1`) don't matter, as long as they're unique in the file.
+

doc/TYPE_MAPPINGS.md

@@ -0,0 +1,46 @@
+
+Type Mappings
+=============
+
+DKOs have default Java types for each database column type known.  But sometimes you don't want what's being 
+offered.  If you want to change the type of a generated field, you need to create a `type_mapping.json` file.
+
+for instance, if you want all `java.sql.TimeStamp`s changed to `java.util.Date` (because the time components
+are always ignored by your app), you need a `class_mappings` entry in your `type_mapping.json`.  An example:
+
+```json
+{
+    "class_mappings": {
+        "java.sql.Timestamp": "java.util.Date",
+    },
+    "functions": {
+      "java.sql.Timestamp java.util.Date" :
+          "new java.util.Date((%s).getTime()",
+      "java.util.Date java.sql.Timestamp" :
+          "new java.sql.Timestamp((%s).getTime()",
+    }
+}
+```
+
+Note the required `functions` section which specifies Java code for conversions between the two.  The first 
+entry converts a `Timestamp` to a `Date`.  The second does the reverse.  This will work for your own custom
+classes as well.
+
+If you don't want all types to be mapped the same way for all classes, you can specify Java
+regex statements (matched against the schema.table.column names) to specify certain classes.
+For example, this will do the same as the previous example, but only for fields with names ending in "_date":
+
+```json
+{
+    "schema_mappings": {
+        ".*_date": "java.util.Date",
+    },
+    "functions": {
+      "java.sql.Timestamp java.util.Date" :
+          "new java.util.Date((%s).getTime()",
+      "java.util.Date java.sql.Timestamp" :
+          "new java.sql.Timestamp((%s).getTime()",
+    }
+}
+```
+

examples/helloworld/generate-dkos.sh

@@ -0,0 +1,6 @@
+#!/bin/bash
+
+java -jar ../../lib/dko.jar generate-dkos \
+	--schemas schemas.json \
+	--package com.mycompany.dko \
+	--java-output-dir gensrcdko