SELECT field, other_field
FROM table
WHERE member = 1SELECT field, other_field
FROM table
WHERE member = 1
AND field = 'test'(
SELECT DISTINCT t1.field1, t2.field2
FROM wedge_table1 AS t1
INNER JOIN wedge_table2 AS t2 ON (t1.field3 = t2.field4)
INNER JOIN wedge_table4 AS t4 ON (t4.field7 = t2.field7)
LEFT JOIN wedge_table3 AS t3 ON (t3.mem = t2.mem)
WHERE t1.member = 5 AND (t2.field6 = 0 OR t3.field6 = 0)
GROUP BY t1.field1
HAVING t1.field1 = 'test'
ORDER BY t1.member ASC
LIMIT 1, 50
) UNION ALL (
SELECT IFNULL(m.name, mem.name) AS name, mem.id_member
FROM wedge_mems AS m
INNER JOIN wedge_members AS mem ON (m.id_member = mem.id_member)
WHERE m.id_member IN (
SELECT p.id_member
FROM wedge_players AS p
WHERE p.field IN ('hockey', 'cricket')
)
ORDER BY mem.id_member DESC
)Trouble is, I don't think there's a nice way to deal with it, except on a case by case basis.
I'm tempted to say that INSERT/REPLACE should not be extended in this way but have the parameter list and rows passed to a hook instead to be manipulated (there are no raw INSERTs carried out in the source, they are all done by wesql::insert, and I'd suggest we leave it that way - it is cleaner to do that by not having add-on authors having to deal with the queries' parameterisation)
Also, prepareDisplayContext is pretty unique, everywhere else just processes rows into an array of some form. getBoardIndex is atypical, though, but it's still ultimately running a query and pulling rows into an array.
I'm tempted to say that INSERT/REPLACE should not be extended in this way but have the parameter list and rows passed to a hook instead to be manipulated (there are no raw INSERTs carried out in the source, they are all done by wesql::insert, and I'd suggest we leave it that way - it is cleaner to do that by not having add-on authors having to deal with the queries' parameterisation)
Also, prepareDisplayContext is pretty unique
I thought I did...
I like it provided that it only executes a single query otherwise there's no benefit to using a UNION.
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.
| 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'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's the thing; I don't especially want to expand the validation at point of general query, but I would do so happily at the point of data insertion.
Especially the query builder example I posted on previous page.
I am 1500 lines late on my plugin code review. I don't even know how it works...
Well, more for boasting about when places get hacked into and sharing all the details of who did so :/
Even though it extends wesql, it it does its own queries instead of calling wesql for its needs. Sounds silly to me and should be changed.