I would say using data with meaning is not a good way to design a
schema. A user should have no way of knowing pk, so they would be very
unlikely to enter one. Not that it would never be entered for example
by picking an option from a select, but in this case the app is
supplying the correct values for the pk's. If a user hacks the form
parameters and gets zero for retrieveByPK it would be an exceptional
condition. What happens if a user changes their username, or the column
must change from a max of 6 characters to 16 characters to support a
customer request. Using it as a foreign key is going to complicate
these kind of changes.
That said torque does not require this "best practice" to be followed.
And a distinction between 0 and more than 1 values would be good. If
someone submits a patch that creates a new method and deprecates the old
I will submit it.
Hopefully any developer opposed to this strategy will speak up now.
john mcnally
On Mon, 2002-06-24 at 14:11, James Turner wrote:
> At 05:07 PM 6/24/2002, you wrote:
> >I think it is more likely that calling retrieveByPK returning 0 results
> >is an error than doing so with a Map get method call. Where did the PK
> >that returned 0 results come from? There is a pending patch to make the
> >exception vs. null configurable with a propery. I'm not sure I want to
> >go this way though. Can anyone provide me with some use cases that
> >supports the use of null vs. throwing an exception. i.e. when is it not
> >an exceptional condition?
>
> Here's a simple code fragment that shows an obvious use case:
>
> username = request.getParameter("username");
> User u = UserPeer.retrieveByPK(username);
> if (u == null) {
> response.sendRedirect("noSuchUser.jsp");
> } else {
> request.getSession().setAttribute("loggedInUser", u);
> }
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
