Wedge

Heh, that said, he did make a valid point about it...

Technical lolcats never work out that way, sadly, but I'll nudge someone in case he has any ideas on the matter...

Don't tempt me, after all the valid debate Unknown gave on it...

I'm pretty enthusiastic about validation at the best of times, but it's not often that we do selects or similar that need anything other than int, string, or an array of ints or strings. Might I suggest, then, that we do that validation in the insertion routine instead?

It's also a performance thing: I'm not enthusiastic about making the process of physically querying any slower than it needs to be, and already there's a significant overhead vs a bare mysql_query call. It isn't a killer because we rarely make beyond 15 queries per page but it is something to bear in mind.

That said, insertion generally is something that happens slightly less often, so I'm not bothered by the notion of expanding the type validation there.[1] And yes, there's no reason we can't use classes there for that.

As for the parameterising of data, I can see both sides of it. On the one hand, your method is much closer to classic query parameters, it also limits the clutter in the query itself, while putting the validation in the SQL does make it easier for me personally write the queries, because when I'm phrasing the SQL, I am conscious of getting the type of variable right.

I'm not fussed either way as a result but whatever is used, it should be consistent.

1.	Just to really fuck with your mind, though, consider how bigint would be dealt with: true bigint cannot be dealt with actually as an int, which means the times I have done it, I've done it in a string.

I don't think the syntax needs to change at all (to be honest I'm not sure what else you could do with it anyway) and as for ease of use, I can't see any comparable way of making big queries extensible - it's harder to use than a bare query, until you're used to it, but it's extensible in a way that bare queries aren't.

And since I don't envisage most add-ons having to write them I doubt it'll be a problem, provided there is sufficient documentation and examples of using said setup to extend queries.

That's what I suspected. Can I suggest, then, that (at the very least), WHERE, and the JOINS should always be supplied as arrays to avoid add-ons having to test and coerce values to array just so they can add them in?

I like it provided that it only executes a single query otherwise there's no benefit to using a UNION.

Oh hahaha, yes, now I remember. I think I wrote that! :lol: