Mapping to NSPredicate and NSSortDescriptor

[omiz]

Using PredicateKit version 1.4.0

I need to map the generated predicate or request back to CoreData classes.

A short demo using the examples in readme file:

let predicate: Predicate<Note> = \Note.text == "Hello, World!" && \Note.creationDate < Date()

let controller: NSFetchedResultsController<Note> = managedObjectContext
    .fetch(where: predicate)
    .sorted(by: \Note.creationDate, .descending)
    .fetchedResultsController(sectionNameKeyPath: \Note.creationDate)

controller.fetchRequest.predicate = ???

I need help on using predicate: Predicate<Note> as NSPredicate

I am asking for something similar to the function fileprivate func makePredicate<Root>(from predicate: Predicate<Root>) -> NSPredicate in NSFetchRequestBuilder.swift

another example is using either NSPredicate or NSSortDescriptor on NSArray

[ftchirou]

I need to map the generated predicate or request back to CoreData classes. I need help on using predicate: Predicate as NSPredicate

I'm a little cautious about publicly exposing an API to directly convert from Predicate to NSPredicate. Could you provide a concrete example (maybe a simplified example from your project) where this would be useful to you?

(In the short demo you provided, controller.fetchRequest.predicate already returns the NSPredicate equivalent of the predicate passed in fetch(where:).)

[omiz]

I have many reasons but some of them are temporarily.

I'm working on a big project and replacing everything at once might need a very long time so I want to do this in stages

in the example above I wanted to update the value of controller.fetchRequest.predicate to keep reusing the controller instead of creating a new one

I need some kind of a listener on multiple entities at the same time so just understand what I mean I have this I have RFContextWatcher.swift. Now this behavior can be also achieved by using Combine and publishers.

Another case that I have is filtering an NSArray or NSSet using the function func filtered(using predicate: NSPredicate) -> Set<AnyHashable> this does not have anything to do with CoreData

another reason is for logging predicateFormat

Many of the reasons that I have could be added as cool new features but exposing NSPredicate would make it much easier to apply staged integration

most of these examples would apply to both NSPredicate and NSSortDescriptor

[ftchirou]

Hi @omiz!

Thank you for your reply. I understand your request better now. Though I see how exposing an API to convert from Predicate to NSPredicate would be helpful in your specific use cases, I don't think this is something that would be a good addition in general because:

• it is potential source of runtime errors. Right now, we can convert a KeyPath to a string only if the root of the KeyPath is a subclass of NSManagedObject. Trying to convert an arbitrary KeyPath to a string will result in a failure at runtime. Through the PredicateKit API (managedObjectContext.fetch(where: ...).result()), we have the guarantee that the object on which the predicate runs is a subclass of NSManagedObject, so we know this will not fail. If we introduce free-form conversion from Predicate to NSPredicate, we loose that guarantee and developers will start experiencing runtime failures; especially if the converted NSPredicates are meant to be used independently of CoreData. For example, on NSArray and NSSet (like you suggested) where we have no control over the types of elements contained in the arrays/sets.
• PredicateKit is an opinionated framework. Introducing conversion from Predicate to NSPredicate will enable the usage of the framework to deviate from its initial philosophy.

I would be happy to discuss and implement the specific features you need (without the shortcut Predicate -> NSPredicate). I think they will improve PredicateKit and be useful to more people (e.g. adding the option to update the predicate of a NSFetchedResultsController).

[omiz]

Thank you @ftchirou for the explanation.

I totally agree with you especially that the library is built using swift and the concept of type safe idea.

my idea can be easily misused I was just looking at it in a similar way to the Array Subscript I can say myArray[1] on an empty array but I would still expect the programmer not to do that by passing them the responsibility to check for edge cases and writing clean code.

At this point it's really your decision if you would introduce something like var _asNSPredicate: NSPredicate or maybe an initializer on NSPredicate that takes Predicate<Entity>

If you would say that you can not allow such a feature in your code then I would suggest to close this ticket and try with small targeted features like the update of a predicate on NSFetchedResultsController or the string description of the predicate.

[ftchirou]

Thank you. Let's close this issue. I'll push an update in the next few days to allow mutations on the predicate of NSFetchedResultsController. In the meantime, feel free to open new issues for your other feature requests.