[PD] [psql] object hand-holding

[Hans-Christoph Steiner]

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