-
Notifications
You must be signed in to change notification settings - Fork 79
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
Multi-threading with Graph #96
Comments
Hi :) Can you share your code you are currently using to make the background request? As for documentation, that is something we would love help with and plan to attack this month. |
It was my mistake :) was passing a wrong parameter as subscript. Sorry for opening the issue. Still i would like to know if you would recommend one instance of Graph and update it from each thread or multiple Graph instances (the latter seems odd). Example : let graph = Graph()
for i in 0.stride(to: 1000, by: 1) {
var q: dispatch_queue_t? = dispatch_queue_create("com.testQueue.\(i)", DISPATCH_QUEUE_CONCURRENT)
dispatch_async(q) {
let entity = Entity(type: "new")
entity["count"] = i
graph.save()
}
} |
Great question. I found that usually people think of connecting to databases through a singleton or some global object. I found that that approach is really bad when it comes to architectural design. So what I recommend, is that each ViewController, or module, have a private reference to graph, that it uses. No need to get anything shared. In regards to your example code you just shared, you are creating 1000 threads and saving the entities in each thread. Is this a test to check the threading? If not, it would be better to do it in one thread, call the save once and go from there. For example: var q: dispatch_queue_t? = dispatch_queue_create("com.testQueue.\(i)", DISPATCH_QUEUE_CONCURRENT)
dispatch_async(q) {
let graph = Graph()
for i in 0.stride(to: 1000, by: 1) {
let entity = Entity(type: "new")
entity["count"] = i
}
graph.save()
} The other thing to note, is that graph has an asyncSave method. I didn't test the code, but that should be the general idea. Another tip, is that Graph doesn't require synchronization. It is always synchronized. Deep down in the code that makes Graph, there is ever a single instance of the Context, Coordinator, and such that ensure this. :) |
Yes, it was just to test threading. Thanks for the answer! It seems strange to me have an individual private reference since I'm used to CoreData as is and to the rather abused Objective-C"ish" Singleton (anti)-pattern. I really think that Graph is going to be very successful. Its simple and powerful! |
Thank you! We really appreciate it. If you feel this issue is resolved, please close it. If you would like, and I invite you, open more issues with some more interesting questions :) |
Will do. Changed the title of the issue for future reference. :) |
Thank you :) Daniel Dahan M: +1 647.627.0770
|
Hi guys, while testing your library I've made an app and installed crashlytics so I could track errors. I've come across this stack trace a couple of times now :
I'm using a background thread to get the entity from Graph. So my question is: Is there a recommended way to fetch result from Graph in background threads ? Could it be done concurrently or only serially ?
Thanks for the help.
PS: IMHO this library would benefit from a detailed documentation, I don't know if that is on your backlog ;) I'd be happy to contribute to that if you like
The text was updated successfully, but these errors were encountered: