Query function does not return same result format as Read with nested object

[AllusiveBox]

Trying to search offer the ability to search for contacts off recordNumber, contactName and return specified fields, but when I perform the search using the Read function I get

{
  RECORDNO,
  CONTACTNAME,
  MAILADDRESS: {
    ADDRESS1,
    ADDRESS2,
    CITY,
    STATE,
    ZIP
  }
}

While using a query that searches for the exact same fields returns

{
  RECORDNO,
  CONTACTNAME
  MAILADDRESS.ADDRESS1,
  MAILADDRESS.ADDRESS2,
  MAILADDRESS.CITY,
  MAILADDRESS.STATE,
  MAILADDRESS.ZIP
}

[ryan-holderfield-sage]

Hi,

This is more API Gateway specific behavior and not related to the SDK. I could see this being confusing and will mention it to the product manager.

[AllusiveBox]

Hey Ryan,

Thanks for getting back regarding this. Would it be possible to get confirmation if this is intentional or not? Would be greatly appreciated to know if this is intended functionality so I can work around it, or if it is a bug that might be fixed in the future?

Thanks! :)

[ryan-holderfield-sage]

Hey @AllusiveBox ,

Yes, this is the current functionality, and we understand the return results are inconsistent between these functions. However, we have no plans currently to enhance the read function as it could impact existing integrations.

Best Regards Ryan

[AllusiveBox]

However, we have no plans currently to enhance the read function as it could impact existing integrations.

Honestly, the functionality from the Read function is preferred, so that's fine; I would much rather get the results back as a nested object than not. I just don't always have the record number for an entity on hand, so having to have two different mapping logics, one for Read and one for Queries is a bit of a hassle. If anything, I'd love to see the Query function format the response similar to what we get when the Read function returns, as I find it not really intuitive to have to query by MAILADDRESS.ADDRESS1, MAILADDRESS.ADDRESS2, MAILADDRESS.CITY etc. and would much rather be able to specify the query to just return all the MAILADDRESS associated data as an object.

[ryan-holderfield-sage]

Good Morning @AllusiveBox ,

I would recommend posting this as an idea in the community. The product manager can evaluate if this is something that can be added as a return format for the query function.

From the Sage Intacct Community Home page, locate the Ideas section in the center of the page above the Connect with the Community section and click the green View All Ideas button. Once on the Popular Ideas screen, select Post Idea.

Be sure to mention maintaining two different logic mappings for the functions as part of the reason why you are making the suggestion.

Is it OK to mark this question closed?

[AllusiveBox]

Hello @ryan-holderfield-sage

Thanks for the information on how to submit this to the community. At this point, I think my only question would be if it would be possible to have the SDK add logic to consolidate fields like these when converting the SQL back to JSON?

[AllusiveBox]

@ryan-holderfield-sage

I was wondering if you could tell me if the ReadByQuery function is legacy as in it's deprecated and will eventually be removed, or if it's legacy as in the Query function replaces it but the old way is staying because it has different uses compared to the new Query? I noticed that switching from the Query function to ReadByQuery has resolved the issues that I'm having without the need of custom mapping logic, but I'm very hesitant to switch to something marked as legacy, especially given I'm seeing no indication of what legacy means in this case.

Thanks,

[ryan-holderfield-sage]

Hi @AllusiveBox

As far as I know, the legacy functions are not being removed. However, legacy functions will not receive enhancements.

[AllusiveBox]

Hey @ryan-holderfield-sage,

Thanks for getting back to me regarding legacy functions. It makes sense that they wouldn't be supported, I just wasn't sure if they had an EoL date or were just going to be around indefinitely, without support.

Unfortunately, I'm realizing that the ReadByQuery function does not have any functionality for case-insensitivity, and as the legacy functions are no longer receiving support, I assume it means it would not be possible to get that added, even if requested via the Community.

With that said, I find myself back at the mercy of the Query function. I have submitted an idea regarding this to the community, however, given the top rated idea is over 10 years old, I will be fully transparent in my skepticism that such an idea will be implemented in a timely fashion, if at all. As such, would it be possible to see an addition to the SDK that takes similarly grouped items and condenses them into an object to result in a format similar to the results of a Read function? This issue is now becoming a bit more annoying, as my team and I are learning that this isn't an issue exclusive to contacts, but to all entities returned from a Query function.