Just a quick follow-up to report on progress on the template conversions. I managed to get the single mergepoint override working by changing the order of outlets and mergepoints. As for the bean classes, I was able to just use the baseBean.vm template and it’s outlet directly from the distribution.
Let me know if you are still interested in the two patches I mentioned below. cheers, h. > On Jul 2, 2015, at 5:04 PM, Helge Weissig <hel...@grajagan.org> wrote: > > Thanks Thomas! Some comments and follow-up questions below: > >> On Jul 1, 2015, at 6:03 PM, Thomas Fox <thomas....@seitenbau.com> wrote: >> >> Helge Weissig wrote: >> >>> I forgot about the HTML filter this group uses… pardon the crappy >>> formatting. >>> Here is a text-only version: >>> >>> Our code base is heavily invested in some of the functionality removed from >>> torque 4.0 >>> and I was wondering if any one had some advice on a migration path: >>> >>> 1. We make extensive use of village records obtained via >>> BasePeer.doSelect(Criteria), for example. >>> Those results could probably be considered a view of the data >>> and I am wondering if that would be the correct/recommended/best >>> approach. >> >> If you are using this to read data only, have a look at the RecordMapper >> functionality. A record mapper maps DB Columns to an object. You can use >> different record mappers for the same table (e.g. it can be passed in >> through SomePeer.doSelect(Criteria, RecordMapper<TT>), so have different >> object representations. For a generic village-record-like representation, >> see org.apache.torque.om.mapper.ObjectListMapper (personally I do not like >> this representation, put perhaps it serves your needs). Views (now supported >> !) are also a more db-centric option. > > It looks like RecordMapper may ultimately be the best way to go although I > still like the idea of using views because it would simplify the assembly of > criteria in our code and allow for some generalization as well. > > >>> 2. We have added our own caching implementation >>> (configurable via the schema definition) to the Object.vm >>> and Peer.vm templates. I have read through the new generator >>> documentation >>> and the customization part of the OR Mapping Reference >>> >>> (https://db.apache.org/torque/torque-4.0/documentation/orm-reference/customizing-generation.html) >>> but I don’t seem to be able to find the relevant information >>> to put it all together. Basically, I would like to override one or >>> more templates. >>> I think I know how to specify that in an outlet, but do I also need >>> the control configuration >>> in the conf directory? The maven plugin (we use maven) has >>> configuration parameters >>> for overrideConfigDir and overrideConfigPackage… do I need to set >>> those? >> >> Have you checked the code-gen tutorial >> (http://db.apache.org/torque/torque-4.0/documentation/tutorial/orm/index.html) >> for a basic understanding ? >> Also, there is an example in the torque test project >> (https://svn.apache.org/repos/asf/db/torque/torque4/trunk/torque-test/src/main/torque-gen) >> which basically does what you want, i.e. overrides the Peer template >> (adding @SuppressWarnings annotations). The torque generation config which >> invokes this can be found in >> https://svn.apache.org/repos/asf/db/torque/torque4/trunk/torque-test/pom.xml >> lines 183ff. >> To be more specific: >> Yes, you need at least an empty control configuration. >> You need to set either overrideConfigDir or overrideConfigPackage, depending >> whether the additional templates can be found in the file sytsem or in the >> classpath. >> Please ask again if you cannot get it working. Although more complicated >> :-(, the new generator is much more extensible than the old one. In the >> current trunk, you can even use groovy templates :-) > > OK, I am getting somewhere, my outlets and templates are now found, alas I am > having trouble achieving the desired results. For one, I am not able to get > the example at the bottom of > http://db.apache.org/torque/torque-4.0/documentation/codegen-reference/configuration.html > > <http://db.apache.org/torque/torque-4.0/documentation/codegen-reference/configuration.html> > > <http://db.apache.org/torque/torque-4.0/documentation/codegen-reference/configuration.html > > <http://db.apache.org/torque/torque-4.0/documentation/codegen-reference/configuration.html>> > to work. I get an error about a missing outlet tag. I think if I could > actually override just a specific mergepoint, that would get me 90% of the > way. However, we also modified the Bean.vm template to allow us to continue > using fields like “modified” or “new” in our DB schema. Those attributes and > their corresponding getters and setters are now in the template > bean/base/baseBean.vm which is referenced from the bean.xml outlet > definition. If I simply bring over that definition, the generator seems to > expect to also find all other templates contained in bean.xml to be in my > code base. If I remove all mergepoints and other outlets and simply keep the > empty outlet definition for bean/base/baseBean.vm, my template is used with a > lot of warning messages about missing mergepoint definitions and in the end, > the generated beans contain only the above mentioned attributes and their > getters and setters and nothing else. Putting it more generally, how can I > override parts of a template that also contains a lot of mergepoints? > >>> 3. This is more of a maven question, maybe, alas I have the feeling >>> it isn’t actually possible to implement through it, but is there a >>> way >>> to skip the code generation steps if the schema sources have not >>> changed? >> >> Sorry, this is not any more possible. The problem is to reliably find out >> whether the file has changed (e.g. some OS do not change the change date of >> a file when it is copied). I have seen more than one situation where schema >> changes did not get picked up because of this option, so my personal >> recommendation is not to rely on such a mechanism. Also, mvn generate is >> typically not executed often while developing, so long generation times >> should not slow down development too much. >> However, if you still want to use it, you can patch the Mojo class in the >> Torque maven plugin, this should not be too difficult (please share if you >> choose to do it). > > The documentation has the plugin executions happen during the > generate-sources phase, which is part of the standard build life-cycle and is > executed whenever I run a ‘mvn compile’ for example. I understand the > limitations you mention though and will dig into other plugins to see what > they do. It may also just be handy to have an option to skip in the plugin, > the patch for which I am happy to contribute when I have it. > >> >>> 4. I know how to configure logging for the generator, but the switch >>> between loglevel >>> WARN and INFO is quite severe. Is there a way to log at INFO level >>> but only to a file, >>> not to the console? We use log4j throughout our project. >> >> Yes, check the log4j configuration documentation. Basically you need to >> override the log4j configuration file and use two appenders, one file >> appender and one console appender, with different log levels. The log4j >> configuration needs to be in the classpath >> /org/apache/torque/generator/log4j.properties and it must have a higher >> classpath priority than the torque-generator.jar (I am currently not sure >> how to achieve this using maven, the last resort is patching the generator) > > OK, looking at the code in the generator, this is a little kludgy to achieve > via maven itself, at least as far as I can determine. Basically, one would > have to package the log4j.properties file under the path > /org/apache/torque/generator in a jar file that then would be listed as a > dependency for the torque maven plugin. Alternatively, a patch in the > generator could check if a logger has already been configured (e.g. via the > -Dlog4j.properties system variable) and just use that one if it is the case. > I tested both methods and they work. Personally I prefer the second approach > and I am happy to contribute the patch if you let me know how. > > Thanks again for your help!! > > cheers, > h. > > > >> Good luck! >> >> Thomas >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: torque-user-unsubscr...@db.apache.org >> <mailto:torque-user-unsubscr...@db.apache.org> >> For additional commands, e-mail: torque-user-h...@db.apache.org >> <mailto:torque-user-h...@db.apache.org>
