Re: Confused by mysqli


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.

.

Relevant Pages

  • Re: [PHP] PHP & MySQL Problem
    ... [PHP] PHP & MySQL Problem ... > actually there seems to be no problem with your query (besides that you ...
    (php.general)
  • Re: timestamp
    ... PHP newsgroup, and should be discussed in comp.databases.mysql). ... Then click on the Survey link."; ... your SQL syntax; check the manual that corresponds to your MySQL ... Your query fails because a datetime value needs to be in single quotes in the query, ...
    (comp.lang.php)
  • Re: [PHP] Architecture patterns in PHP
    ... 316 Query SHOW TABLES FROM `cake` ... 316 Query DESCRIBE `posts` ... Application and Templating Framework for PHP ... when they cache the results of reverse engineer the object model from ...
    (php.general)
  • RE: Perl Performance Help.
    ... commands to read from / dump to a file. ... you should start by running the equivalent query from ... Subject: Perl Performance Help. ... take less time to fetch the data and assign to an array. ...
    (perl.dbi.users)
  • PHPs MySQL Query Length Limit? (Long SQL failing!)
    ... I've been doing PHP for a pretty good while now, ... Then I go and use it with a mysql query. ... The query is written correctly AKAIK, but no data reaches the table I'm ... The only difference between queries that work and those that do not ...
    (php.general)