Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Users List" <torque-user@db.apache.org>
From: Helge Weissig <helgew@grajagan.org>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_347B2F23-ECFB-4BAC-989B-738C5C9D28FE"
Message-Id: <058162AA-24A6-43B5-9FA3-D44EF517CA60@grajagan.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2101\))
Subject: Re: 3.3.1 to 4.0 migration
Date: Wed, 8 Jul 2015 15:31:02 -0700
References: <E39DA7D3-E39E-472D-8A9C-6A7970D806CE@grajagan.org>
 <D6E412D0-9174-4FDC-B09D-76BBCEC68B9F@grajagan.org>
 <892020672.4015702.1435799001627.JavaMail.zimbra@seitenbau.com>
 <C8B226F0-2EC6-49D1-AF0D-637239AC356A@grajagan.org>
 <922F4C29-498E-454F-9D8C-2999357133F4@grajagan.org>
 <1885624663.6278105.1436318913990.JavaMail.zimbra@seitenbau.com>
To: Apache Torque Users List <torque-user@db.apache.org>
In-Reply-To: <1885624663.6278105.1436318913990.JavaMail.zimbra@seitenbau.com>

--Apple-Mail=_347B2F23-ECFB-4BAC-989B-738C5C9D28FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

No worries! Thanks again for your help earlier.

I have submitted two patches at =
https://issues.apache.org/jira/browse/TORQUE-337 =
<https://issues.apache.org/jira/browse/TORQUE-337> and =
https://issues.apache.org/jira/browse/TORQUE-338 =
<https://issues.apache.org/jira/browse/TORQUE-338>. The first adds the =
ability to easily override the logging configuration for the Generator =
and the second fixes the implementation of the undocumented (hint! hint! =
;) ) configuration setting runOnlyOnSourceChange, which already provides =
for a way to skip the re-generation of sources when the schema files =
have not changed.

Additionally, I submitted =
https://issues.apache.org/jira/browse/TORQUE-339 =
<https://issues.apache.org/jira/browse/TORQUE-339>, which provides a =
patch for the generator=E2=80=99s configuration documentation.

hth,
h.

> On Jul 7, 2015, at 6:28 PM, Thomas Fox <Thomas.Fox@seitenbau.com> =
wrote:
>=20
> Hi Helge
>=20
>> Helge Weissig wrote:
>=20
>> Just a quick follow-up to report on progress on the template =
conversions.=20
>> I managed to get the single mergepoint override working by changing =
the order of outlets and mergepoints.=20
>> As for the bean classes, I was able to just use the baseBean.vm =
template and it=E2=80=99s outlet directly from the distribution.
>>=20
>> Let me know if you are still interested in the two patches I =
mentioned below.
>=20
> Sorry not to answer sooner. There is not much time nowadays for me and =
Torque.
> I'm glad you got it finally working. Are there still open questions?
> Yes, I'm still interested in the two patches. Please create jira =
issues.
>=20
>    Thanks,
>=20
>      Thomas
>=20
>> cheers,
>> h.
>=20
>=20
>> On Jul 2, 2015, at 5:04 PM, Helge Weissig <helgew@grajagan.org> =
wrote:
>>=20
>> Thanks Thomas! Some comments and follow-up questions below:
>>=20
>>> On Jul 1, 2015, at 6:03 PM, Thomas Fox <Thomas.Fox@seitenbau.com> =
wrote:
>>>=20
>>> Helge Weissig wrote:
>>>=20
>>>> I forgot about the HTML filter this group uses=E2=80=A6 pardon the =
crappy formatting.=20
>>>> Here is a text-only version:
>>>>=20
>>>> Our code base is heavily invested in some of the functionality =
removed from torque 4.0=20
>>>> and I was wondering if any one had some advice on a migration path:
>>>>=20
>>>> 	1. We make extensive use of village records obtained via=20
>>>>       BasePeer.doSelect(Criteria), for example.=20
>>>>       Those results could probably be considered a view of the data
>>>>       and I am wondering if that would be the =
correct/recommended/best approach.
>>>=20
>>> 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.=20
>>=20
>> 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.
>>=20
>>=20
>>>> 	2. We have added our own caching implementation=20
>>>>       (configurable via the schema definition) to the Object.vm=20
>>>>       and Peer.vm templates. I have read through the new generator =
documentation=20
>>>>       and the customization part of the OR Mapping Reference=20
>>>>       =
(https://db.apache.org/torque/torque-4.0/documentation/orm-reference/custo=
mizing-generation.html)
>>>>       but I don=E2=80=99t seem to be able to find the relevant =
information=20
>>>>       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=20
>>>>       for overrideConfigDir and overrideConfigPackage=E2=80=A6 do I =
need to set those?
>>>=20
>>> Have you checked the code-gen tutorial =
(http://db.apache.org/torque/torque-4.0/documentation/tutorial/orm/index.h=
tml) 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.x=
ml 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 :-)
>>=20
>> 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/con=
figuration.html =
<http://db.apache.org/torque/torque-4.0/documentation/codegen-reference/co=
nfiguration.html> =
<http://db.apache.org/torque/torque-4.0/documentation/codegen-reference/co=
nfiguration.html =
<http://db.apache.org/torque/torque-4.0/documentation/codegen-reference/co=
nfiguration.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 =E2=80=9Cmodified=E2=80=
=9D or =E2=80=9Cnew=E2=80=9D 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?
>>=20
>>>> 	3. This is more of a maven question, maybe, alas I have the =
feeling
>>>>       it isn=E2=80=99t actually possible to implement through it, =
but is there a way
>>>>       to skip the code generation steps if the schema sources have =
not changed?
>>>=20
>>> 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).
>>=20
>> 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 =E2=80=98mvn compile=E2=80=99 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.
>>=20
>>>=20
>>>> 	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,=20
>>>>       not to the console? We use log4j throughout our project.
>>>=20
>>> 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)
>>=20
>> 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.
>>=20
>> Thanks again for your help!!
>>=20
>> cheers,
>> h.
>>=20
>>=20
>>=20
>>> Good luck!
>>>=20
>>> Thomas
>>>=20
>>> =
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org =
<mailto:torque-user-unsubscribe@db.apache.org>
>>> For additional commands, e-mail: torque-user-help@db.apache.org =
<mailto:torque-user-help@db.apache.org>
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>=20


--Apple-Mail=_347B2F23-ECFB-4BAC-989B-738C5C9D28FE--