Re: 3.3.1 to 4.0 migration

Hi Helge

> Helge Weissig wrote:

> 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 o=
rder 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 be=
low.

Sorry not to answer sooner. There is not much time nowadays for me and Torq=
ue.
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.

    Thanks,

      Thomas

> 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 crap=
py 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
>>> =091. 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 d=
ifferent record mappers for the same table (e.g. it can be passed in throug=
h SomePeer.doSelect(Criteria, RecordMapper<TT>), so have different object r=
epresentations. For a generic village-record-like representation, see org.a=
pache.torque.om.mapper.ObjectListMapper (personally I do not like this repr=
esentation, 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
>>> =092. 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 doc=
umentation=20
>>>        and the customization part of the OR Mapping Reference=20
>>>        (https://db.apache.org/torque/torque-4.0/documentation/orm-refer=
ence/customizing-generation.html)
>>>        but I don=E2=80=99t seem to be able to find the relevant informa=
tion=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 n=
eed the control configuration
>>>        in the conf directory? The maven plugin (we use maven) has confi=
guration parameters=20
>>>        for overrideConfigDir and overrideConfigPackage=E2=80=A6 do I ne=
ed to set those?
>>=20
>> Have you checked the code-gen tutorial (http://db.apache.org/torque/torq=
ue-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) whi=
ch basically does what you want, i.e. overrides the Peer template (adding @=
SuppressWarnings annotations). The torque generation config which invokes t=
his can be found in https://svn.apache.org/repos/asf/db/torque/torque4/trun=
k/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, depen=
ding 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 cu=
rrent 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 t=
o get the example at the bottom of http://db.apache.org/torque/torque-4.0/d=
ocumentation/codegen-reference/configuration.html <http://db.apache.org/tor=
que/torque-4.0/documentation/codegen-reference/configuration.html> <http://=
db.apache.org/torque/torque-4.0/documentation/codegen-reference/configurati=
on.html <http://db.apache.org/torque/torque-4.0/documentation/codegen-refer=
ence/configuration.html>> to work. I get an error about a missing outlet ta=
g. I think if I could actually override just a specific mergepoint, that wo=
uld get me 90% of the way. However, we also modified the Bean.vm template t=
o 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 correspondi=
ng 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 t=
hat definition, the generator seems to expect to also find all other templa=
tes contained in bean.xml to be in my code base. If I remove all mergepoint=
s and other outlets and simply keep the empty outlet definition for bean/ba=
se/baseBean.vm, my template is used with a lot of warning messages about mi=
ssing mergepoint definitions and in the end, the generated beans contain on=
ly the above mentioned attributes and their getters and setters and nothing=
 else. Putting it more generally, how can I override parts of a template th=
at also contains a lot of mergepoints?
>=20
>>> =093. 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 ou=
t 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 sch=
ema changes did not get picked up because of this option, so my personal re=
commendation is not to rely on such a mechanism. Also, mvn generate is typi=
cally 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 th=
e Torque maven plugin, this should not be too difficult (please share if yo=
u choose to do it).
>=20
> The documentation has the plugin executions happen during the generate-so=
urces 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 t=
he limitations you mention though and will dig into other plugins to see wh=
at they do. It may also just be handy to have an option to skip in the plug=
in, the patch for which I am happy to contribute when I have it.
>=20
>>=20
>>> =094. 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 lev=
el 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 appen=
der and one console appender, with different log levels. The log4j configur=
ation needs to be in the classpath /org/apache/torque/generator/log4j.prope=
rties and it must have a higher classpath priority than the torque-generato=
r.jar (I am currently not sure how to achieve this using maven, the last re=
sort is patching the generator)
>=20
> OK, looking at the code in the generator, this is a little kludgy to achi=
eve via maven itself, at least as far as I can determine. Basically, one wo=
uld have to package the log4j.properties file under the path /org/apache/to=
rque/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 chec=
k 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 met=
hods 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:to=
[email protected]>
>> For additional commands, e-mail: [email protected] <mailto:=
[email protected]>