So, I guess I will just assume that this is what we were discussing, until someone tells me different. Mike
On 12/11/07, Mike McGonagle <[EMAIL PROTECTED]> wrote: > > (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 > > > > _______________________________________________ > [email protected] 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
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
