Hi Francesco >>> I guess that one could rewrite ContentLoader, ContentUpgrader and ContentExporter to work with EntityManager and thus remove spring-jdbc from main dependencies (it will still be used by integration tests code). >>> I decided to use the JPA Layer instead of JDBC Template to initially load the db https://issues.apache.org/jira/browse/FEDIZ-78
But I don't have to write a ContextLoader then anymore as I can configure all the entity beans in an isolated spring configuration file, load it and call persist on all object types in a certain order: http://svn.apache.org/viewvc/cxf/fediz/trunk/services/idp/src/main/java/org/apache/cxf/fediz/service/idp/service/jpa/DBLoaderSpring.java?view=markup Wouldn't that not make sense for Syncope as well? The OpenJPA also supports to create the indexes - well in a proprietary way till JPA 2.1 is officially supported. Thanks Oli ________________________________________ From: Oliver Wulff [owu...@talend.com] Sent: 05 January 2014 14:44 To: dev@syncope.apache.org Subject: RE: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml > OpenJPA is initialized via Spring in persistenceContextEMFactory.xml: as you can read from there, the OpenJpaVendorAdapter is configured with 'generateDdl' true. Even this was set to true (in my case for Fediz IDP) it didn't create the table therefore I thought there must be something else missing. Thanks Oli ________________________________________ From: Francesco Chicchiriccò [ilgro...@apache.org] Sent: 03 January 2014 14:06 To: dev@syncope.apache.org Subject: Re: Persistence Layer in Syncope, Table Creation, orm.xml, content.xml On 03/01/2014 13:56, Oliver Wulff wrote: > Thanks for your feedback. I didn't find where you configure OpenJPA to create > the tables when the spring context is created. You do all the initialization > work in SpringContextInitializer which also loads the table if empty. OpenJPA is initialized via Spring in persistenceContextEMFactory.xml: as you can read from there, the OpenJpaVendorAdapter is configured with 'generateDdl' true. > I've used an ApplicationListener and used JPA to insert the records into the > tables which will also create tables implicitly. > > Will try to write a JPA based ContentLoader to fill the data. Good news: in case, please do it with reference to trunk (not 1_1_X branch). Regards. > ________________________________________ > From: Francesco Chicchiriccò [ilgro...@apache.org] > Sent: 31 December 2013 09:14 > To: dev@syncope.apache.org > Subject: Re: Persistence Layer in Syncope, Table Creation, orm.xml, > content.xml > > On 30/12/2013 21:44, Oliver Wulff wrote: >> Hi there >> I'm looking into adding a persistence layer to the Apache Fediz Identity >> Provider and used the persistence layer in Syncope as a good reference. >> Nevertheless, I got a few questions... > Hey, looks cool :-) > >> 1) JPA creates the tables when the first entity is added - usually triggered >> by a REST call. >> They won't be created when the spring application context is loaded. The >> Syncope ContentLoader does only add rows to existing tables and creates >> indexes and views, but no tables. How did you workaround this? > OpenJPA is configured in Syncope to create tables when Spring context is > loaded (you can experiment this by providing an empty content.xml or by > disabling the ContentLoader). > >> 2) What was the reason for you to create an orm.xml instead of using >> annotations only? > The general policy was to use orm.xml for all configurable parameters > that would have been instead stuck as annotation parameters in the > source code. > For example: putting table generators in orm.xml lets you easily > configure the initial value to pick without changing the source code. > This is very useful in Syncope since it is meant to be used via WAR > overlays. > >> 3) You introduced your own semantic of a file to import default data >> (content.xml). I assume you did not use an SQL script to be independent of >> the database? > Correct. > >> But why did you use the JDBC template instead of the JPA layer? > Hum, that's a nice question, probably related to the evolution that > ContentLoader had from original (pre-ASF) DBUnit. > I guess that one could rewrite ContentLoader, ContentUpgrader and > ContentExporter to work with EntityManager and thus remove spring-jdbc > from main dependencies (it will still be used by integration tests code). > > Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
