'group by' count() soql fails in 9.0

[perbrondum]

SELECT activitydate, status, Count(Id) Cnt FROM task WHERE isdeleted = false GROUP BY activitydate, status

used to work, now it fails with : Error: keyNotFound(CodingKeys(stringValue: "url", intValue: nil), Swift.DecodingError.Context(codingPath: [CodingKeys(stringValue: "records", intValue: nil), _JSONKey(stringValue: "Index 0", intValue: 0), RecordCodingKey(stringValue: "attributes", intValue: nil)], debugDescription: "No value associated with key CodingKeys(stringValue: \"url\", intValue: nil) (\"url\").", underlyingError: nil))

[mike4aday]

@perbrondum would you post your (formatted) code, please?

[perbrondum]

private func groupedQuery() throws {
    let app = try ConnectedApp()
    let soql = """
        SELECT activitydate, status, Count(Id) Cnt
        FROM task
        WHERE isdeleted = false
        GROUP BY activitydate, status
    """
   // let soql = "SELECT activitydate, status, Count(Id) Cnt FROM task WHERE isdeleted = false GROUP BY activitydate, status"
    let pub: AnyPublisher<QueryResult<SObject>, Error> = app.query(soql: soql)
    pub.sink { completion in
        switch completion {
        case let .failure(error):
            print("Failed to execute grouped Query. Error: \(error)")
        case .finished:
            print("Success query")
            break
        }
    } receiveValue: { (tasks: QueryResult<SObject>) in
        for task in tasks.records {
            print(task.string(forField: "Cnt"))
        }
    }.store(in: &subscriptions)
}

[perbrondum]

You get the error when you add the GROUP clause. The count is not really relevant.

[perbrondum]

