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.
Ciao