[PD] [psql] object hand-holding

[Mike McGonagle]

Ok, so I spent the weekend just trying to figure out if what Hans described
is POSSIBLE at all... And NO, it is not possible in Plain Vanilla PD. You
can't create a second inlet that will take arbitrary selectors. According to
the 'pd-external-HOWTO.pdf' (by IOhannes), page 32;
"It is not possible to addmethods for more than one select to a right inlet.
Particularly it is not possible to add a universal method for arbitrary
selectors to a right inlet."

And this is exactly what Hans is proposing. The 'cold' inlet would need to
recognize arbitrary selectors. I don't know if it is possible to create a
second inlet that takes a list, as there is no function call to add a list
inlet.

The only way that I know to do that is to use Flext, and quite frankly, this
is one of the things that I wanted to avoid in the first place. If we are
forced to use Flext, then why not just get 'pool' running and be done with
this mess...

Also, I don't think the idea of having other "hot" messages, like [use
<database>( should be made into their own selectors, as ALL SQL should be
processed in the same way, and no special cases should be created. I think
it would be difficult for a user to know what SQL goes where, there may only
be a few of them, but it still makes special cases out of those bits of SQL.
The only selectors the external should recognize are ones that are for
controlling the external itself.

So, if anyone has any ideas, I think I am just going to continue with what I
have, you can use it if you want, but quite frankly, this is very
frustrating when a suggestion like this comes from one of the lead
developers, and it turns out not to be possible. I am not really thrilled
about using Flext, as it is not part of the Extended build, and it is not
part of Vanilla-PD (also, I have never been able to get anything to compile
on my machine with Flext, not so say I put forth a huge effort, as I like
things to be as simple as possible). I didn't want to force a user to have
to download and install any additional packages (which include not just PD,
but an extra database).

Or am I just freaking out over nothing.


Mike


On 12/9/07, Hans-Christoph Steiner <hans at eds.org> wrote:
>
>
> 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
>
>
>


-- 
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/20071209/b6e1e7d1/attachment.htm>