Bug #23467 Bug Fixed

Fetching partial data from model wields inconsistent results

Version: 4.0.9 Reporter: Low

When using the ChannelEntry model to fetch entries, and using the Partial Data option to only select relevant fields, will give me inconsistent results. It is best shown via this video.

The main thing being that in some cases, you need to explicitly add channel_id to the fields list in order to fetch certain custom fields. In the video, I limit the fields to entry_id, channel_id, title, field_id_1, field_id_2, field_id_75. When I remove channel_id from the list, field_id_75 is removed as well.

In the debugger, I can see a query being generated with this WHERE clause, which looks wrong:

WHERE  ( 
    `Channel_channels`.`channel_id`  IN (NULL) 
)

Also, the custom fields are only added to the result set when the value is not NULL, where I expect the keys to always be present, possibly with a value of NULL.

  • I’m guessing field_id_75 is a field stored in its own table? If so, then yes it needs the channel_id to know that field is assigned to the entry and to go get it. Is your argument that we should do an auto-magic selection of fields to include in addition to what the developer specified so that relationships work, even though the developer deliberately omitted the data needed for them?

    Also, the custom fields are only added to the result set when the value is not NULL, where I expect the keys to always be present, possibly with a value of NULL.

    I think we can make this change, might save it for 4.1 developer preview since it’s kind of an API behavioral change.

    Kevin Cupp
    09th February, 2018 at 4:36pm
  • I was under the impression that using the fields() method will give me the fields I ask for. The docs don’t mention that you at least need field X if you also want field Y, so there’s no way of knowing which fields are dependent on each other.

    So yeah, I am expecting that, when I define any number of fields using the fields() method, those fields will be present in the result set, even though you’d need to use other fields to get to those. IMO, that should be abstracted away in the builder. That, or the docs should mention any dependencies.

    Low
    10th February, 2018 at 7:34am
  • I was under the impression that using the fields() method will give me the fields I ask for.

    Ideally, yes, but there are sometimes exceptions. These new custom fields are just kind of magic in how they’re added, no other model fields behave like this, and it seems to be uncommon to cherry-pick specific field IDs since those change from install to install, so this specific use case wasn’t given much attention.

    The docs don’t mention that you at least need field X if you also want field Y, so there’s no way of knowing which fields are dependent on each other.

    There is a way. I mentioned why the relationship between these fields is the way that it is, so you should be able to use that as a heuristic.

    So yeah, I am expecting that, when I define any number of fields using the fields() method, those fields will be present in the result set, even though you’d need to use other fields to get to those. IMO, that should be abstracted away in the builder. That, or the docs should mention any dependencies.

    I could see the desired behavior going either way, but I’ll try to look into what it will take to accommodate this preference in coming week.

    Kevin Cupp
    10th February, 2018 at 1:00pm
  • > it seems to be uncommon to cherry-pick specific field IDs since those change from install to install, so this specific use case wasn’t given much attention

    I’m not following. In add-ons, it is common practice to target only a specific field and do something with the value in that field. Then it seems a waste to fetch all fields for that entry, so limiting the query builder to that field only (and an entry_id) is oftentimes enough. That’s not cherry-picking, is it? Especially if the field(s) in question are user-defined.

    The only reason I managed to figure out that the channel_id was indeed required, was after investigating this support request using with trial and error. That seems counter-intuitive and not suitable to use as a heuristic for future development.

    Low
    12th February, 2018 at 9:06am
  • I’m not following. In add-ons, it is common practice to target only a specific field and do something with the value in that field. Then it seems a waste to fetch all fields for that entry, so limiting the query builder to that field only (and an entry_id) is oftentimes enough.

    It’s not common enough to have it come up as an issue as of yet, is all I meant. Of course it’s common in query building in general, but this specific use case of using the fields method on the model and using it to select individual channel fields just isn’t, or else it would have come up by now. That’s all.

    That’s not cherry-picking, is it?

    Cherry-picking means “selectively choose (the most beneficial items) from what is available,” so yes. You are picking the field that you need to act on out of all the other fields because it is most beneficial to your task.

    The only reason I managed to figure out that the channel_id was indeed required, was after investigating this support request using with trial and error. That seems counter-intuitive and not suitable to use as a heuristic for future development.

    Yes of course, I only gave it to you to help you along while you’re developing your add-on while we figure this out.

    Kevin Cupp
    12th February, 2018 at 10:55am
  • Gotcha.

    Maybe there needs to be some kind of Service available rather than a Model, that is responsible for getting channel entry data like that, since no other model behaves this way. The service would only get data, not set it, and would act like a channel:entries tag, but programmatically/as an API, so it’s available for all.

    Low
    13th February, 2018 at 3:55am
  • I was able to change it so that we’ll automatically select any columns needed to fulfill relationships, which is typically only 2-3 more columns. It seems to be working fine and covers the issues you were having, we’ll have it in the 4.1 developer preview here soon.

    Kevin Cupp
    13th February, 2018 at 2:03pm

You must be signed in to comment on a bug report.

.(JavaScript must be enabled to view this email address)

ExpressionEngine News!

#eecms, #events, #releases