(As the other thread seemed to diverge greatly in topic, I figured this might be a time to branch off and discuss what we are trying to implement)
So, can we take a step back and figure out exactly what we are doing? It seems that even within the thread itself, we have changed the Object Model a LOT... From what I have read, this is what I now understand the model to be...
[mySQL-Connection id-symbol <connection info>] <-- a PD object representing connection
[SQL-Query id-symbol <sql statement>] <-- an SQL query object
The first object, the Connection, takes a symbol that identifies itself to PD, and optionally the connection info. The second takes a symbol linking it to a Connection object (this linking can also be changed to point to another connection using a control message), and an optional SQL statement for Placeholder Inlet creation. This method will "bind" those inlets into the SQL statement. If there is no SQL statement, no binding is allowed using that object, and all SQL come to a cold inlet, using PD messages (variable stuff can be put into the statement via PD's $ mechanism).
The connection object responds to the following
open/connect - to open a file (in an embedded database) or connects to server
close/disconnect - close the file or breaks the connection
As the connection object can represent any database, its named <dbname-connect>. A MySQL database would be [MySQL-connect ...], sqlite would be [sqlite-connect ...], etc. A connection object provides a single outlet to provide status about the connection (similar to a [netsend] object). There is a single inlet used to control the connection object.
The query object responds to the following
buffer - to change the size of the SQL input buffer
results - to change the size of the results buffer
bang - submits the initial query, and outputs a result set for each bang
clear - clears the SQL buffer
addsemi - appends a semicolon to the SQL buffer
addcomma - appends a comma to the SQL buffer
adddollar - appends a dollar sign to the buffer (do we need this?)
If the query is created with an embedded statement, any placeholders will generate an inlet. No cold inlet for SQL will be created.
If the query does not have an embedded statement, it will provide an arbitrary inlet that accepts SQL to process.
The query object has 3 outlets, the first outputs a list for each result set (on each subsequent bang, very much like a [textfile] object), the second will outlet a float representing the ROWID of the last insert statement, and the third outlet indicates the status of the query, with a bang indicating the end of the result sets, a symbol or a list is a status message from the database.
*************************
Does this sound about right? I would like to have a clear outline before I start coding anything.
Thanks,
Mike
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list