Re: Confused by mysqli

Dodger wrote:
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*


In 25 years of RDB programming I've never been able to do what you're trying to do efficiently unless I have an OO database - and MySQL isn't an OO database. Sure, I've been able to cobble things together. But the results have never been satisfactory performance wise.


I'm not surprised. Short cuts rarely are.


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


This is not polymorphism. First of all, MySQL is not an OO database. Secondly, PHP doesn't use polymorphism in this way (in fact, neither do Java, C++ or ADA).

If you want polymorphism, you:

1. Create a base class with code common to all tables (i.e. connect, disconnect)
2. Create a derived class for each table with code specific to that table, i.e. SELECT statements where column names are different
3. Instantiate the appropriate derived class where you need it.


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...


Because that's the way it works. If you want it changed, put in a suggestion to the PHP developers. Or create your own fork of PHP to include it.


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.


I've found it's much cleaner code than what you're doing, if it's done right. I cut/paste all the time, then modify for the specific instance. Really shortens my development time (and my client's costs).

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.


It's still not good practice in PHP or any other language to SELECT * if you only need one or two columns. Get only what you're going to use.

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.


Because that's the way it works. See above.

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.


In your opinion. Perhaps they have access to information you don't.

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 --
???


I can believe that. As I said before - it can be done, but I wouldn't recommend it.

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 don't know about Perl or Cold Fusion. But I agree PHP won't work. But it will work fine if you only select the columns you need.

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.


No, you're just trying to force PHP to conform to *your* idea of how programming should be, instead of adapting to *PHP's* method of programming.

There are millions of programmers who work quite well with PHP. But you have problems with it. Gee. I wonder where the real problem is?

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.


As I said - to *you* they are arbitrary. But you don't have all the facts, do you?

Try learning some good programming practices when using RDB's. Things like only selecting the columns you want. Handling tables which are different by using different code.

The problem here is not with PHP.



--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.

Relevant Pages

  • Re: database lookup
    ... the query on the subsequent page, and display the "drill down" data. ... The thing with PHP and MySQL is that you need the user to do an action ... I tried to state that I have the database designed and implemented but I ...
    (alt.php)
  • Web Developers - Happy Hearts And HDTV! - Lockergnome
    ... Certificate on your MSIIS Web server. ... getting data from a database is only half the problem. ... Zend recently started a series about building rock solid code in PHP. ... which provides bulk database conversion. ...
    (freebsd-questions)
  • Re: php vs mysql speed
    ... complex query or to have php do all the complex processing and submit ... lots of simple queries to the mysql database? ... Sometime a complex multijoin query with nested sub-queries may be ... quicker, other times it will take far longer. ...
    (comp.lang.php)
  • Re: Am I on the right track here?
    ... webpage based on data from a database query, ... PHP code loops through the records ... display the specified text from the record - title, description, ...
    (comp.lang.php)
  • Re: Techniques for Vulneability discovery
    ... in mind) so i searched the net for some free database driven software and came ... the first thing i did was grab some info about PHP programming and some MySQL ... I did some more reasearch on different types of web based "input validation" ... PHP and SQL docs, etc.. ...
    (Vuln-Dev)