What is the UsersConnectionRepository for in Spring Social Facebook?

[mueller]

I'm following the directions here and elsewhere:
https://github.com/SpringSource/spri...ki/Quick-Start

Why do we need to specify a dataSource and UsersConnectionRepository to use Spring Social Facebook? What gets written to our database? Am I supposed to create special tables or modify my Users table?

[habuma]

To be clear, you don't need a data source or UsersConnectionRepository to use Spring Social Facebook. If you want to obtain the access token through other means, you can certainly create an instance of FacebookTemplate and go from there.

You do need a UsersConnectionRepository, however, if you want to use Spring Social's connection support. A UsersConnectionRepository can be used to create a ConnectionRepository, which ConnectController will use to persist connections for long-term use (so that you don't have to go back and ask the user to authorize your app every time). And, in Spring Social 1.0, the only implementation of UsersConnectionRepository is JDBC-based--so it needs a data source to be able to access the database.

If you've not done so already, check out http://static.springsource.org/sprin...eprovider.html, specifically section 2.3 will clear up the purpose of the connection repository.

[mueller]

That's what I was looking for Craig! Thanks.

[samkiller]

Sorry for digging this thread after all these months. But I have a little question since I'm beginning to use spring social.
Our main database is not a RDBMS, but Cassandra . Then the JdbcUsersConnectionRepostory is useless.Does it mean I have to implement the full ConnectionRepository interface with all the methods in order to make it work. And then do I still need the UsersConnectionRepository to be implemented?
Sorry if theses are so beginner minded.

[habuma]

In short, the answers to all of your questions are "yes".

We set out to provide a JDBC-based set of templates, as we figured that would be the one most commonly used. But knowing that other implementations would prove useful, it's all based on interfaces from which you can implement whatever kind of connection repository you want. Some work has been done in the community already to provide JPA-based, Mongo-based, and SQLite-based implementations. If you decide to implement a Cassandra-based implementation, then it'd be awesome if you could share your work with the community.

And yes, you'd need to implement both ConnectionRepository and UsersConnectionRepository. The UsersConnectionRepository is one that deals with connections across all users, while ConnectionRepository focuses on connections for a specific user.

At first glance, it may seem that ConnectionRepository is the most useful of the two. In fact, it's the ConnectionRepository that ConnectController uses to manage connections for the current user. And in an application that only cares about creating connections between its users and some provider, then UsersConnectionRepository is only a means to an end...that is, it only exists to create a ConnectionRepository for the current user.

But if the app offers a sign-in-with-provider option, then UsersConnectionRepository is useful for more than just being a ConnectionRepository factory. In that scenario, there isn't a notion of a "current user" yet...they're still signing in. Therefore, ConnectionRepository is useless for helping a user sign in. UsersConnectionRepository, having the ability to deal with all connections for all users is able to help ProviderSignInController find a user who has a connection that matches the connection details obtained while signing in with Facebook/Twitter/etc.

[samkiller]

Thanks it's all clear now.
Thanks for the great job.

[gumkins]

Hello,

Can somebody specify any useful link where I can find out status of Mongo-based implementation of the interfaces please?

Thanks

[habuma]

I seem to recall that someone was working on a Mongo implementation, but I can't seem to find the reference to it.

I *do* want to include a Mongo implementation in some future version of Spring Social. There's even an issue for it in JIRA (which I'd link to, but our JIRA is down for maintenance right now). I've got an ambitious plan for things to include in a 1.1 release, and this is one of those items on my list (it's just a really high priority item).

It really shouldn't be that hard to implement, though...in fact, I'd think it'd be much simpler than the JDBC implementation. It'd be super-simple if you created a dependency on Spring Data Mongo, but I'm not so sure that I'd encourage that approach, as I'd like to avoid a transitive dependency on Spring Data--not because I don't like Spring Data (I really really really like it), but because that dependency would otherwise be unnecessary for any project not using Spring Data.

[gumkins]

Hi Craig,

Yes, I saw the Jira issue and related discussion.

Taking into account dates of those messages of that thread I've made an assumption that this has been already done and is available on some unofficial resource.

Thank you,

Alex

[gumkins]

Finally it is found.