Does let nilClub: Club? = nil let noClubPred = #Predicate<Member> { member in member.club == nilClub } work?

Hi, DMG, You're right - that is the obvious way to deal with the issue. I'm an old UIKit guy new to SwiftUI (and SwiftData and Observation Framework) so I was looking for a way to leverage the Observation framework, but a more traditional callback approach will certainly work. Very helpful. Thanks, Rick

I'm sorry, but this isn't right. localizedStandardContains(_:) provides CONTAINS semantics, not EQUALS semantics. The original poster (and I) want a case-insensitive test for equality. Using localizedStandardCompare(_:) == .orderedSame is not supported by the current (Xcode 15.0 beta 7) version of SwiftData, and the alternative suggested by Xcode's error messages (localizedCompare(_:)) is case-sensitive. The only thing I can think of at this point (not tested, by the way) is $0. attribute.localizedStandardContains(str) && str.localizedStandardContains($0.attribute) which is ridiculous. FB13051739

I put together a writeup of the technique I'm using. (Yes, it's kludgy and I would be delighted for someone to offer an improvement or a replacement.) If the writeup seems long (or insultingly detailed), please forgive me. I find writing this sort of thing helps me clarify my thinking. Be that as it may, since I can't attach either a Pages file or a PDF to this reply, I moved the writeup to my Dropbox. https://www.dropbox.com/s/nf2diu6haayn147/Pseudo-Transient%20Attributes.pdf?dl=0

I finally worked out a solution to this problem, but it is a real hack. If you're interested in details, I can write it all up. However, in a nutshell, what I do is as follows: in any entity which contains an attribute that is used in the computation for the computed property, I use the validateForXXX methods to register changes. (The registration process is part of my CoreDataStack.) The entity which has the "computed" properties maintains real attributes with the computed values. The entity registers for notification for changes and performs the computations necessary to update the real (stored) values as appropriate. In this way, I am able to use a stored attribute (which can be the target of the find or sort operation) which is kept up to date. It's definitely kludgy (and requires more infrastructure that needs to be implemented correctly and consistently that I'd like), but I am finding it to be reliable. Again, I'll prepare a writeup if you're interested.