|
|
Posted by Jerry Stuckle on 12/17/74 11:52
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@attglobal.net
==================
Navigation:
[Reply to this message]
|