Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Init entities and relationships #12

Closed
MP0w opened this issue Apr 4, 2016 · 9 comments
Closed

Init entities and relationships #12

MP0w opened this issue Apr 4, 2016 · 9 comments
Assignees
Milestone

Comments

@MP0w
Copy link
Member

MP0w commented Apr 4, 2016

Every entity that conform to the protocol (ATM called KakapoSerializable) will have to implement init(id: String). To create entities there might be 2 ways:

db.create(20, User) //pseudocode
// or
db.create(20) { (id) in
    return User(name: Faker.name, friends: db.findRandom(Friends))
}

Friends is a relationship od User:

struct Friend: KakapoModel {
    let id: String
    let name: String
    init(id: String) {
       self.id = id
       name = Faker.name
    }
}

User will init is relationship as:

struct User: KakapoModel {
    let id: String
    let name: String
    let friends: [Friend]
    init(id: String) {
       self.id = id
       name = Faker.name
       friends = 1...(arc4random()).each{ Friend(id: NSUUID()) }
    }
}
@joanromano
Copy link
Member

I think we should aim for usability here. If I want to use this one:

db.create(20) { (id) in
    return User(name: Faker.name, friends: db.findRandom(Friends))
}

Means that I also need to specify a second init method in user, right? Is that what we want? It also means that I already have to create friend objects (that seems ok). Would we also need to pick different random friends for each user or we don't care about repeating (this is not that important for now, probably)

Also, how about hiding the database implementation details as much as possible? @zzarcon proposed to only use the server for object creation, which will then forward those calls to the internal db. Then the db might only be used in the closure as a passed in parameter.

@MP0w MP0w added this to the Alpha-1 milestone Apr 4, 2016
@MP0w MP0w added the discussion label Apr 4, 2016
@MP0w
Copy link
Member Author

MP0w commented Apr 4, 2016

@joanromano that closure was just an example and should not be required to use it if init(id:) is enough, so we are not forcing to have that init.
I think I Agree with @zzarcon about merging / wrapping the database in the server

@joanromano
Copy link
Member

But if they need relationships we then force to have two inits

@MP0w
Copy link
Member Author

MP0w commented Apr 4, 2016

No we don't in User.init(id:) they just have to call Friend.init(id:)

@joanromano
Copy link
Member

So what is User(name: Faker.name, friends: db.findRandom(Friends)) then?

@MP0w
Copy link
Member Author

MP0w commented Apr 4, 2016

Another example using the closure if fake data is not enough (e.g creating a user from ui should have a nane entered by the user)

@MP0w
Copy link
Member Author

MP0w commented Apr 5, 2016

Reverse and recursive relationships are not part of this discussion see #16

@MP0w
Copy link
Member Author

MP0w commented Apr 14, 2016

struct B: Storable {
    let id: Int

    init(id: Int, db: KakapoDB) {
        self.id = id
    }
}

struct A: Storable {
    let id: Int
    let b: B

    init(id: Int, db: KakapoDB) {
        self.id = id
        self.b = db.create(B)[0]
    }
}

@MP0w
Copy link
Member Author

MP0w commented Apr 14, 2016

or:

self.b = sutt.insert { (id) -> B in
     return B(id: id)
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants