Update FetchRequest

[MaxHasADHD]

Pull request checklist

• [x] All tests pass. Demo project builds and runs.
• [x] I have resolved any merge conflicts.
• [x] I have followed the coding style, and reviewed the contributing guidelines.

  This fixes issue #___.

  What's in this pull request?

Uses a cleaner FetchRequest.

[codecov-io]

Current coverage is 90.11%

Merging #86 into develop will increase coverage by 0.02%

@@            develop        #86   diff @@
==========================================
  Files            13         13          
  Lines           434        435     +1   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            391        392     +1   
  Misses           43         43          
  Partials          0          0          

Powered by Codecov. Last updated by 5413b36...1bf6f9e

[jessesquires]

Thanks @MaxHasADHD ! 😄

This isn't quite the direction that I think we should take the library.

• I think FetchRequest should continue to be initialized with an entity description. Initializing a fetch request with a context is really awkward considering we have context.fetch(request: r)
• I would like to see improvements around initializing an entity description. Using "\(self.self)" is close, but not quite there. I'd like to use the approaches that Daniel outlines here: https://realm.io/news/tryswift-daniel-eggert-modern-core-data/

I've opened #87 to track this. 😊

[MaxHasADHD]

I'm watching the talk right now! I'm currently reading his book as well. Just wondering though, would "\(self.self)" ever be wrong? Or just maybe in the future it could change to not be the entities name like I expect?

[jessesquires]

Or just maybe in the future it could change to not be the entities name like I expect?

Exactly.

With Daniel's approach, we can have the classes provide an entityName.

Then, we might be able to provide a default implementation that returns "\(self.self)" (or similar). This way, we could provide good defaults, but allow clients to override. 😄

[MaxHasADHD]

I like that idea! I'm going to implement this into my project :) Thanks

[jessesquires]

We'll provide more of these kinds of things in this library soon 😊

[saurabytes]

safer to use "\(self.dynamicType.self)" also get rids of the module name and will leave you with the class name which is in most case is the entity name