Hi McKinley, Just a quick reply to let you know we'll have a look at your patch. We really appreciate user feedback and it seems you know a lot about database-specific differences. Further the empire-db codegen was really a good addition to the framework.
The new year brought us quite some activity in the community :-) Cheers, Francis On Fri, Jan 8, 2010 at 5:44 PM, McKinley <[email protected]> wrote: > Hello, > > I am using Empire-db in a large project. It is working very well and > gives very good control over query generation. I love doing multi > table conditional joins! If you could see what I had to do before in > stored procedures you would weep :) I am using codegen entirely so > that schema changes will can always be automatically synchronized. In > my project I am using Empire-db to move data between SQL Server 2005 > and MySQL among other things. > > I have found it necessary for my needs to use custom velocity > templates (I do not need a "C_" prefix on my column names for > example). In some cases, I need different templates for SQL Server and > MySQL. Therefore, being able to specify a template folder in the > config file is convenient. I have added that. > > There is a bug in codegen where a column named "state" will conflict > with DBRecord.getState() or was it DBRecord.setState()? I added a > feature to compare each generated accessor and mutator name against > the method names of DBRecord. If there is a conflict, "Column" is > appended to the getter name and setter name to keep them consistent. I > would like someone to answer the question quoted at the bottom of this > email to let me know if the column name in the table class will need > to be named consistent to the getter and setter too. > > In one of my databases, my table names are already camel case so I > added a check for that in the javaClassName method. If '_' and ' ' are > not present (some schemas can have ' ' in the name) then it will not > try and uppercase beyond the first character. > > There is a little hack for MySQL default value on timestamp data type. > It may be a hack or it may be the right way to do it, but I think it > should go into codegen now and get pushed upstream later or kept in > codegen but surrounded by checks from supported features in the > Empire-db database drivers. > > The best feature I have added here is support for AUTOINC in codegen. > My schemas use AUTOINC but this introduces and interesting problem for > codegen. Codegen will not create the right Java data type in the > Record class for the AUTOINC column if we change the type. So, I use > an attribute to store the base data type (usually int, but could be > others) and made changes to read that data type during the creation of > the Record class. > > I am going to add quoted identifiers soon so that codegen will use the > table name "[Transcation]" instead of "Transaction" in the table class > generation. I have some schemas with a few reserved words used as > table or column names. Codegen will need wrap the proper quotes around > the column name when it writes to the super.addColumn("${col.name}"... > line. > > Here is a like to the feature request and the patch is attached. > https://issues.apache.org/jira/browse/EMPIREDB-69 > > Thanks, > > McKinley > > On Thu, Jan 7, 2010 at 2:52 PM, McKinley <[email protected]> wrote: >> When I extend the DBRecord class (especially with the templates) and >> that type is used by a DBReader, what controls the assignment of data >> from the reader to the record data? Is it on the setter argument type >> or on on the setter name minus "set"? >> >> Thanks, >> >> McKinley >> > -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house.
