Re: 3.3.1 to 4.0 migration

--Apple-Mail=_1B06FF29-0EA8-4C02-A0BF-ADD0DB9AED15
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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=E2=80=99s 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 <[email protected]> wrote:
>=20
> Thanks Thomas! Some comments and follow-up questions below:
>=20
>> On Jul 1, 2015, at 6:03 PM, Thomas Fox <[email protected]> =
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: [email protected] =
<mailto:[email protected]>
>> For additional commands, e-mail: [email protected] =
<mailto:[email protected]>

--Apple-Mail=_1B06FF29-0EA8-4C02-A0BF-ADD0DB9AED15--