Jump to content

Underlying workings of autojoin


Rob
 Share

Recommended Posts

I'm tying to understand the codebase of PW, as best I can, as part of my decision-making process regarding whether to use it for a new project.

I'm delving into the autojoin functionality, primarily becasue I couldn't understand why I couldn't autojoin image fields.  It turns out I just had to do a one-line tweak and the autojoin checkbox appeared in the setup, but I haven't actually tested it and it made me curious about the deeper workings.

It looks to me that the "getLoadQueryAutojoin" method i key here, but what surprised me is that when I searched for that method name in my IDE, it is only defined in a handful of classes and only called twice by the "Pages" class and the "FieldType" class and it's subclasses.  In both cases the call does not appear to use the return value (an instance of "DatabaseQuerySelect" or NULL) and nor are the parameters references so it doesn't appear to be making any changes to and dat "in situ" as it were.

This leaves me very baffled as to how this works, what pitfalls I might need to lok out for (for example is there a good reason that autojoin was disabled for images) and how it all holds together!!  I appreciate this is a pretty techie question so I hope it is in the right forum, but I need to have a reasonable understanding (and therefore some faith) in a codebase before I use it for a major project.

Thanks!

Link to comment
Share on other sites

Autojoin is a way to have data for some fields bundled into the query that loads the page. It's a way of reducing number of queries for fields that you always want loaded with the page. For instance, you probably always want to load the page's "title" field (a good autojoin candidate). Whereas, something like a large "body" field you probably only need when the full page is rendered. So no need to have that "body" field loaded with every instance of the page (autojoin off).

In reality, well indexed and simple MySQL queries are extremely fast, and autojoin may not make that much difference in real use. For example, a couple hundred simple select queries will often run faster than one or two really complex queries. So query counting is futile. But I believe it's still a good idea to use autojoin for fields that you always want loaded with every instance of the page. Most fields do not need to be autojoin.

Using autojoin on FieldtypeMulti fields (like pages, files, images, comments, etc.) is a tricky matter because the primary page load query is designed to execute with 1 fetch with no data repetition. That ensures the fastest possible performance. Fields with multiple entries (FieldtypeMulti) are not well suited to being retrieved in 1 fetch. However, ProcessWire can still do it using a MySQL GROUP_CONCAT function to bundle the multiple entires into a string suitable for that 1 fetch. The problem is that MySQL has a byte limit on how much it will GROUP_CONCAT (it's a MySQL setting that we can't count on). As a result, autojoin is okay to use on simple multi-entry fields like Page relations that don't have hundreds of entries–that's because it's just a bunch of integers. But it's not well suited for more complex fields like images that might have long descriptions. As a result, I don't recommend using it with file/image fieldtypes.

nor are the parameters references so it doesn't appear to be making any changes to and dat "in situ" as it were.

In PHP5, all object instances are passed by reference. So that particular function is adding on components to the query object to support the autojoin if it can.

  • Like 1
Link to comment
Share on other sites

In PHP5, all object instances are passed by reference. So that particular function is adding on components to the query object to support the autojoin if it can.

I'm actually genuinely embarassed that I didn't know that, or at least had forgotten!!  I'm allegedly a "professional" PHP developer for about 5 years.  Oh well, we all have bad days!

The makes sense with that in mind..

Cheers Ryan.

Link to comment
Share on other sites

Don't worry about it. :) I've been guilty of forgetting this too. It's actually an easy thing to forget because in PHP4 objects were not passed by reference... you had to prepend a "&" to them in order to prevent it from creating a new copy on every function call. Thankfully we don't have to do that anymore. But people that have been using OO in PHP for a long time sometimes still use the "&" in front of arguments since it used to be required. When I spend an hour looking at PHP4 code, and then go back into PHP5, I sometimes do the same thing. :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...