Posted by Dodger on 07/08/06 10:23

Jerry Stuckle wrote:

> They are two different tables - so typically they have two different
> routines. In this case one size does NOT fit all.

> And why is that? You're accessing different data - so you need
> different code.

But you *shouldn't* need different code...
*drops face into hands*

> I'm not surprised. Short cuts rarely are.

I'm not talkin g about a shortcut, I'm talking about polymorphism.

> That's right, because you're trying to mix bind and non-bind functions.
> It doesn't work.

> No, there's nothing wrong with the syntax. But there are no results to
> return the way you're doing it. You used mysql_bind_param to bind the
> parameters so you need to use mysql_bind_result to get the results back,
> not mysql_fetch_assoc().

> Yes, because you're not binding the parameters.

> You're trying to mix apples and oranges. It doesn't work.

> People have tried to create generic libraries before. Some of them,
> like Pear::DB, are pretty decent. Others are not so good.

> If you insist on using bound parameters, you *must* use bound results.
> It doesn't work otherwise. And if you need to know the column names,
> you need to fetch the metadata.

See, that's where I'm not seeing any sense to this. Returning a row
from a database as an associative array seems *basic* to me, and should
always be able to be done. Further, using bind variables in order to
execute an equation also seems simple and basic to me.

What doesn't make any sense to me is *why* they wouldn't be allowed...

> Now tell me - how long have you been fooling around trying to get this
> to work - vs. how long it would have taken you to copy/past/modify the
> code to work with different tables in the first place? It could have
> easily been done by simply creating separate classes for each table,
> reuse common code (or better yet, derive all from a common base) and add
> code to handle the unique stuff.

Quite honestly, that doesn't matter in the grand scheme of things.
Copying, pasting, and modifying code is not a good coding practice.
It's not clean code.

When I started using MySQL with Perl back in 1998, I did stuff like
that. I'd write queries like:

SELECT *
FROM session
WHERE id = '$sessionid'

After carefully checking sessionid for the existence of a ' and stuff
with regexes. I later learned *not to*... not because of Perl, but
because of good coding practices.

And I don't see any rationale for *why* I shouldn't be able to call
fetch_assoc() on a query I prepared with bind variables, nor do I see
what tying results to variables has to do with submitting a query with
bind variables have to do with each other, except that whoever
originally wrote the mysqli interface stopped halfway on the API.

Binding variables into the query has *nothing* do to with binding (we
perlmongers call the latter case tying) the results to variables.
Except that someone inscrutably wrote it that way.

Anyway I tried to work around it... I tried an eval. I went through the
metadata which I *could* gat back from a bound query and generated a
string of code to do all the result binding.

So things escalated to a new level of inscrutable. It didn't work. The
eval raised an exception about an unexpected '$' in the eval string --
???

So I had it print out its eval string that it was trying to run. Then I
copied *that* and pasted it in to see if I could get a more detailed
answer outside of an eval...

It worked fine. Got everything back.

Anyway I have put up a comparison of three scripts that would do the
same thing, one in Perl, one in PHP, and one in ColdFusion.

http://www.xfx3d.net/scriptcompare/

There's one main difference between all three's functionality:

If I do the following in MySQL:

ALTER TABLE session
ADD spork VARCHAR(12)

The three scripts will react differently.

Perl will continue to function and do everything expected. It will
press on and add in a SESSION_SPORK environment variable.

ColdFusion will continue to function, but it will ignore the spork
column and thus will work *exactly* as it did -- without setting the
SESSION_SPORK environment variable. ColdFusion does have proper
bind_params too, but the database itself must support them. However in
a cfquery it's my understanding that it automatically escapes the input
anyway (don't use my statement as a citation on Wikipedia or anything
-- I'm not a big CF person, just some small experience and could be
totally wrong about that) and thus works the same pretty much.

PHP will fail to run at all, because bind_result will not have enough
arguments anymore.

I will look into this Pear::DB thing. But if it won't do the job right
either, I think I am going to have to give up on using PHP for the task
I had in mind. Sorry. I tried. I really did give it a shot.

Just if there's not a solid and functional database abstraction layer
that works right and doesn't make arbitrary rules about 'if you bound a
parametre on the query you have to tie the results' and so on... then
PHP doesn't appear to be ready to me.

[Back to original message]