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.

Let's say I have two type of users whom can each modify these Name objects. For some silly reason one group is not allowed to see / edit the middle names of the users. So I leave that field off of the form (no hidden field either).

Is there anyway to keep Spring from clearing that middle name field (i.e it wasn't displayed to the user, hence it couldn't have changed)?

I could create a new object for this, but it seems like duplication which shouldn't be needed.

Comment

In fact that is by design. The name instance that is passed to controller method is created from the request parameters, the process is called binding. So if your form doesn't contain middle field it has no way to appear in the name parameter passed to controller. The key point here is that it has nothing to do with your DAO.

Let's have a good look at your particular example. Pretend you have a Name stored in the DB with id = 1, name = Samuel, middle = Langhorne and last = Clemens. Let's also pretend that you have two user roles: ROLE_A can change name and middle, ROLE_B can change name and last.

First this to do is to display relevant fields for the form depending on user role:

See theseposts for how to get $security available in your templates. Note, I haven't tried it myself, but it should work .

Now you need to obtain the Name stored in the DB using the submitted id (1), update properties allowed depending on roles current user is (2) (since nothing prevents him from POSTing fields not shown in markup, never trust the user ) and then save it back to the db (3).

Comment

We first must lookup the user (if one exists on the initial search page), then redirect them to this new page, where we must again pull them from the DB to ensure freshness.

Then upon posting, we have to pull them from the DB to persist the middle name?

That's 3 hits for lookup, plus another one to save the user (if changes occur).
Not to mention the fact that we'd then have to implement our security code to utilize spring security as well (although I'd see this as a win, I'm not so sure others on the team would).

Comment

Oh, please don't blame me That's your business requirements. But I doubt it is a huge DB hit. How often is this name change used in your system? Is it at least 10% of use cases? Also note that fetching a row by primary key (that's what we are doing in this code) is extremely optimized in all DBMS I've heard of.

Originally posted by sgentry

We first must lookup the user (if one exists on the initial search page), then redirect them to this new page, where we must again pull them from the DB to ensure freshness.

I wasn't aware of these two steps performed before Name update since you didn't mention them, but I don't think there's another option here.

Originally posted by sgentry

Then upon posting, we have to pull them from the DB to persist the middle name?

That's 3 hits for lookup, plus another one to save the user (if changes occur).

In fact you may omit this fetch. Implement two extra methods updateNameAndLast(Name name) and updateNameAndMiddle(Name name). Depending on underlying technology used you'll need to create a custom SQL/HQL/JPQL update query for each of them.

Originally posted by sgentry

Not to mention the fact that we'd then have to implement our security code to utilize spring security as well (although I'd see this as a win, I'm not so sure others on the team would).

Well, Spring Security is not a must. I just thought you are already using it since you mentioned two type of users in your initial post. Just substitute the view and controller logic based on Spring Security with the one you already use, I just showed the concept.

Comment

While you're correct on the part of lookup on primary key, we have other instances where we are dealing with many many results. Looking up by that type of query is expensive. We're also likely to experience large user growth, so any extra performance I can squeeze out of the DB will be greatly appreciated.

I hadn't mentioned the PRG pattern, but that is how these pages are being dealt with.