Similar results from use of Max in select list (I assume it's using 'group by' internally).

SELECT max(id) MaxId
        FROM Account
        WHERE isdeleted = false

[mike4aday]

Thanks @perbrondum - yes, any aggregating function in the query will cause the error. It's my fault - I re-introduced an error in ver. 9 that I had corrected in ver. 7. The current code expects the result to contain an array of records, each with an ID. But Salesforce returns a list of AggregateResult "records" when an aggregating function is used, and there is no ID. I'll fix it ASAP - trying to decide whether to fix with a breaking change (and update to ver 10) or a non-breaking change.

[perbrondum]

Happy to hear there is a quick fix.

Thanks

Per

On Aug 10, 2021, at 8:24 PM, Michael Epstein @.***> wrote:

 Thanks @perbrondum - yes, any aggregating function in the query will cause the error. It's my fault - I re-introduced an error in ver. 9 that I had corrected in ver. 7. The current code expects the result to contain an array of records, each with an IDs. But Salesforce returns a list of AggregateResult "records" when an aggregating function is used, and there is no ID. I'll fix it ASAP - trying to decide whether to fix with a breaking change (and update to ver 10) or a non-breaking change.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[perbrondum]

Is branch V9-fix-135 the fix for the bug?

[mike4aday]

@perbrondum it is -- but the fix isn't in there yet. I haven't had time yet to implement the fix. If you are blocked by the bug, I will accelerate the fix and try to get it done this week. I will notify you once ready. Thx

[perbrondum]

I have (unfortunately) added some new features (on 9) that I’d love to show to some people next week, so I’d love to see a fix.

Thanks a lot.

Per

On Aug 18, 2021 at 10:34:04 PM, Michael Epstein @.***> wrote:

@perbrondum https://github.com/perbrondum it is -- but the fix isn't in there yet. I haven't had time yet to implement the fix. If you are blocked by the bug, I will accelerate the fix and try to get it done this week. I will notify you once ready. Thx

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mike4aday/SwiftlySalesforce/issues/135#issuecomment-901412135, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCYWDD7JQ7GJXWDW6IXMYLT5QKLZANCNFSM5BUKY2RQ .

[perbrondum]

Thanks a lot for fixing this. Looks like I was able to pass all our tests with this fix.

[mike4aday]

@perbrondum good to hear. I didn't have time to test yet - as soon as I have working unit tests (and figure out what's wrong per issue #137 that you opened) I will merge into main branch.

[perbrondum]

Have you decided on a V9 or V10 release for the fix?

[mike4aday]

@perbrondum it'll be a minor release, updating version 9. I believe it's ready, but I wanted to do more testing before release. (For version 10, I'm considering a major release, in line with Apple's release of async/await in Swift 5.5.)

[perbrondum]

Awesome on both. We’ve started using async/await and can’t wait to see that in 10.

Per

On Nov 1, 2021, at 9:48 PM, Michael Epstein @.***> wrote:

 @perbrondum it'll be a minor release, updating version 9. I believe it's ready, but I wanted to do more testing before release. (For version 10, I'm considering a major release, in line with Apple's release of async/await in Swift 5.5.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[perbrondum]

Mike - Are you still considering a 9 release for this fix or is it pushed to R10? Thanks.

[mike4aday]

@perbrondum - the fix will be in version 10. I'm working on v.10 now, writing tests and plan to release it soon.

[perbrondum]

Good to know. Thanks for the update.

Can you share what will be in v10? We’re very interested in anything that will break connection/SFDC access, Combine/Await? Will salesforce.search make it back?

Trying to prepare :)

Per B Jakobsen CEO Tap2Sales.com @.***

On Feb 15, 2022 at 10:34:22 PM, Michael Epstein @.***> wrote:

@perbrondum https://github.com/perbrondum - the fix will be in version

10. I'm working on v.10 now, writing tests and plan to release it soon.

— Reply to this email directly, view it on GitHub https://github.com/mike4aday/SwiftlySalesforce/issues/135#issuecomment-1040816447, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCYWDD3GMA7SMHMCISYKMTU3LBF5ANCNFSM5BUKY2RQ . You are receiving this because you were mentioned.Message ID: @.***>

[mike4aday]

@perbrondum the major change in v10 will be async/await. I will try to reintroduce SOSL search in v10.0, but if I can't, I'll start working on that for v10.1 as soon as possible. Thanks

[perbrondum]

We replaced all SOSL calls w SOQL for now, but would certainly like it back. It’s just more flexible and powerful across objects.

Thanks

Per

On Feb 17, 2022, at 2:56 PM, Michael Epstein @.***> wrote:

 @perbrondum the major change in v10 will be async/await. I will try to reintroduce SOSL search in v10.0, but if I can't, I'll start working on that for v10.1 as soon as possible. Thanks

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[mike4aday]

Thanks @perbrondum - it's good for me to know what's useful.

[mike4aday]

Fixed in version 10.0.0

[perbrondum]

Mike,

Congrats on what so far looks like a very stable and cool release.

Checked about 80% of our tests and they all seem to pass (incl apex, multi query, group by and seach).

I remember when the switch to Combine was a delight (codewize). Await/Async is just so much more amazing, reduces the SFDC access code by 2/3 and makes the code so much easier to read.

Thanks for all your hard work. Can’t wait to see how our final App behaves with this release.

Per B Jakobsen CEO Tap2Sales.com @.***

On Mar 29, 2022 at 5:00:45 AM, Michael Epstein @.***> wrote:

Closed #135 https://github.com/mike4aday/SwiftlySalesforce/issues/135.

— Reply to this email directly, view it on GitHub https://github.com/mike4aday/SwiftlySalesforce/issues/135#event-6323015223, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCYWDDD4XTDYSXQX5XQYBDVCJW53ANCNFSM5BUKY2RQ . You are receiving this because you were mentioned.Message ID: @.***>

[mike4aday]

Thank you @perbrondum. I am loving async/await so far - so much simpler to follow, and requires much less code, as you noted. And thanks to the new Actor type, even multiple OAuth requests emanating simultaneously from different places in the code are easily 'bundled' into a single call. (The flip side is that I had to remove, for now at least, the ability to disable the automatic re-authentication -- i.e. no more "allowsLogin" switch in a request. So if you call a Salesforce method and in the unlikely event the refresh token flow fails, the user would be prompted to re-authenticate.)

[perbrondum]

Mike — Took me some time to convert, but everything is working (but for issue #114, which you just commented on, thanks)

Here’s a (very short) list of the issues we encountered. Most of the work was removing code, learning async/await/Task/Actor (ongoing).

1. TASK object conflicts with Swift 5.5 Task() and the Swift error message was not helpful, so that’s 2 hours I’ll never get back :).

2. When using DispatchQueue.main.async (and asyncAfter) inside functions like ViewDidLoad(), we get the following 'Sendable' warning.

   Capture of 'self' with non-sendable type ‘xxxViewController' in a @.***` closure

   I’m reading up on Actor/Sendable, eliminating old DispatchQueue code got rid of most of the warnings but a few I have not resolved and they seem harmless for now. Not sure if it’s SwiftlySFDC related.

3. .nextResult is not in V10 (#144). -> Will add code back in when implemented, not needed for now.

So, again, thanks for a very cool release. It forced us to learn better coding, eliminated a ton of old ugly code and the simplifications of code allowed us to optimize the user experience.

Per B Jakobsen CEO Tap2Sales.com @.***

On Mar 29, 2022 at 6:46:12 PM, Michael Epstein @.***> wrote:

Thank you @perbrondum https://github.com/perbrondum. I am loving async/await so far - so much simpler to follow, and requires much less code, as you noted. And thanks to the new Actor type, even multiple OAuth requests emanating simultaneously from different places in the code are easily 'bundled' into a single call. (The flip side is that I had to remove, for now at least, the ability to disable the automatic re-authentication -- i.e. no more "allowsLogin" switch in a request. So if you call a Salesforce method and in the unlikely event the refresh token flow fails, the user would be prompted to re-authenticate.)

— Reply to this email directly, view it on GitHub https://github.com/mike4aday/SwiftlySalesforce/issues/135#issuecomment-1082116068, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALCYWDEMCG4OUFHO3S34XPDVCMXVJANCNFSM5BUKY2RQ . You are receiving this because you were mentioned.Message ID: @.***>

[mike4aday]

@perbrondum re. the issues you mentioned: 1) Is TASK a custom object that you created to represent the Salesforce Task sObject? 2) I'll be interested to know what you learn about this. I'm using Swiftly Salesforce with SwiftUI on a project, so haven't dealt with UIKit issues. 3) I will fix that asap -- please see issue #144 for a workaround in the meantime Thank you for the feedback.

[perbrondum]

1. Yes. Renaming the object fixed the issue
2. I’ll probably do a write-up on how we ended up doing async concurrent and conseq salesforce queries. I’ll pas it along when done. We used .zip a lot (loved it) and need that same behavior.
3. Thanks for the workaround.

Per

On Apr 15, 2022, at 3:45 AM, Michael Epstein @.***> wrote:

 @perbrondum re. the issues you mentioned:

Is TASK a custom object that you created to represent the Salesforce Task sObject? I'll be interested to know what you learn about this. I'm using Swiftly Salesforce with SwiftUI on a project, so haven't dealt with UIKit issues. I will fix that asap -- please see issue #144 for a workaround in the meantime Thank you for the feedback. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.