[PD] SQLdb V0.0 is posted

[Mike McGonagle]

On Dec 31, 2007 2:45 PM, Hans-Christoph Steiner <hans at eds.org> wrote:

>
> I took a look at it.  It is nice to be able to handle the results right
> next to the query, but I find the send/receive as first argument confusing.
>  I think the objects should use inlets and outlets and then people who want
> to use send/receive could it themselves.  I can understand wanting to handle
> the queries separately from each other, but I think this can be accomplished
> using standard Pd message handling methods (lists, [route], etc).  I'll try
> to come up with a working sketch soon.
>

You can think of each send/receive SYMBOL attached to a database object as
being a separate data channel. As we are restricted to one set of results in
each database object, you can create multiple datapaths by using more than
one database object, and giving it a different name. This way, two different
query objects can make a request into the same database (using two different
database objects opening the same database) at the same time. If these two
queries were to send the requests to the same database object at the same
time, they would interfere with each other, and would lose result sets.

Also, if we are going to make these connections between the objects as you
suggest, just how would the database know which query object to send the
result sets back to? I really don't like the idea of having all the data
come out of the database object. That would force a user to build some sort
of routing mechanism into their PD code, and in order to do that, you would
have to write your SQL queries such that each was tagged with some symbol
indicating its purpose.


> I think that the database object could have a data and a status outlet,
> like [hid].  Then the status info could all be handled centrally wherever
> the single sqlite object, then data would be routed to where it needs to go.
>  Real world examples would be good to have now, I suppose we can look to see
> how people are using [pool] and PDContainer, or even [sqlsingle] and the Max
> MySQL object.
>

I have no idea what 'hid' does. So, I really don't understand what you want
here. I will have to read the paper on it...

As far as the "status" goes, I think that is something that should also be
handled by the query object, as that is the object that actually generated
the "status" message. The only status messages I see coming from the
database object itself, are the ones dealing with the connection to the
database (either by using 'open' or 'connect').

And I still don't know why you want the data to come out of the database
object. It just doesn't make any sense to have different query objects that
send their queries to the database object, and then have those results come
out of a central location. While I know that we could set it up so that each
query result set would be tagged, and then route the data based on that, I
just think it is better to have the data come out of the query object.


> About "addsemi" I am starting to think that it should really only be there
> for specific circumstances and not for regular use.  I think that if you
> execute a sql query by sending the data thru, it should just use whatever is
> in the SQL cold inlet buffer and add a semi-colon to it.  Also, I think it
> would be good to avoid using semi-colons inside of the SQL in object boxes (
> i.e. like in the [sql_query] example that I posted).  This makes each
> sql_query a single SQL statement, which I think is quite clear, plus it
> could be tricky implementing the semi-colon handling.
>

I don't like the idea of automatically appending a semicolon. I think that
everything that is in the SQL buffer should be put there by the user, and
the external should do nothing to that buffer, except send it to the
database. I also still see no restrictions on being able to send multiple
SQL statements in the same packet, as that restriction does not exist in the
standards. It is only a few databases that put this limitation on to their
own operation to get around certain problems. Things like SQL injection,
something I don't really see as being all that big a deal, it should be
something left to either the database administrator to protect against, or
the application developer. This is a framework we are creating, and we
shouldn't be putting any limitations on how it can be used.


>
> Anyway, those are some rambling thoughts. It's great to see progress on
> this, hopefully we can get some people to try out the sketches to see what
> actually works.
>

Anyone with question, please feel free to ask.


Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20071231/5e7e1b77/attachment.htm>