[PD] [psql] object hand-holding

[Hans-Christoph Steiner]

Since both the current Pd-SQL devs (Mike and Jamie :) have posted to  
this thread, I want to bring up the interface again.  What do you  
guys think about the two inlet interface for SQL objects?  I just  
find the sql/sqlend thing very strange, and it could end up being  
difficult to work with.  I see the interface like this: the hot inlet  
is for meta commands, like "open", "close", "export", "connect",  
etc.  Then the second, cold inlet is for building SQL queries.   
Having a cold inlet devoted to building SQL queries would mean that  
you would not need any special "sql/sqlend" style tags at all.

Instead, you'd just send messages to the cold inlet, those messages  
would be appended to the existing SQL message buffer.  Then when the  
query is ready to be sent, send a "submit" or "run" or whatever to  
the hot inlet, and it would run the buffer from the cold inlet and  
clear it.  There would also be a "clear" command to just clear the  
buffer without sending it.

This would allow for the comma trick, etc. and I think it would fit  
better into Pd's message processing.  In addition, there could be a  
single line message for the hot inlet, like this:

"submit insert into mine (name) values ('the_text')"

I'll help implement this if you want.  I just have a strong aversion  
to the "sqlend" stuff since I think it could end up being strange to  
use within Pd.  Plus I think these are very valuable objects to have,  
so I think it's important to get the interface right.  Basically, I  
am thinking of something along the lines of the [textfile] interface,  
as much as possible. Here's a sketch:

__hot inlet__
[open $1(
[close(
[export $1(   - this could be used to export the database to a .sql file

[clear (
[submit (
[submit insert into mytable (name) values ('$1') (


__cold inlet__
[insert into mytable (name) values ('$1') (
[CREATE TABLE datatable(id INTEGER, duration FLOAT, type VARCHAR,  
datetime DATETIME)  (
[SELECT id, ABS((duration - 1500)/1500) AS error FROM datatable ORDER  
BY error LIMIT 1(

Also, on a different note, I think it could be useful to have various  
status and meta data queries output on the second inlet.  Currently  
in [psql], there is just a bang on complete.  But there could be  
things information about the database that aren't available via SQL.

Finally, there is the source code for the Max/MSP mysql external, so  
I think it should be pretty easy to make a mysql version of this  
interface as well.  Then we'll have a nice trio of SQL options:  
embedded, PGSQL, and MySQL.

http://www.publicbeta.cx/maxx/

.hc


On Dec 7, 2007, at 4:32 PM, Mike McGonagle wrote:

> Andy, have you had a chance to check out the SQLite external yet?  
> You can get a copy of it here ( http://puredata.info/Members/ 
> mjmogo ), the latest version is 0.13. While this is still under  
> developement, it is based on the work of Jamie (and others), as far  
> as how the SQL is handled. They are not exactly the same, but I  
> would like to make that one of the goals so that these things can  
> be interchangeable.
>
> One thing that I have not done yet is implement any kind of Blob  
> data types. It appears that SQLite3 (not the external, but the  
> database) handles Blobs as binary strings. I still don't know quite  
> how this would work in PD though. I would like to get some feedback  
> from others about how to do this.
>
> As SQLite3 stores its database in a file, rather than a server,  
> there is no need to set up anything for the database (other than  
> designing the tables). Also, if you need to, you can use the tools  
> from SQLite3 to work with the same database file.
>
> I work on the Mac, so the Makefile is setup to build a Universal  
> Binary (thanks to Hans). If you are on another platform, it  
> shouldn't be difficult to compile these things, as SQLite3 is pure  
> ANSI C. When I compile it, there are a lot of warnings generated,  
> but everything works fine. I guess I should turn off all the  
> warnings for that part of the compile.
>
> But, let me know if you try this. I am eager to see how it works  
> for others.
>
> Thanks,
>
> Mike McGonagle
>
>
> On 12/7/07, andy.graybeal at casanueva.com <  
> andy.graybeal at casanueva.com> wrote:
> i installed postgresql, and got it running, created a user for myself,
> compiled [psql] from postlude (i'm using pd-extended from cvs).
>
> i opened up the psql-help file and started with the first  
> instruction, and
> it created the database fine, i moved to the second command and get  
> this
> error:
> psql: Action failed. PQresultStatus is PGRES_FATAL_ERROR
>
> i'm wondering where i can look for more information about what is  
> going
> wrong, and what i can do to fix it.
>
> i think it would be wonderful if i could start using a database to  
> store
> values :)
>
> -andy
>
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list
>
>
>
> -- 
> 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
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



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

If you are not part of the solution, you are part of the problem.


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