Bring Sugar syntax on board

[pepicrft]

One of the most remarkable features of Swift is its sugar syntax and it's time to bring it to SugarRecord too. This issue is opened as a brainStorming to talk about the syntax and how we could refactor our methods.

Syntax

// Operations with contexts
person.save()
person.save(asynchronously)
person.inContext(context).save()
person.inContext(context).save(asynchronously)

// Main examples
Person.by("name", "Pedro").sorting("age", ascending: true).fist() // -> NSFetchRequest
Person.by("name", "Pedro").sorting("age", ascending: true).first(20).find() // -> [NSManagedObject]?
Person.by("name", "Pedro").sorting("age", ascending: true).last().find(context) // -> [NSManagedObject]?
Person.by("name", "Pedro").sorting("age", ascending: true).all().find(context, asynchronously: true) // -> [NSManagedObject]?

// Alternatives around previous idea
Person.by("name", "Pedro").all // -> NSFetchRequest
Person.by("name", "Pedro").first(20) // -> NSFetchRequest
Person.by("name", "Pedro").last(20) // -> NSFetchRequest
Person.by("name", "Pedro").all // -> NSFetchRequest
Person.by("name", "Pedro").first // -> NSFetchRequest

// FetchedResultsController
Person.by("name","Pedro").fetchedResultsController() // -> NSFetchedResultsController

Requirements

[pepicrft]

@fjbelchi take a look to the idea above!

[fjbelchi]

I've been thinking about the stack and the syntax and I think the core of the library, the focus, should be in the syntax more than the technology behind, either CoreData, SQL, any other.. at the end of the day these tools are tools to persist data.

I would like to have operations with a syntax similar to what you describe like this, without necessary be depending on CoreData:

db.person.filter(person.id == "234234234").delete()
db.person.create(personType).save()

[pepicrft]

Yeah!, that's the idea @fjbelchi , when you do something like this

Person.by("name", "Pedro").sorting("age", ascending: true).first().find

This is completely transparent for the user. Where do you find the dependency with CoreData?

[fjbelchi]

that example is perfect, but I've seen others like:

Person.by("name", "Pedro").sorting("age", ascending: true).last().find(context) 

where you need to know about a context. And probably the consumer doesn't know about the stack either

[pepicrft]

Yes @fjbelchi because although you make it simple for the basic user, we're going to have advanced users that probably want to decide in which context do the fetch for example.

[pepicrft]

MagicalRecord offered at first only one stack and they had to move to a new architecture where they allowed advanced and custom stack. I guess it is because developers asked for it. So although we make the syntax more sugar, we always have the simplest one that uses the stack without asking to the user, and the advanced where the user decides even the context. What do you think?

[pepicrft]

Covered in this issue:
#5