The "addcomma", "addsemi", "adddollar" messages are a workaround, for
sure, but yeah, I suppose a more pd-ish one. I think that if SQL
gets submitted only on the right/cold inlet, then we would not need
those messages. They might come in handy though, so they could be
added later.
"bang" for submit sounds good too.
As for clever hacks, I can't think of any with regexs too. Plus from
my experience, clever hacks can often lead to really strange and
difficult bugs. IMHO, we'd better off with something simple that
might be a bit harder to start on, but doesn't have odd conditions
that could trigger bugs.
.hc
On Dec 9, 2007, at 9:26 AM, Jamie Bullock wrote:
Hi Hans,
I like this idea of a hot and cold inlet, and I can see where you are going with making the database access objects more pd-like. I also
agree that the sql/sqlend delimiters are a rather inelegant workaround for Pd's lack of a string type. What you suggest shouldn't be too hard to implement either.I have a few specific comments (see below).
On Fri, 2007-12-07 at 21:37 -0500, Hans-Christoph Steiner wrote:
That is done by sending the [submit( message to the hot inlet. Or do you mean having multiple SQL calls separated by semi-colons? If you wanted to add semicolons, there would have to be a special message, I think we could just reuse the "addsemi", "addcomma", "adddollar" messages from message boxes.
This feels like another workaround, but I suppose it's more
idiomatic pd than 'sqlend'.
As far as I know, the semi-colon at the end of the statement in SQL triggers the execution of that statement, so I can't see an advantage to having multiple, semi-colon terminated statements in a single message box. Does it change how the SQL is executed if they are submitted at the same time?
No.
The other thing I think that would have to be is forcing all input SQL to go into the second inlet. Allowing some things to go into the hot inlet, while others are required to go into the second outlet would make it difficult to use because you would have to remember which type of statement can go where...
Any SQL statement would be allowed on the cold inlet. Because of the limitations of Pd (no escape mechanism), and the fact that commas already have a meaning in Pd messages, the hot inlet would not be
able to handle commas (unless someone comes up with something quite clever).I think we should either come up with something quite clever (using regex springs to mind), or not allow queries to be submitted to the
hot inlet at all. Having a hot inlet that doesn't quite handle queries in the same way as the cold inlet is just confusing.Another suggestion: perhaps it would be even more idiomatic to use "bang" instead of "submit" as the 'quert send' message?
Jamie
-- www.postlude.co.uk
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin