I also have a case where I get a product code from a screen and need show the product if it exists. If it doesn't exist I want to inform the user about it.
I think the idea of a configurable property doesn't sound very good. It is probably a better idea to have a new method (probably getByPrimaryKey()) with the new behavior. Any way retrieveByPK can be implemented in terms of getByPrimaryKey() in the BasePeer level. -- Humberto -----Original Message----- From: John McNally [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 4:07 PM To: Turbine Torque Developers List Subject: RE: Does this idea of merit? 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? If there are valid reasons to change the behavior, would creating a new method getByPrimayKey and deprecating the retrieveByPK method be preferable to yet another configuration property? john mcnally On Mon, 2002-06-24 at 13:46, James Turner wrote: > I agree with this. At the least, it should throw different > exceptions. But returning null is > in agreement with what other get-type functions do, like doing get on a HashMap > > James > > At 05:41 PM 6/24/2002, you wrote: > >What I don't like about this retrieveByPK() is that throws an exception > >whenever returns a number of records different from 1. I think it should > >throw the exception whenever the number of records is greater than 1 and > >return null whenever there are no records. The reasoning behind this is that > >when it returns more than 1 there is a problem with the model and it should > >be considered and error. And when the number of records is 0 it only means > >the record wasn't found but it can be very normal. The way it is now, there > >is no way of distinguishing these cases when you call the method. > > > >-- > > Humbertoi > > > >-----Original Message----- > >From: John McNally [mailto:[EMAIL PROTECTED]] > >Sent: Monday, June 24, 2002 2:03 PM > >To: Turbine Torque Developers List > >Subject: Re: Does this idea of merit? > > > > > >There is a retrieveByPK method(s). > > > >john mcnally > > > >On Mon, 2002-06-24 at 11:54, James Turner wrote: > > > I'm thinking about adding code to automatically generate a > > > "getByPrimaryKey" method to the BasexxxPeer classes. Since this is the > > > most commonly written method used in xxxPeer extensions, it would be a big > > > > > timesaver if a default "probably the right thing" version existed in the > > > base, and it should be fairly straightforward to generate as the primary > > > keys are called out in the XML. > > > > > > James > > > > > > > > > -- > > > 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]> > > > >-- > >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]> > -- 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]>
