1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Not Planned Add CalledBy Variable to All Model Functions

Discussion in 'Closed Suggestions' started by Snog, Jun 12, 2015.

  1. Snog

    Snog Well-Known Member

    I know it's a task, but adding a CalledBy variable to all model functions would allow developers to decide if their extension to model functions should run during certain operations or not.

    For example, let's say a node gets extended using a developer's table and there's no need to have that info during a rebuild, the developer could condition his extension with something like if(!$calledBy == 'deferred') and prevent it from running during a deferred process.

    public function getThreadById($threadId, array $fetchOptions = array(), $calledBy = null)
    Would be called like this..
    $thread = $this->getModelFromCache('XenForo_Model_Thread')->getThreadById(
               array('join' => XenForo_Model_Thread::FETCH_FORUM),
    We already have the Hint in the listener, but this would extend that concept even farther at the model level. I can think of many instances where this would come in handy.
    Last edited: Jun 12, 2015
  2. Mike

    Mike XenForo Developer Staff Member

    Doing something similar with specific methods might be viable, but I can pretty definitively say this wouldn't really happen "globally". If something like this were to happen, I don't think the calling context (eg, "deferred") is really what would be defined; it would likely represent the usage context (eg, "full" to mean that we need as much data as possible because this is a focal point).

    Based on that and the particular suggestion here, I'm going to say this isn't planned.
  3. Snog

    Snog Well-Known Member

    I can understand the 'full', etc. for certain functions. I only used 'deferred' because that's the process that prompted the suggestion. I was doing an import on a site that already had a large number of add-ons installed and noticed the import time was insanely long when it came time to finalize the import. After investigation I found it was the add-ons causing the long import time. And the same applied to rebuilding caches. So the idea to have the variable came to mind.

    Anyway it wasn't meant as a steadfast, must have this way suggestion. It was more of a concept than anything else. ;)

    Although it would be nice globally. If an add-on only affects the member page, then a getUserByName($input['username'],'member') would allow the possibility to eliminate all other calls in other parts of the forum where the info from the add-on isn't need.
    Last edited: Jun 13, 2015
  4. digitalpoint

    digitalpoint Well-Known Member

    Not sure it's practical, but it certainly would help a situation where I have a bunch of custom joins when loading a user related to trophies. I ended up getting super hacky with it because I didn't want all those joins happening every time a user is loaded (every page view).

    Would be nice if trophy evaluation queries aren't the same as the normal one for loading a user when they are on the site.
    Xon likes this.
  5. Luke F

    Luke F Well-Known Member

    It's not a terribly clean solution but you could just parse debug_backtrace()
  6. W1zzard

    W1zzard Well-Known Member

    Have you considered using the $_SERVER global variables for detection of what page is loaded etc?
    Xon and Snog like this.

Share This Page