There you go, shows ya how much attention I am paying! I just did a search for storedproc, found none, searched for cfquery found some, and now realize they are QoQ, ok I feel stupid, I am stupid, time for another nap ;-))
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Stephen Milligan > Sent: Saturday, 6 March 2004 6:45 AM > To: CFAussie Mailing List > Subject: [cfaussie] Re: BatFink Released... > > > Which batfink are you looking at? > > The wiki doesn't even have a database, so you can't be > looking at that. > > BatFink makes no assumptions about whether a stored procedure > will be better than a standard SQL query because that's a > decision that should be made on a per project basis. > > Spike > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of > >Taco Fleur > >Sent: Friday, March 05, 2004 12:36 PM > >To: CFAussie Mailing List > >Subject: [cfaussie] Re: BatFink Released... > > > >Just curious, but why is BatFink based on using CFQUERY and no > >Stored Procedures? > > > >Also why are there no queryparams used? > > > >Hey, maybe there is a valid reason, if so, I'd like to know ;-)) > > > >Taco Fleur > >Blog http://www.tacofleur.com/index/blog/ > >Methodology http://www.tacofleur.com/index/methodology/ > > > >Tell me and I will forget > >Show me and I will remember > >Teach me and I will learn > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf > >Of Sean A > >> Corfield > >> Sent: Saturday, 6 March 2004 3:05 AM > >> To: CFAussie Mailing List > >> Subject: [cfaussie] Re: BatFink Released... > >> > >> > >> On Mar 3, 2004, at 6:21 PM, Stephen Milligan wrote: > >> > Having spent the last couple hours puzzling over it, I've > >> decided that > >> > the > >> > current approach of throwing exceptions of type validation > >> just isn't > >> > good > >> > enough. > >> > >> On the grounds that input validation is 'expected' to fail because > >> users enter garbage? :) > >> > >> > I'm currently leaning towards creating a validator service in the > >> > model that allows you to pass in form data and returns a > >validation > >> > object/structure that contains a key telling you if the > validation > >> > succeeded > >> as a whole > >> > and a > >> > struct containing message and errorcode for each field that > >> failed. The > >> > presenter can then re-route back to the original form > and the view > >> > layer can decide whether to use the message from the > model or use a > >> custom one > >> > based > >> > on the error code. > >> > >> Sounds pretty good but don't forget i18n which would require your > >> messages to be driven by locale... > >> > >> > The validation service can be called by the form action > >> method in the > >> > presenter layer before passing the data to the model to > update the > >> > database. > >> > >> Yes. > >> > >> > The question is whether or not the validation service > should check > >> > whether say a username already exists in the database, or only if > >> the username > >> > submitted has a valid length and characters. > >> > >> I think that's a slippery slope. You don't really want to mix > >> knowledge about the persistence mechanism (which in general > >might not > >> be a > >> database) with the input data validation routine. Besides, in a > >> multi-threaded environment, checking the username exists prior to > >> updating the database isn't guaranteed to produce unique > entries in > >> the > >> database(**) so you still need a constraint on the database > >and you'll > >> still have to deal with exceptions thrown for constraint > violations. > >> > >> ** Consider two form submissions from different users for the same > >> username. They press submit at the same time and both requests are > >> being processed. Both check the username and find it is not > >present in > >> the database. Both attempt to insert their respective > record. Either > >> (a) both will succeed if there is no DB constraint or (b) one will > >> succeed and the other will violate the constraint and throw an > >> exception. > >> > >> > There are also edge conditions where two users > >> simultaneously sign up > >> > with > >> > the same username and they both pass the validation check, > >but only > >> > one of them gets added to the database. The other gets a data > >> integrity error. > >> > >> Ah, yes, we're on the same page :) > >> > >> > I think I can live with the edge conditions and I'm thinking that > >> > checking for existing values in the database is probably > the best > >> > way to go, but I'm open to suggestions if anyone has a > better idea. > >> > >> I would be inclined to keep the lookup of the username out of the > >> validation itself, but perform a lookup ahead of the > validation and > >> pass the result into the validation - or pass a user > gateway object > >> into the validation. That way the validator does not need to know > >> about persistence. > >> > >> Regards, > >> Sean > >> > >> > >> --- > >> You are currently subscribed to cfaussie as: > >> [EMAIL PROTECTED] To unsubscribe send a blank email to > >> [EMAIL PROTECTED] > >> > >> MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia > >http://www.mxdu.com/ + 24-25 February, 2004 > > > > > >--- > >You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To > >unsubscribe send a blank email to > >[EMAIL PROTECTED] > > > >MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia > >http://www.mxdu.com/ + 24-25 February, 2004 > > > --- > You are currently subscribed to cfaussie as: > [EMAIL PROTECTED] To unsubscribe send a blank email to > [EMAIL PROTECTED] > > MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004 --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
