« [Plugin] Notifications system (1.0)
Hooking up data loading
[Plugin] Awards »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Hooking up data loading
« Reply #15, on September 25th, 2011, 10:49 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.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Hooking up data loading
« Reply #16, on September 25th, 2011, 10:52 PM »
Quote from Arantor on September 25th, 2011, 10:49 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)
Fair enough.
Quote from Arantor on September 25th, 2011, 10:49 PM
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.
But it fits into the norm far better than getBoardIndex, It pretty much acts like a result callback and hence is much easier to implement in the flow.
The way it's meant to be

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Hooking up data loading
« Reply #17, on September 25th, 2011, 11:00 PM »
Quote from Arantor on September 25th, 2011, 10:49 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)
Could the fifth (IIRC) parameter (for index) be used for the hook name?
Quote
Also, prepareDisplayContext is pretty unique
As I recall, it has one sister, the search. It works the same way. Do they do that for performance?
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Hooking up data loading
« Reply #18, on September 25th, 2011, 11:07 PM »
Well, the old last parameter was for stating keys; that's not needed in MySQL as far as I know if the table is set up properly, so I don't see why not off-hand.

The reason is less for pure performance and more memory: displaying 20 posts at a time is potentially heavyweight if you have to hold them all in memory at once, so they iterate that way to avoid shunting that data about in memory, and on the side, less processing effort.

What I find curious is that print-page does not do that.

Nao

  • Dadman with a boy
  • Posts: 16,082

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Hooking up data loading
« Reply #21, on September 25th, 2011, 11:36 PM »
Google likes topic pages more, so they optimized that. It's for the long run. Rarely accessed pages won't bring your server down. Makes sense to me...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Hooking up data loading
« Reply #22, on September 25th, 2011, 11:39 PM »
I still don't think it's about speed, it's more about not running out of memory.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Hooking up data loading
« Reply #23, on September 26th, 2011, 12:34 AM »
It is about memory, it can't be faster than simple fetching. Any comments about my code?

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Hooking up data loading
« Reply #26, on September 26th, 2011, 07:45 AM »
What I tried to say is I thought I already commented on your code posted in this thread.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Hooking up data loading
« Reply #28, 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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
« [Plugin] Notifications system (1.0)
[Plugin] Awards »