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

[Hans-Christoph Steiner]

On Nov 7, 2007, at 2:35 PM, Frank Barknecht wrote:

> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>
>> AFAIK, MySQL and the like do not guarantee realtime responses, and
>> network connections certainly do not. So if want something that is
>> designed to do that, then use [pool], [textfile], or perhaps an
>> embedded SQLlite, if it is quick enough.
>>
>> Unless there are ways to guarantee the database will reply within one
>> clock tick (usually ~1.5ms), then the interface should represent the
>> reality of the situation.  Otherwise the database object will cause
>> lots of clicks and interruptions when used.
>
> SQLite is fast. In most cases, MySQL etc. will be fast enough as well,
> but of course no common DB gives realtime guarantees. But neither does
> [textfile], e.g. when responding to the "read"-command: Loading large
> textfiles will halt execution as well. (Btw: An important use of SQL
> in Pd would be as a  replacement for [textfile] if you need to parse
> tons of data, like gigabytes, as you can read row by row in
> nanoseconds with a realtime response that would be better than
> [textile] by miles.)

> Pyext's approach of offering threading as an option is the most
> flexible and it's what first inspired my remark. If you want to use a
> sql-db as a way to store and load data for use in your logic, you
> often *need* deterministic behaviour. Of course then it's in your own
> responsibility to make sure you meet the deadlines, for example by
> optimizing queries, using fast, local DBs etc.
>
> But the need to do deterministic queries sometimes (or rather often)
> must not be ignored by designing a SQL class for Pd with only threaded
> use in mind.
>
> As databases can be used in so many different ways, I still favour the
> DIY approach using Python or Lua or so anyway. It's again a use case,
> where not the interpreted language is the bottleneck, but an outside
> factor. A C-class for SQL querying wouldn't be any faster than the
> (existing) Python/Lua classes, if the database is too slow.

Using threads in a Pd objects without representing it in the  
interface is a recipe for very difficult bugs.  Talk to Max/MSP about  
bugs in "Overdrive" mode.  Most people solve them by turning off  
overdrive, from what I hear.

Making the interface reflect the threaded nature doesn't have to be  
complicated.  It could just be that you give each query a message ID  
which is prepended to the result.  A deterministic database query  
object will cause interruptions, especially if there is any network  
activity involved.  It would be a shame to have a database object  
that couldn't be used with realtime audio, video, etc.

I think the bigger issue is that people want to use Pd to interface  
all sorts of things that can't be deterministic.   So it would be  
good if we figure out how to make that work well in the context of  
programming in Pd.  "It's pretty good, but it interrupts sometimes"  
doesn't sound like a goal to strive for.

.hc




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

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie