[PD] Fwd: [psql] object hand-holding

Hans-Christoph Steiner hans at eds.org
Tue Dec 11 00:03:58 CET 2007

On Dec 10, 2007, at 3:57 PM, Mike McGonagle wrote:

> On 12/10/07, Hans-Christoph Steiner <hans at eds.org> wrote:
> (What is the "hold" inlet, by the way?)
> It's a hot inlet that has been misspelled...
> 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.
> And if you want placeholders to have inlets, then we are back to  
> putting the SQL into the object creation arguments, like:
> [sqlite insert into table (id, name) values (:id, :name)]
> While I don't think it is a bad idea, it does restrict a particular  
> instance of a database object to only a single type of message, and  
> it would have to be done at creation time of the object.
> Should we allow both methods of entering SQL? One done at creation  
> time, the other one done on the fly?

> 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.
> I would think that an object having the ability to change its  
> inlets on the fly would NOT be possible, as the inlets may change  
> so much, as to lose a connection when it is recreated.
> OR, could we possibly do something like this
> [sqlite :id(f) :name(s)]
> Which would create an instance with 4 inlets, the first 'hot' inlet  
> would accept all the control messages, the next (x number) would  
> represent the bound inlets for the placeholders, and the last would  
> be the inlet for the incoming SQL statement. Would it be an error  
> if the incoming SQL statement didn't have the same placeholders  
> defined in it? Or should it be allowed to operate as any other?

This kind of thing could be done in a separate "query" object, like  
what's included in the "sqlwrappers", and [sqlite]/[psql] would still  
represent the database itself.  Having the objects structured this  
way means that Matju could write his [expr] SQL query too, and they  
would work with the different SQL database objects (sqlite, psql,  

> 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.
> My thought too...
> 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.
> This is already what I have been doing. Basically, as we are  
> working now, the SQL would get input on the right inlet, then if  
> any binding were needed, that would be done, and when the next bang  
> occurs, the query is submitted, and the first result set is  
> returned. Any subsequent bang would return the next result set. And  
> when the result sets have been exhausted, it would send a bang out  
> the "status" outlet to indicate the sets are done.

Cool, that sounds like a good idea.  I probably got it from you. :)   
Maybe you are already doing this, but a query could also send a  
message out of the status outlet to say how many results were found  
(i.e. [results 5().  This number could be routed to trigger an  
[until] or other such behaviors.  (using the completion bang to stop  
[until] probably makes more sense though).


> Mike
> .hc
> ---------------------------------------------------------------------- 
> ------
> There is no way to peace, peace is the way.       - A.J. Muste
> -- 
> Peace may sound simple—one beautiful word— but it requires  
> everything we have, every quality, every strength, every dream,  
> every high ideal.
> —Yehudi Menuhin (1916–1999), musician


"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity."        -John Gilmore

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20071210/f4f68c8b/attachment.htm>

More information about the Pd-list mailing list