[PD] SQL Object Model was: [psql] object hand-holding

Mike McGonagle mjmogo at gmail.com
Wed Dec 12 03:29:47 CET 2007


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 <mjmogo at gmail.com> 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
>
>
>
> _______________________________________________
> PD-list at iem.at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20071211/7dcc1eb9/attachment.htm>


More information about the Pd-list mailing list