On Dec 31, 2007 2:45 PM, Hans-Christoph Steiner hans@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

On Fri, Aug 22, 2008 at 10:08 PM, glerm soares organismo@gmail.com wrote:

...

...

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.

The makefile is just for pd_darwin ?

How could I compile it on linux?

Well, this is currently not something that I am working on. The last state of the code is that it will allow you to pretty much execute any SQL statements you send to it, but as far as such things as "Placeholders", those have not been added.

If you want to compile this under Linux, you should be able to take any other Makefile for an external, and convert it to work with this. The SQLite code should compile without any trouble, as it is Pure ANSI C, and the Makefile for that is pretty current.

Also, do note, that the version of SQLite is NOT the latest version. I think the last version that I was using was something like 3.5 (if I remember correctly).

Mike

glerm