Woof - implementing the generic App Entity queries for SwiftData entities really highlights all of the shortcomings of the #Predicate macro. This is soooooo much harder than it should be.
Woof - implementing the generic App Entity queries for SwiftData entities really highlights all of the shortcomings of the #Predicate macro. This is soooooo much harder than it should be.
🎉 I just finished Day 57 of the #100DaysOfSwiftUI at https://www.hackingwithswift.com/100/swiftui/57 via @twostraws
TIL how to edit SwiftData objects with #SwiftUI and how to filter data using the `#Predicate` syntax.
@marcel Should be possible with something like this (untested):
Query(filter: #Predicate<Object> { object in
object.date > dateA && object.date < dateB
})
Starting a new project for Day 57, so don’t have much to show so far. We’re learning how to edit SwiftData objects with SwiftUI and filter data using #Predicate. #100DaysOfSwiftUI
I'm toying with SwiftData and the #Predicate stuff seems really bad? A predicate that references an enum doesn't seem to be able to compile: "Member access without an explicit base is not supported in this predicate".
I can get it to work if before building the predicate I map the enum to it's rawValue (String in this case) and then inside the predicate I hardcode the rawValue's strings. That's horrible and it'll break in no time...
Am I missing something?
That was fun, one Swift file was taking 92 seconds to compile, then I figured out I was using a SwiftData filter #Predicate wrong. Fixed, it now it takes 0.7 seconds 🎉
Today's #SwiftData puzzle: using a #Predicate is not possible with enum fields for comparison
Near the end of part 3 of his Prolegomena to any Future Metaphysics, Immanuel Kant compares his systematic deduction of the categories against Aristotle's "rhapsody" account
https://soundcloud.com/gregorybsadler/immanuel-kant-prolegomena-the-system-of-the-categories
#Podcast #Kant #Aristotle #Categories #Metaphysics #Philosophy #Predicate
@ifarouk @fatbobman i havent used the predicate macro myself so far but i think it needs to know of which type it is. So it should be something like #Predicate<Place> {…} i think 🤔
@JetForMe #Predicate was added to the Foundation framework rather than the Swift Standard Library, so it didn’t have the same formal review process at the time as other pitches you might’ve seen for the language or stdlib itself. With the new swift-foundation package we’ve started formalizing a new process adjacent to Swift Evolution for changes to Foundation - you can find more details at https://github.com/apple/swift-foundation/blob/main/Evolution.md as the process evolves over time!
Was there an accepted Swift Evolution proposal for #Predicate? There was a [pitch](https://forums.swift.org/t/pitch-swift-predicates/62000), but i can't find where it was accepted into the language.
#572 - Querying data with the @Query Macro
In this episode we will provide a searchable interface using the @Query and #Predicate macros. We'll discuss how to use localizedStandardCompare instead of...
https://nsscreencast.com/episodes/572-swift-data-queries
@natpanferova this is great! I just learnt about this today in fact, in the context of the new #predicate macro.
@ddribeiro I'm not sure how far the enum support is, but if you have a small sample project, I'd have a look. I don't think you'd want to use the `return true` in a `#Predicate`, but rather just use `searchString.isEmpty && filter == .all`. (the predicate content closure is not actual Swift code that is executed, it is rather translated into NSPredicate's for CoreData to execute by the macro).
Asking here so as to not lone wolf it and then returning to reading https://www.bigmountainstudio.com/swiftdata/214lj (affiliate link). How to get the matching user?
```
ForEach(user.friends, id: \.self) { friend in
@Query(filter: #Predicate<User> { user in user.id == friend.id }) var matchedUser: User
NavigationLink(destination: DetailView(user: matchedUser)) {
Text(friend.name)
}
}
```
right now, Xcode tells me "Cannot reference invalid declaration 'friend'"
Using generics to create SwiftData Predicates leads to crashy times. I tried to write something like:
```Swift
func fetch<T>(
by idString: String,
as type: T.Type
) throws -> [T] where T: PersistentModel, T: ObjectStringIdentifiable {
try modelContext.fetch(FetchDescriptor<T>(predicate: #Predicate { $0.idString == idString }))
}
```
The Predicate macro assumes `idString` is a computed property and crashes at runtime.
Ok my two biggest gripes with SwiftData:
First, @model supports Codable types but ignores the implementations of init(from:) and encode(to:) and does its own thing. They compile fine but blow up with fatalErrors.
Second, #Predicate supports Comparable types but ignores their implementations and does its own thing. Again compiles fine but fatalErrors.
My message to the SwiftData team: please don't co-opt core protocols to do custom things. You're just giving the user loaded foot-guns.
OK I found the problem. The underlying Query for folders delivered all folders, not only the parents. This is the way it works:
@Query(filter: #Predicate<Folder> { $0.parentFolder == nil }) var folders : [Folder]
@helge My Swift Data has Four major Classes, A Person, A Gallery Card, A Specific Card, and an EventType. You can create new EventTypes, And New Cards for the Gallery. A Card in the Gallery must have an Event Type. I can dynamically filter that view - by setting a "selectedEvent" and then in my Init I set the GalleryCard via @Query(filter: #Predicate {$0.eventType?.persistentModelID == selectedEvent.presistentModelID}). However, When I want to create a new specific Card, …
Today I finished Day 57 of #100DaysOfSwiftUI
It is a technique project and I will learn a lot more about SwiftData. Todays learning was all about editing SwiftData and filtering @Query with #Predicate. I also took some time to google and try to understand what the @Enviroment propperty wraper is all about. Because with SwiftData you have to use that, but I didn’t got why. Now I know.
#Swift #SwiftUI #iOSDev