This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
No announcement yet.
UsersConnectionRepository and ConnectionRepository for JPAPage Title Module
You know I thought about going the JPA way too. I mean besides already using Spring Data JPA for some of our data, and the rest using Spring Data other NoSQL projects, that I thought for adding Spring Social it would be nice to keep with that pattern. But after thinking about it, all you have to do for using the already built Jdbc version is run the ddl script to make that one userconnect table and that was it.
As opposed to doing more work to get jpa. Yes that project makes it easier where you just implement their RemoteUser interface.
Although that project hasn't been touched in a year. But there aren't many classes to have to constantly be changing it.
Um, yes you do have a datasource. No other way to get a connection to the database. And EntityManagerFactory which creates EntityManager's need/require a datasource.
Now you might not be accessing the Datasource yourself directly in your config. It might be that you are running in an App Server that is doing container managed EntityManager with Factory, but that is using a DataSource, a datasource that the App Server creates because of the datasource configuration that comes in the app server, or one that someone at your company defined. If it is the app server's note that the database it is using is probably just a dev temp one and not one that should be used in production.
And that dataSource an App Server creates is just put into the JNDI tree, just like the EntityManagerFactory was.
But that is all if you are using an App Server.
But no matter what there is a DataSource out there that it is using.
In short: There is currently not a JPA implementation of the connection repositories, aside from some work that has been done in the community.
And, to be honest, I struggle a bit understanding why one is necessary when the JDBC-based one will work fine. The only piece of code that cares about connections is the connection repository and therefore it's not like *you're* code will be reading/writing to the connection table. And that table has no joins with other tables. For all intents and purposes, it could be in a completely different database (although it's handy having it in the same database for DataSource-reuse purposes). So why is a JPA-specific implementation needed?