Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Dragooon
661
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 10:44 AM »
Even if a string is supplied, internally it's converted into an array. An Add-on wouldn't need to test anything in order to add into the existing values.
662
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 10:31 AM »663
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 10:14 AM »
So I've been focusing on the query builder to accommodate even the most complex queries, and here's what I've had so far
For a query like this :
http://pastebin.com/LXudtCx2 (Completely made up, just to show all the SQL possibilities, not meant to make actual sense)
It can be done like this :
http://pastebin.com/dVvN11JQ
For a query like this :
http://pastebin.com/LXudtCx2 (Completely made up, just to show all the SQL possibilities, not meant to make actual sense)
It can be done like this :
http://pastebin.com/dVvN11JQ
664
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 09:37 AM »I like it provided that it only executes a single query otherwise there's no benefit to using a UNION.
665
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 09:28 AM »666
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 09:09 AM »
Line 324. Want me to post code?
667
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 09:02 AM »
I've been thinking about the whole sub-queries and I've come up with a fairly good solution, I'll treat each of them as separate query and then merge them in the main instance. This'll also properly fix UNION problems, as it is being used in Display.
669
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 07:22 AM »I thought I did...
670
Plugins / Re: Hooking up data loading
« on September 26th, 2011, 12:34 AM »
It is about memory, it can't be faster than simple fetching. Any comments about my code?
671
Plugins / Re: Hooking up data loading
« on September 25th, 2011, 10:52 PM »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.
672
Plugins / Re: Hooking up data loading
« on September 25th, 2011, 10:47 PM »
I haven't had this kind of rush since quite a while, feels good to be back. Attached are the 2 files, Class-DBQuery.php and Subs-BoardIndex containing the roughest, most brutal test this class can face.
Now I haven't handle getBoardIndex the way it's meant to be handled, simple reason being that I couldn't figure out a way to. But that doesn't make it less extensible, all the parameters are still tossed around and it is still extensible, but it is sort of a "special case" in terms of implementation, but I didn't need to make any sort of adjustment in the query class itself. This is because of the way things are set, the categories and this_category array are tossed like burger on a pan, maybe I missed it, but it works fairly well.
The definitions for SQL Params are probably incomplete in the Class-DBQuery file, but contains the most common ones used : INSERT INTO, VALUES, SELECT, FROM, LEFT JOIN, INNER JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION(I'm not too sure about this)
One's that still need to be added from the top of my head : REPLACE INTO, INSERT IGNORE INTO, RIGHT JOIN, and quite a few more.
I'll leave it at this, been coding for over 8 hours and it's 2 AM ATM.
Okay, some technicalities, I've made params to be {param} now instead of {type:param}, I've moved type out of param to PHP declaration. Makes more sense and is probably more extensible. I've no idea.
I have also removed query_<name>_result hook in favour of in-line callback handling, this allows control over the order of flow as some functions need to be executed first.
One more thing, I believe getBoardIndex is only one of it's kind, prepareDisplayContext and the likes are far more traditional. Maybe loadMemberContext is similar, I haven't dug into it.
Now I haven't handle getBoardIndex the way it's meant to be handled, simple reason being that I couldn't figure out a way to. But that doesn't make it less extensible, all the parameters are still tossed around and it is still extensible, but it is sort of a "special case" in terms of implementation, but I didn't need to make any sort of adjustment in the query class itself. This is because of the way things are set, the categories and this_category array are tossed like burger on a pan, maybe I missed it, but it works fairly well.
The definitions for SQL Params are probably incomplete in the Class-DBQuery file, but contains the most common ones used : INSERT INTO, VALUES, SELECT, FROM, LEFT JOIN, INNER JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT, UNION(I'm not too sure about this)
One's that still need to be added from the top of my head : REPLACE INTO, INSERT IGNORE INTO, RIGHT JOIN, and quite a few more.
I'll leave it at this, been coding for over 8 hours and it's 2 AM ATM.
Posted: September 25th, 2011, 10:40 PM
Okay, some technicalities, I've made params to be {param} now instead of {type:param}, I've moved type out of param to PHP declaration. Makes more sense and is probably more extensible. I've no idea.
I have also removed query_<name>_result hook in favour of in-line callback handling, this allows control over the order of flow as some functions need to be executed first.
Posted: September 25th, 2011, 10:44 PM
One more thing, I believe getBoardIndex is only one of it's kind, prepareDisplayContext and the likes are far more traditional. Maybe loadMemberContext is similar, I haven't dug into it.
673
Plugins / Re: Hooking up data loading
« on September 25th, 2011, 03:17 PM »
I'll attach the files, you can see how easy or difficult it is to code them. Give me a few hours, quite busy with other stuff. Apparently they preponed my IT exam to be held tomorrow, ah well, wasn't gonna study anyway.
674
Plugins / Re: Hooking up data loading
« on September 25th, 2011, 12:44 PM »
The query class, implementation or both? I'd be happy to do both but in case you want to see something else earlier. I'll start in 15 minutes or so.
675
Plugins / Re: Hooking up data loading
« on September 25th, 2011, 12:38 PM »
I just went over loadMemberData and loadMemberContext as well as getBoardIndex, they fit perfectly with my query model. So does prepareDisplayContext. Would anyone want me to actually code the code?