I'm not a big fan of [expr]'s syntax since it is custom syntax that is not used anywhere else in Pd. Instead, you could achieve the same result by using the interface I described, then embedded your SQL statements with [sql] into a subpatch or an abstraction. This just about any regular Pd user knows how to do.
.hc On Dec 8, 2007, at 12:51 AM, Mathieu Bouchard wrote: > On Fri, 7 Dec 2007, Hans-Christoph Steiner wrote: > >> That is done by sending the [submit( message to the hot inlet. Or >> do you mean having multiple SQL calls separated by semi-colons? >> If you wanted to add semicolons, there would have to be a special >> message, I think we could just reuse the "addsemi", "addcomma", >> "adddollar" messages from message boxes. > > The only SQL interface I'd really be happy to use (if I had to use > SQL) is something using placeholders, sort of like [expr], but > perhaps written in the usual SQL style: > > [sql select * from candies where flavour=? and colour=?] > > you wouldn't modify the statement any more than you modify an > [expr] at runtime. this allows the statement to be precompiled by > the server. you could still allow runtime change but perhaps it > would get messy with multiple inlets, so let's assume for now that > it is not supported. > > in the above example, [sql] has two inlets, one for each question- > mark. Sending a list in the hot inlet is also correct, and "set" > and "bang" do as usual. Each value will be quoted automatically, > with appropriate apostrophes and backslashes and stuff, so that the > user never has to do it. (my biggest problem with PHP is the lack > of this feature). > > an alternate way to do it is to use the same syntax as [expr]. This > allows a repeated value to not have to be repeated in the input to > the object. However, this means that values are going to be typed, > which is a bad match with SQL, which doesn't type values (it only > types table cells themselves and casts everything automatically). > >> As far as I know, the semi-colon at the end of the statement in >> SQL triggers the execution of that statement > > With this interface, there would be no semicolon at the end (or it > would be optional and useless). The execution is done each time the > hot inlet is activated (bang, float, symbol or list, but not others > like set and whatever else if there's anything else). > >> so I can't see an advantage to having multiple, semi-colon >> terminated statements in a single message box. Does it change how >> the SQL is executed if they are submitted at the same time? > > Multiple statements are compiled as one function to which you pass > all arguments you want at once. This could be useful if you want to > do both insert and select in one go. It may be a bit faster, or > maybe not, but it's convenient. > > [expr] supports semicolons and uses them for multiple outputs. For > [sql], it might make only sense to have one outlet per query rather > than by statement: that is, only SELECT and EXPLAIN and such would > get an outlet, while INSERT and DELETE wouldn't, for example. > > At this point, I can't think of a case where I'd like to modify a > SQL statement at runtime. Somehow it's possible to find a use, but > I think that for almost everything you don't. > > _ _ __ ___ _____ ________ _____________ _____________________ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada ------------------------------------------------------------------------ ---- I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
