public final class Generate extends Object
This framework is great for inserting and updating data in various tables and even fetching one or more rows form individual tables.
For each table foo in our database, the following classes are generated:
This framework is not intended to transparently allow arbitrary joins and data from multiple tables. A better way is to use prepared statements directly to run ad-hoc SQL queries including those containing arbitrary joins.
However, to somewhat facilitate arbitrary select queries/joins across multiple tables,
each generated "Mgr" class has a columns()
method
that returns a list of columns for the corresponding table. For example, in say a Molly
Server Page where information from two tables (table1, table2) is displayed from both
tables on the same page.
String my_query = "select " + table1Mgr.columns() + ", " + table2.columns() + " from table1, table2 WHERE table1.x = table2.x"; PreparedStatement ps = connection.prepareStatement(my_query); ResultSet rs = connection.executeQuery(); while (rs.next()) { table1 t1 = table1Mgr.getFromRS(rs); //create a new table1 from the rs table2 t2 = table2Mgr.getFromRS(rs); //ditto for table2 //..use t1 and t2... //.... }
Here is a minimal sample configuration file.
Cache
utility class(es).
Note 2: MySQL 3.x, 4.x or 5.x does not have true boolean types and silently converts bool types to TINYINT. This wreaks havoc with auto-generated code which creates methods with the wrong signature (TINYINT as opposed to bool).
There are 2 approaches to solving this mysql-specific problem:
a) Require all boolean columns to begin with some keyword (say bool_) and if a column begins with this word, then treat it as a boolean, regardless of the type returned by the database meta data.If the flag mysqlBooleanHack is set to false in the configuration file, then TINYINT's are not transformed to booleans. There should be no practical need to do this however.
b) Treat all TINYINT's as boolean types. This is the approach I have chosen since TINYINT's are NOT portable across databases (for example PostgresQL does not have TINYINT's). Therefore we should not use TINYINT's in physical database models; if booleans are turned into TINYINT's by MySQL then so be it..since that will not clash with any of our modelled types.
Note 3: MySQL allows its tables and columns to start with a numeral. For example: 52_weeks, 3_col, etc. This is wrong, not-standard and not-supported. From the spec:
SQL identifiers and key words must begin with a letter (a-z, but also letters with diacritical marks and non-Latin letters) or an underscore (_). Subsequent characters in an identifier or key word can be letters, underscores, digits (0-9), or dollar signs ($).
So compiling these wrongly named tables (which only MySQL and no other database allows) results in a bunch of java compiler errors, which may confuse neophytes into believing that the generator is outputting buggy code. No, the generated code is proper and exactly the way its intended to be. Java variables/classes cannot start with a number. Hence, compiler errors. So if you must use MySQL, at least don't name your tables with a number.
Modifier and Type | Method and Description |
---|---|
boolean |
isMysql() |
boolean |
isPostgres() |
static void |
main(String[] args)
Usage:
java fc.jdbc.dbobjects.Generate -conf
|