On Wed, 2002-11-27 at 15:49, John McNally wrote: > I'm guessing this was a result of hitting Send to quickly, did you want > this to go to torque-dev? >
Yes you're correct, I didn't notice that scarab sets a different reply-to. > I will note that the retrieveByPK method is usable in its current > state. When I wrote the method, the intention was that you should not > call it with a random number, but one that is known to be a the pk of > some row. But allowing its use as a way to determine if a certain value > is a pk is reasonable I guess. The problem is the traditional stateless nature of HTTP. The row in the database did exist, but might have been deleted before we attempted to access it. This is a small error that the application should be able to handle gracefully. The other extreme is the case where there are multiple results, which would indicate a major failure on the database softwares part. It seems to me that TorqueException traditionally indicates a major failure that my application is not going to be able to solve on it's own. > I'm not sure why you disagree with calling the new method > getByPrimaryKey. Part of the reason I don't like that method name is that it is following the bean pattern, even though it isn't returning a "ByPrimaryKey". I think it will also confuse developers... "Why is there a get and a retrieve?" I've added the getByPrimaryKey methods to my copy of Torque, so I can upload the patch if people really want to do it this way. It involves a lot of duplicated code, someone else may want to modify retrieveByPK to call getByPrimaryKey. I don't really understand aliases, so I don't understand what all that code is trying to accomplish. -james -- James A. Hillyerd <[EMAIL PROTECTED]> Java Software Engineer - http://www.whynotown.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
