On Dec 10, 2007, at 2:07 PM, Mike McGonagle wrote:
---------- Forwarded message ----------
From: Mike McGonagle <mjmogo@gmail.com>
Date: Dec 10, 2007 1:07 PM
Subject: Re: [PD] [psql] object hand-holding
To: jamie@postlude.co.uk
On 12/10/07, Jamie Bullock <jamie@postlude.co.uk> wrote: Good point! I think Hans' recent suggestion addresses the problem. It
also occurs to me that for Postgres at least, we have the PREPARE
statement, which addresses the optimisation and injection issues you
have raised. Technically [psql] already supports PREPARE except that
PREPARE uses the '$' character as its placeholder identifier, and '$1'
can't be passed around as a symbol in Pd. I think it might be
interesting to use the '?' notation currently under discussion as an
interface to PREPARE though.
One of the things that I have been reading on this is that when you use these 'pre-complied' SQL statements, you need to 'bind' each of the variables with their types to a specific function. (Also, I kind of like the ':' syntax, as it puts a name to the data within the statement.) I also think that we would need to do something like
[insert into table (id, name) values (:id, :name) ( <-- sent to the cold inlet
[bind :id float( <-- sent to hold inlet
[bind :name symbol( <-- sent to hold inlet
[:id 1 ( <-- sent to hold inlet
[:name john ( <-- sent to hold inlet
[bang ( <-- sent to hold inlet
and then we would be able to put all the data into the database with the expected types. At least SQLite and libdbi use these 'bind' functions to associate the expected datatype with the input data.
(What is the "hold" inlet, by the way?)
It would be really nice to be able to have inlets for the sql placeholders, but I couldn't think of a clean way to do it. We could try the dynamic allocation like you say here, I don't know if I have a specific objection to it, but it could get weird. Since the SQL inlet has to be cold to support the comma hack, then these dynamic inlets shouldn't be hot since they are the right of a cold inlet. But that's not a big deal.
Also, I don't know if any objects do this kind of dynamic inlet creation after the object itself has been instantiated. It might not even be possible. I figure that you can easily make a subpatch or abstraction around the SQL message generation, then manage the inlets there. Perhaps not ideal, but it's not difficult to do and follows existing practice.
As for the SQL binding, I was thinking it would happen inside of the object, binding the placeholder names to the selectors. As long as there wasn't any new input on the SQL inlet, then the SQL statement wouldn't need to be recompiled.
Another question I just thought of it how to handle returning multiple results from s single query. If it followed the [textfile] style, then you would have to bang to get each individual result, then keep banging until you get a bang on the status/second outlet, meaning the query was done. I think this could work.
.hc
----------------------------------------------------------------------------
There is no way to peace, peace is the way. -A.J. Muste