[PD-dev] Connecting up an SQL Database to PD

[B. Bogart]

Hi Mike,

I wonder what things would be like if you could suck SQL data directly
into data structures. This way they could be highly structured and
perhaps altered in PD.

I've often thought about data structures to store data only, and not
graphics, which I suppose would be a good idea with lots of lots of data
in it.

Being able to put a huge table into a gridflow matrix (of symbols) could
be interesting, I don't know if you can have a grid of symbols (or
strings) in gridflow...

.b.

Mike McGonagle wrote:
> Hello all,
> 
> It has been several months since I first inquired about this idea, and
> it seems there are some out there who think this would be a good idea.
> So, in the interest of figuring out just how this could work with PD,
> I would like to start a discussion about what sort of interface
> objects should be created.
> 
> 1.0 What the objects would look like.
> My first thought is to design them so they operate like other already
> existing PD objects. While there may not be a perfect match with other
> objects, I am thinking more along the lines of what commands they
> recognize and their basic functionality.
> 
> While I don't have a specific idea for how to implement these
> connecting objects, I think that there would be three (or more)
> different PD objects instantiated to work with a database. One object
> to handle the connectivity, one object to handle the querying, and a
> third to handle any results coming from a query.
> 
> A. While there could be multiple connectivity objects, each one would
> point to a different database. This could be used to construct several
> data paths, and each connectivity object would be passed a symbol to
> use as a name for its data path. This name would then also have to be
> passed onto each query and results object to link them to a particular
> data path. (Does this need more explaination?)
> 
> B. There could be more than one query object, each one handling a
> different query type (as PD doesn't really support strings, it might
> be difficult to build a whole SQL statement using commands via an
> inlet).
> 
> C. There could also be multiple result object, each "listening" for a
> different parameter set.
> 
> 2.0 Data Types, SQL, and PD
> So far, the biggest hurdle that I see with this is Data Types. As PD
> doesn't have much support for strings, there would either have to be
> special handling involved, or we just agree that a string in this
> context would be a PD symbol. Also, all the other datatypes (with the
> possible exception of a BLOB) would not really have a PD equivelent.
> But then again, how might binary data be stored to a BLOB from within
> PD?
> 
> 3.0 Linking data into PD
> Another idea for connecting the data from the database into a PD
> patch, would be to map each of the fields in the database table to a
> particular PD variable. While this might allow for increased
> interaction, it would eliminate the use of any symbols returned from
> the database.
> 
> 4.0 Version 0.0
> As this is still in this design stage, there are some things that I
> would like to put off dealing with until there is a working set of PD
> objects.
> 
> A. Currently works with one database. As there are so many different
> types of databases out there, and most of them require additional
> components to setup and configure, I would like to keep this as simple
> as possible. Currently my idea is to use ONLY SQLite, as a backend.
> This would be compiled directly into the PD external, as the SQLite
> code implements a full SQL database in a single source file, it is
> pretty easy to link this up directly without any other programs to
> install.
> 
> B. All databases need to be designed externally. This means that no
> CREATE TABLE functions or other commands that would manipulate the
> database schema. This might be a problem is you need to create tables
> on the fly, but I would think that we could get a good start on the PD
> interface, and then take this idea up later.
> 
> ***************
> 
> So, if any of you have any ideas on this topic, please feel free to
> jump in and add your $0.02. It would be very much appreciated.
> 
> Thanks,
> 
> Mike
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>