Multiget/intelligent generic PHP wrapper function... thoughts/advice wanted

[Dustin Sallings]

On Nov 2, 2007, at 15:11 , mike wrote:

>>        I'd strongly recommend you to use bindings *before* you  
>> find out
>> you're wrong about the control you're exercising.  Someday you'll be
>> entering data for Little Bobby Tables and everything will go terribly
>> wrong.  The price of protection is *really* low, and in many cases
>> can make things much faster.
>
> By parameter binding are you talking about using prepared statements
> in the SQL queries?
>
> I have never had any of my applications that I can remember suffer
> from SQL injection. I always use mysql_escape_string, the PHP filter
> functions on POST and GET data, type checking and bounds checking (for
> numeric information)

	Don't confuse not having someone exploit a vulnerability (or not  
knowing that it's been done) with not having one.  I'm quite certain  
you have a vulnerability and you've just been lucky that nobody's  
found it yet.

> That's not to say it couldn't happen but that is lower on my priority
> list and something the language already provides. I was looking to
> address the cache stuff here.

	Understood.  This middle part is definitely OT.

> I do have a generic cache_get() wrapper, I just plan on having _set
> _get etc. type functions for each type of data interaction. In theory
> I could just put in the function name in the cache_get() as a
> callback, but I do like having control, sometimes a function like
> user_get needs some additional work, not just a raw SELECT * FROM
> table WHERE user_id=$id.

	Yes, that's exactly how I designed the sample code I showed  
you.  :)  The ``cache miss'' code doesn't necessarily have to use a  
DB at all (I do this kind of stuff in one of my apps where the data  
I'm caching come from digg).

>>        ...but you're working really hard to optimize for a case  
>> that you
>> haven't proven causes any issues in your application.
>>
>>        That is to say, if PHP is so incredibly bad at iterating a  
>> small
>> array that you would work this hard to avoid it, why would anyone
>> ever use it?
>
> I think PHP is already fast, but obviously no matter what language it
> is, if the code is trying to work with too much data or is written
> like crap, it's going to be slow.

	djb has a pretty nicely written paper out mostly about the topic of  
security in qmail, but has some really good general programming points:

	http://cr.yp.to/qmail/qmailsec-20071101.pdf

	Section 2.6 refers to speed as a distraction that prevents us from  
writing better software and begins with a classic Knuth quote:

     	Programmers waste enormous amounts of time thinking about, or  
worrying about,
	the speed of noncritical parts of their programs, and these attempts at
	efficiency actually have a strong negative impact when debugging and
	maintenance are considered. We should forget about small  
efficiencies, say
	about 97% of the time; premature optimization is the root of all evil.

> I have a very nice generic non-pipelining function set already
> written, this thread was aimed to address trying to move it into
> pipelineable/multiget-compatible code, and it seemed like having to do
> multiple iterations and creating two or more arrays was overkill, once
> I noticed the key prefixes were complicating things.

	Good, you've got a baseline, then.  :)  I'd expect you'd find it  
easier to build your abstractions in your scripting language than in  
C.  Once you get them nailed down to where they're exactly right, and  
you can detect whether they're slow, then you can try to rewrite them  
and see if you can make them fast enough.

-- 
Dustin Sallings