StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
4390644
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2010-12-08T17:52:52.203
FavoriteCount
0
LastActivityDate
2010-12-08T17:52:52.203
LastEditDate
LastEditorUserId
0
OwnerUserId
337101
ParentId
493926
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
I think it generally not a good idea insert the user object into the request object every time: The request lifetime is very short, so you might end up making round trips to caches or even worse to the database on each http-request to retrieve an object, that you might not even need and that get's deleted immideately afterwards. So if you must, better store the whole object in the session instead of just the id. Generally, I'd suggest you write a <code>AuthenticationService</code> with a method <code>isLoggedIn()</code> that returns true when the user is authenticated and a method <code>getLoggedInUser()</code> that returns this object. <pre><code>class AuthenticationService { def transactional = false boolean isLoggedIn() { return session.user_id } def getLoggedInUser() { return User.get(session.user_id) } } </code></pre> Then you use the Filter for redirection if not authenticated, and maybe the Interceptor for storing the local reference <code>user = authenticationService.loggedInUser</code>. But also I don't think this the best way to go. I suggest you'd create an abstract <code>AuthenticationAwareController</code> as base class for all your controllers in src/groovy and there have the convenience method like <code>user</code> <pre><code>class AuthenticationAwareController { def authenticationService def getUser() { return authenticationService.loggedInUser() } } </code></pre> This way, you can later change you mind about storing the user however you like and don't have to change your code. Also you benefit from Caches in Hibernate, that share already retrieved user object instances between different sessions, so db roundtrips are avoided. You still should check the retrieved user object for validity or throw an <code>AuthenticationException</code> in case the retrieval does not succeed. (Maybe something like <code>AuthenticationService.getLoggedInUser(failOnError = false)</code>.) You can even make this Service/ControllerBase a small plugin an reuse that on every application or go directly with the spring security plugin... ;-)
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. PODefining controller accessible variables from filters in Grails
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAdrian0CG
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.