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 statementWith 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