[PD-dev] SQLite for PD v0.0

Hans-Christoph Steiner hans at eds.org
Tue Dec 4 23:32:18 CET 2007


On Dec 4, 2007, at 12:49 PM, Mike McGonagle wrote:

>
>
> On Nov 30, 2007 11:39 PM, Hans-Christoph Steiner <hans at eds.org> wrote:
> If you use a selector for every message into this object, then you  
> can get rid of the "sqlite" prefix, and it would be very natural  
> for people used to Pd.  For example:
>
> [open $1(
> [close(
> [export $1(   - this could be used to export the database to a .sql  
> file
>
> This is doable...
>
> Instead of commas, you could reuse the same message used for  
> message boxes [addcomma(.  Plus [tkwidgets/text]  (its in Pd- 
> extended now) will allow you to type commas and have them sent in  
> messages, but they'll be escaped.  Here's an example combined the  
> syntax of [textfile] and message boxes:
>
> [clear (
> [add insert into mytable (name (
> [addcomma (
> [add id (
> [addcomma (
> [add  data) values ('$1' (
> [addcomma (
> [add $2 (
> [addcomma (
> [add $3)  (
> [submit (
>
> It's not pretty, but it follows Pd-style messages and it would work.
>
> At the same time, doing it in the fashion we are now would make it  
> more SQL-like. While I understand the idea of doing things in a PD- 
> like way, taking it too far, and mangling the SQL might make the  
> object almost unfriendly, if not downright unusable. Trying to keep  
> the SQL as close to the real syntax, I think is very important.
>
> It would be nice to hear from others on this topic. Anyone?

Ah, I get it, you are re-inserting the commas that Pd is interpreting  
based on their being a message that does not start with "sql" or  
"endsql"?  In that case, I think it makes sense to have a separate  
"sql" inlet.  I just have a strong aversion to having an atom at the  
end of the list cause the execution of something, in effect to act  
like the selector.  Pd's whole list handling is built around the idea  
that the selector is always the first element, and the rest are data.

So the first, hot inlet could accept the "open", "close", "export",  
"clear", "add", and "submit" messages.  Then the right, cold inlet  
would just accept anything and append it onto the end of what's  
there.  This is also something of a violation of Pd's standards for  
interfaces, but I think a much less egregious one.

Another possibility would be to have the submitsql message only cause  
a reaction if it was selector of the current message, but I think  
since this interpretation of the commas is non-standard, it would be  
best if it had its own inlet.

.hc

------------------------------------------------------------------------ 
----

There is no way to peace, peace is the way.       -A.J. Muste


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20071204/55a15a42/attachment.htm>


More information about the Pd-dev mailing list