> We don't store generated superclasses in version control since that's 
> confusing and redundant.

I commit generated superclasses to Git everywhere. Never caused any issues that 
I can remember. But yes, I think that would be a prerequisite to switching away 
from cgen in build scripts to the Modeler-based flow.

What I was alluding to is that the XML config below is now managed visually in 
the Modeler and is saved in the XYZ.map.xml, while previously it was only saved 
in the local modeler preferences. So keeping a similar configuration in a build 
script was a superior approach because it was the only way to keep the config 
portable across dev machines. Imagine asking all your team members to manually 
import a custom template and setup their Modeler to use it for a specific 
project. Now this problem is gone.


<dbImport xmlns="http://cayenne.apache.org/schema/10/dbimport";>
        <catalog>
                <includeTable>
                        <name>ma_.*</name>
                </includeTable>
                <name>media</name>
        </catalog>
        <tableTypes>
                <tableType>TABLE</tableType>
                <tableType>VIEW</tableType>
        </tableTypes>
        <forceDataMapCatalog>false</forceDataMapCatalog>
        <forceDataMapSchema>false</forceDataMapSchema>
        
<namingStrategy>org.apache.cayenne.dbsync.naming.DefaultObjectNameGenerator</namingStrategy>
        <skipPrimaryKeyLoading>false</skipPrimaryKeyLoading>
        <skipRelationshipsLoading>false</skipRelationshipsLoading>
        <stripFromTableNames>^ma_</stripFromTableNames>
        <useJava7Types>false</useJava7Types>
        <usePrimitives>true</usePrimitives>
</dbImport>
<cgen xmlns="http://cayenne.apache.org/schema/10/cgen";>
        <destDir>../../../../../../java</destDir>
        <mode>entity</mode>
        <template>templates/v4_1/subclass.vm</template>
        <superTemplate>templates/v4_1/superclass.vm</superTemplate>
        <outputPattern>*.java</outputPattern>
        <makePairs>true</makePairs>
        <usePkgPath>true</usePkgPath>
        <overwrite>false</overwrite>
        <createPropertyNames>false</createPropertyNames>
        <createPKProperties>false</createPKProperties>
        <client>false</client>
</cgen>

Andrus


> On Oct 10, 2021, at 10:04 AM, Aristedes Maniatis <a...@ish.com.au.INVALID> 
> wrote:
> 
> 
> 
> On 10/10/21 5:42pm, Andrus Adamchik wrote:
>> A bit OT... Before 4.1 all my projects used cgen and most - cdbimport. Not 
>> anymore. Things went full circle and Modeler has become the only way to sync 
>> up project with the DB. DataMap XML file now stores all the settings of the 
>> c* tasks. So now I came to realization that putting those same settings in 
>> your build file (Ant/Maven/Gradle) was simply a hack that allowed to share 
>> and version-control task configs. It is not needed anymore.
>> 
>> While I'll expect pushback on this:)  , may I suggest to deprecate the tools 
>> in 5.0, and remove them in 5.1.
> 
> Can you explain a bit more? We don't store generated superclasses in version 
> control since that's confusing and redundant. [1]  This is similar to how we 
> don't store swagger generated classes in version control for the server side 
> API implementation.
> 
> 
> Ari
> 
> 
> [1] https://github.com/ishgroup/oncourse/blob/main/server/build.gradle#L335
> [2] https://github.com/ishgroup/oncourse/blob/main/server-api/build.gradle#L62

Reply via email to