[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