Re: Core Data Multiuser
On 9 Oct 2012, at 04:54, Flavio Donadio fla...@donadio.com.br wrote: On 08/10/2012, at 17:56, Alex Zavatone wrote: Thank you Flavio. Out of curiosity, did you encounter pessimistic vs. optimistic locking performance/data reliability issue in having many clients writing to potentially the same places at once? If so, how did each of the candidate solutions answer the problem that this poses? The problem being if there are multiple users potentially writing to the same place at once, locking records during each write is too slow, but if you don't do this, you end up with the potential of two (or more) people writing to a record at once. An example of this in real life is if both of us try to book a ticket for the last seat on a plane at the same time. I don't think I'll have performance problems. I'll never have more than, say, 20 users at any given time and these race conditions will be rare. The database server can handle this easily, *in my case*. The real problem is in the user interface. The interface will be like in Address Book: the user opens a card/record for viewing, but has to click an Edit button to make changes. If the record is locked, the user will get an alert when he/she clicks the button. I need: 1. A mechanism to avoid users opening records for editing and leaving them open forever (timer?); 2. Some kind of feedback for the users when a record is unlocked, without having to refresh manually. Ideas are very welcome. Optimistic locking http://en.wikipedia.org/wiki/Optimistic_locking might be a solution. In this you let everyone edit at will and lock nothing. If a conflict occurs when a user attempts to overwrite another user's recent edit then you query the user as how to proceed. If a user leaves a record open indefinitely it causes no issues. Regards Jonathan Mitchell Mugginsoft LLP ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Flavio Donadio fla...@donadio.com.br writes: The interface will be like in Address Book: the user opens a card/record for viewing, but has to click an Edit button to make changes. If the record is locked, the user will get an alert when he/she clicks the button. I need: 1. A mechanism to avoid users opening records for editing and leaving them open forever (timer?); 2. Some kind of feedback for the users when a record is unlocked, without having to refresh manually. I would not go this route. Have a look at network file systems like Windows SMB for how ugly this can get (but maybe you can find there some inspiration for your solution; Microsoft did quite some changes in this area for the latest releases of the SMB protocol). I would prefer the classic ORM optimistic locking approach: Just use a special field in the database (e.g. a simple integer field called version). On each write do something like UPDATE ... WHERE version = X and objectid = Y. If this fails (0 records updated), then someone else updated the record in the meantime (between clicking on Edit and clicking on Save) and you may present the user an error message (maybe with the option to merge or overwrite the other changes). In many use cases this will lead to very few messages due to record version mismatches, there are no stale locks and the implementation is quite simple (except for some kind of merge algorithm). -- Until the next mail..., Stefan. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On 09/10/2012, at 01:46, z...@mac.com wrote: For 2. Can you use a NSNotification to fire and forget an unlock event? Not really. The server can't send the notification back to the client. There's a RESTful web service between the client and the database. But are you merely querying the database, or do you have a facility to send messages back to the GUI? I'm querying the database only. I still can have the client poll the app server with a fair interval, but this can create overhead as more clients are added. I don't like polling at all... If there are messages back so, you can set up a message relayer that can hold the current messages from the server and choose how to or when to relay them. It would require something else for the client-server communication, like the protocols Jens Alfke suggested. Or talking to the database server directly, with something like BaseTen (only for PostgreSQL). Or going low-level (e.g., libpq), which goes beyond my skills. Since I am not a dev-wizard like you guys, I have to stick to simple things! ;) Also, keep in mind this is an in-house project, never meant to be a commercial product. We can deal with some problems in ways that would not be desirable in commercial software. But, since I'm a Mac user, I want things to be as perfect as they can be Cheers, Flavio --Original Message-- From: Flavio Donadio To: Alex Zavatone Cc: Cocoa List Subject: Re: Core Data Multiuser Sent: Oct 8, 2012 11:54 PM On 08/10/2012, at 17:56, Alex Zavatone wrote: Thank you Flavio. Out of curiosity, did you encounter pessimistic vs. optimistic locking performance/data reliability issue in having many clients writing to potentially the same places at once? If so, how did each of the candidate solutions answer the problem that this poses? The problem being if there are multiple users potentially writing to the same place at once, locking records during each write is too slow, but if you don't do this, you end up with the potential of two (or more) people writing to a record at once. An example of this in real life is if both of us try to book a ticket for the last seat on a plane at the same time. I don't think I'll have performance problems. I'll never have more than, say, 20 users at any given time and these race conditions will be rare. The database server can handle this easily, *in my case*. The real problem is in the user interface. The interface will be like in Address Book: the user opens a card/record for viewing, but has to click an Edit button to make changes. If the record is locked, the user will get an alert when he/she clicks the button. I need: 1. A mechanism to avoid users opening records for editing and leaving them open forever (timer?); 2. Some kind of feedback for the users when a record is unlocked, without having to refresh manually. Ideas are very welcome. Cheers, Flavio ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Oct 8, 2012, at 9:54 PM, Flavio Donadio wrote: The interface will be like in Address Book: the user opens a card/record for viewing, but has to click an Edit button to make changes. If the record is locked, the user will get an alert when he/she clicks the button. I need: 1. A mechanism to avoid users opening records for editing and leaving them open forever (timer?); This is not an easy problem, although I would say it is more of a business logic issue than a technical one. Namely, what would be the uncommitted data policy? Discard all changes? Or commit with a discard fallback (in case of validation errors)? Both approaches could lead to data integrity and customer service issues, depending on the business logic. In my most recent project I opted for a social approach: when locks are made they are forever, but when another user tries to edit the locked row the app tells them the user that locked the record, which (hopefully) provides some action of recourse, and avoids the pitfalls I mention above. 2. Some kind of feedback for the users when a record is unlocked, without having to refresh manually. It shouldn't be onerous to implement a lightweight notification system--just spin off a worker thread that handles it. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Oct 9, 2012, at 10:42 AM, Flavio Donadio wrote: On 09/10/2012, at 01:46, z...@mac.com wrote: For 2. Can you use a NSNotification to fire and forget an unlock event? Not really. The server can't send the notification back to the client. There's a RESTful web service between the client and the database. But are you merely querying the database, or do you have a facility to send messages back to the GUI? I'm querying the database only. I still can have the client poll the app server with a fair interval, but this can create overhead as more clients are added. I don't like polling at all... Yeah, I agree 100% If there are messages back so, you can set up a message relayer that can hold the current messages from the server and choose how to or when to relay them. It would require something else for the client-server communication, like the protocols Jens Alfke suggested. Or talking to the database server directly, with something like BaseTen (only for PostgreSQL). Or going low-level (e.g., libpq), which goes beyond my skills. Since I am not a dev-wizard like you guys, I have to stick to simple things! ;) Also, keep in mind this is an in-house project, never meant to be a commercial product. We can deal with some problems in ways that would not be desirable in commercial software. But, since I'm a Mac user, I want things to be as perfect as they can be I'm not a dev wizard either, but based on my experience in the late '90s and early 2000s writing a few things, I can see these few items that might bit you in unpleasant ways. 1. Multiple people trying to write to the same item. Maybe spend time to come up with an access model that grants privs based on who is accessing what? 2. Timeouts. What happens when a user has opened a record (and thereby locked a record) and their machine loses power or connectivity? How will you handle this? It's possible to write a timestamp based on GMT for when the record edit was initiated. Before displaying that record from the DB, check it and if it's than your timeout value then reset the lock on the item. 3. If you want to have your GUI respond to changes in the DB, and you have no method to yap back to the GUI, then seems like you're going to have to poll. You might want to consider how to make the basic design work, then plan on ways that you can see that it will break. You've already outlined a few of them. Though you hate polling (I mostly agree), you can implement something better, a heartbeat, where when you initiate part of your GUI, you issue a request to happen in the future where you check Am I still using this thing? If so, update the time to check again and continue for another. If you're not, immediately write the change, lock the record and dismiss the heartbeat. It's polling yeah, but I'm trying to position it differently and it would only run when you have your edit button clicked. If there is no way to read back and forth from the server, then you're going to have to poll, or write to the database to use the database to be a state engine for the requests going to the database. Seems UBER sketchy when it seems like proper timestamping of request issues and sparse polling will do the trick. GL. I'm interested in seeing how this works out Cheers, Flavio --Original Message-- From: Flavio Donadio To: Alex Zavatone Cc: Cocoa List Subject: Re: Core Data Multiuser Sent: Oct 8, 2012 11:54 PM On 08/10/2012, at 17:56, Alex Zavatone wrote: Thank you Flavio. Out of curiosity, did you encounter pessimistic vs. optimistic locking performance/data reliability issue in having many clients writing to potentially the same places at once? If so, how did each of the candidate solutions answer the problem that this poses? The problem being if there are multiple users potentially writing to the same place at once, locking records during each write is too slow, but if you don't do this, you end up with the potential of two (or more) people writing to a record at once. An example of this in real life is if both of us try to book a ticket for the last seat on a plane at the same time. I don't think I'll have performance problems. I'll never have more than, say, 20 users at any given time and these race conditions will be rare. The database server can handle this easily, *in my case*. The real problem is in the user interface. The interface will be like in Address Book: the user opens a card/record for viewing, but has to click an Edit button to make changes. If the record is locked, the user will get an alert when he/she clicks the button. I need: 1. A mechanism to avoid users opening records for editing and leaving them open forever (timer?); 2. Some kind of feedback for the users when a record is unlocked, without having to refresh manually. Ideas are very welcome. Cheers, Flavio
Re: Core Data Multiuser
On 09/10/2012, at 11:57, Keary Suska wrote: This is not an easy problem, although I would say it is more of a business logic issue than a technical one. Namely, what would be the uncommitted data policy? Discard all changes? Or commit with a discard fallback (in case of validation errors)? Both approaches could lead to data integrity and customer service issues, depending on the business logic. I thought about this. Then I started to think about crazy timer ideas... And then gave up. :) In my most recent project I opted for a social approach: when locks are made they are forever, but when another user tries to edit the locked row the app tells them the user that locked the record, which (hopefully) provides some action of recourse, and avoids the pitfalls I mention above. I thought about this too and I am getting more and more fond of this idea each minute... Cheers, Flavio ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On 09/10/2012, at 12:10, Alex Zavatone wrote: 3. If you want to have your GUI respond to changes in the DB, and you have no method to yap back to the GUI, then seems like you're going to have to poll. You might want to consider how to make the basic design work, then plan on ways that you can see that it will break. You've already outlined a few of them. Though you hate polling (I mostly agree), you can implement something better, a heartbeat, where when you initiate part of your GUI, you issue a request to happen in the future where you check Am I still using this thing? If so, update the time to check again and continue for another. If you're not, immediately write the change, lock the record and dismiss the heartbeat. It's polling yeah, but I'm trying to position it differently and it would only run when you have your edit button clicked. This heartbeat idea is nice. I could implement this, but still also implement Keary's idea (user trying to edit a locked row will get a message saying who is currently editing it). So, if the client hangs, disconnects (kind of wrong term, because it's HTTP) or loses power, after a certain number of missed heartbeats, changes are discarded and the row is unlocked. If the user tries to edit a locked row, he/she gets notified that username is editing this record now. He can then wait, call username's extension, send a message, or simply throw something at him/her! :) After negotiating with the user that's editing the row, all that is needed is to refresh the view. This way, I wouldn't even require early feedback about a record being locked or not. I think we can call this case closed (it's also gone a little off topic). Thanks again for all the ideas! Cheers, Flavio ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Hello, all! This a follow-up to a thread started last July. I looked into a lot of things, tested some crazy ideas (that went wrong) and came to my final decision for my project. I consider it very important to let people know what I decided. Maybe I can help someone. And, for sure, you guys can warn me if I'm making the wrong decision. I can say, for sure, that sharing the SQLite database is a bad idea if you have a busy and slow network. The Distributed Objects idea is not so bad, but gives a lot of headaches: the implementation of your business-logic ends up being composed of 90% error handling code. I also dismissed the real-time updates idea. The user will have to refresh the view manually. It saves a lot of effort and users will not get confused by table views changing unexpectedly, for example. So, for the back-end (server side), I'll be using WebObjects to develop a RESTful web service. I chose WebObjects because it's proven, it works very well (Apple uses it on their app stores and iTunes) and it uses a language that is kind of familiar to me (being used to PHP and a couple of C variants). Also, the framework's design patterns are very similar to Cocoa. The development tools are good enough and try to mimic the old tools that Apple provided. It can be deployed on Mac OS X, Linux and others, using standard Java application servers. The WO community seems to be very strong, united and helpful (just check how busy the webobjects-dev list is today). Another reason why I chose this over TouchDB or protocols like SPDY and BLiP, is that I can use a RESTful service with anything. In the future, I could develop clients for different platforms. And WebObjects helps a lot when creating HTML-based interfaces. I looked into Ruby on Rails as an option, but since the Ruby language is very different from everything I know, I chose not to go that route. For the front-end, I'll develop a Cocoa client using ActiveResourceKit (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, it's the most straight forward to use, and the most feature-complete framework for consuming RESTful web services. I also looked into AFIncrementalStore and RESTKit. Kudos to Steve Steinitz, Jens Alfke, Chris Hanson and Alexander Spohr for the tips. Cheers, Flavio On 18/07/2012, at 16:00, Flavio Donadio wrote: Steve, I agree with Apple, SQLite, you and every other sensible developer out there: I won't try this! :) Cheers, Flavio On 18/07/2012, at 04:49, Steve Steinitz wrote: Hi Flavio, While Apple, SQLite, myself and any sensible software developer advise against it, Core Data can run multi-user by placing the database on a server which supports AFP (e.g. a fast Synology NAS over gigabit ethernet). SQLite has limited optimistic locking support, but the record locking will only work over AFP. As mentioned elsewhere, you still have the (big) problem of keeping the cached objects of each Mac up to date. We do it by getting fresh data from the database, then saving, every minute (plus or minus random seconds) during idle time. The refresh code is complicated, ugly and big -- with bad smells abounding. To make it work at all in Leopard and beyond (when Apple finally put their foot down on this abomination) you need to set a special Apple SQL pragma when creating your persistent store. Our line of code looks like this: [pragmaOptions setObject: [NSNull null] forKey: @lock_proxy_file]; A retailer has been doing this for their Point of Sale (and back-office) on seven Macs for six years. We lost a little data a couple times in the early days and we occasionally get a glitch under heavy Saturday load, but we've tamed the beast and now it works surprisingly well -- and fast. Be warned that there are, as Ben Trumbull once colorfully observed, sharp edges. Cheers, Steve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Mon, Oct 8, 2012, at 08:40 AM, Flavio Donadio wrote: Hello, all! This a follow-up to a thread started last July. I looked into a lot of things, tested some crazy ideas (that went wrong) and came to my final decision for my project. I consider it very important to let people know what I decided. Maybe I can help someone. And, for sure, you guys can warn me if I'm making the wrong decision. I can say, for sure, that sharing the SQLite database is a bad idea if you have a busy and slow network. The Distributed Objects idea is not so bad, but gives a lot of headaches: the implementation of your business-logic ends up being composed of 90% error handling code. I also dismissed the real-time updates idea. The user will have to refresh the view manually. It saves a lot of effort and users will not get confused by table views changing unexpectedly, for example. I agree with all of your decisions. So, for the back-end (server side), I'll be using WebObjects to develop a RESTful web service. I chose WebObjects because it's proven, it works very well (Apple uses it on their app stores and iTunes) and it uses a language that is kind of familiar to me (being used to PHP and a couple of C variants). Also, the framework's design patterns are very similar to Cocoa. The development tools are good enough and try to mimic the old tools that Apple provided. It can be deployed on Mac OS X, Linux and others, using standard Java application servers. The WO community seems to be very strong, united and helpful (just check how busy the webobjects-dev list is today). We still run WO 4.5 to power our own store, but we go through some major hoops to do so. Personally, I'd be inclined to choose a more stable and up-to-date technology, but I'm not a server-side programmer. For the front-end, I'll develop a Cocoa client using ActiveResourceKit (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, it's the most straight forward to use, and the most feature-complete framework for consuming RESTful web services. Have you heard of NSIncrementalStore? If you can target Lion and iOS 5, you can continue to use Core Data on the client while communicating with whatever backend and over whatever protocol you choose. Good luck on your project. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Kyle, I like your points and I considered them. It's been 3 months of hair-pulling and I still have some uncertainty about my choices. But I think I made the best decisions, and here's why... We still run WO 4.5 to power our own store, but we go through some major hoops to do so. Personally, I'd be inclined to choose a more stable and up-to-date technology, but I'm not a server-side programmer. WebObjects, in reality, is just a framework. A huge one, to say the least. Users swear by it and think it's still better than Rails, even though it's a decade older! It's very stable too. The true technology behind WO is Java EE. It's a mature and stable platform and has broad adoption. I am sure it's up-to-date (whatever that means, in this case :-) ) The community has been doing a great work to keep it easy to develop WO/EOF apps with Eclipse, since Apple discontinued the official development tools. They also try to improve, fix bugs and work around deprecated Java API's. I've heard (but can't confirm) that Apple uses these same tools (Eclipse, WOLips and the WOnder frameworks) for their projects. So, I think it's a good decision. For the front-end, I'll develop a Cocoa client using ActiveResourceKit (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, it's the most straight forward to use, and the most feature-complete framework for consuming RESTful web services. Have you heard of NSIncrementalStore? If you can target Lion and iOS 5, you can continue to use Core Data on the client while communicating with whatever backend and over whatever protocol you choose. ActiveResourceKit is based on NSIncrementalStore. It can consume any RESTful web service with very little code, just like any other Core Data store. It's available for Mac OS X and iOS. Check it out. It looks and feels awesome -- although I still didn't spend much time with it... Cheers, Flavio ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Thank you Flavio. Out of curiosity, did you encounter pessimistic vs. optimistic locking performance/data reliability issue in having many clients writing to potentially the same places at once? If so, how did each of the candidate solutions answer the problem that this poses? The problem being if there are multiple users potentially writing to the same place at once, locking records during each write is too slow, but if you don't do this, you end up with the potential of two (or more) people writing to a record at once. An example of this in real life is if both of us try to book a ticket for the last seat on a plane at the same time. We ran into this while modernizing US Food's internal system of everything from COBOL to something else. I'd expect this issue to be of core importance to any multi user or multi homed database. Just curious. Thanks. On Oct 8, 2012, at 11:40 AM, Flavio Donadio wrote: Hello, all! This a follow-up to a thread started last July. I looked into a lot of things, tested some crazy ideas (that went wrong) and came to my final decision for my project. I consider it very important to let people know what I decided. Maybe I can help someone. And, for sure, you guys can warn me if I'm making the wrong decision. I can say, for sure, that sharing the SQLite database is a bad idea if you have a busy and slow network. The Distributed Objects idea is not so bad, but gives a lot of headaches: the implementation of your business-logic ends up being composed of 90% error handling code. I also dismissed the real-time updates idea. The user will have to refresh the view manually. It saves a lot of effort and users will not get confused by table views changing unexpectedly, for example. So, for the back-end (server side), I'll be using WebObjects to develop a RESTful web service. I chose WebObjects because it's proven, it works very well (Apple uses it on their app stores and iTunes) and it uses a language that is kind of familiar to me (being used to PHP and a couple of C variants). Also, the framework's design patterns are very similar to Cocoa. The development tools are good enough and try to mimic the old tools that Apple provided. It can be deployed on Mac OS X, Linux and others, using standard Java application servers. The WO community seems to be very strong, united and helpful (just check how busy the webobjects-dev list is today). Another reason why I chose this over TouchDB or protocols like SPDY and BLiP, is that I can use a RESTful service with anything. In the future, I could develop clients for different platforms. And WebObjects helps a lot when creating HTML-based interfaces. I looked into Ruby on Rails as an option, but since the Ruby language is very different from everything I know, I chose not to go that route. For the front-end, I'll develop a Cocoa client using ActiveResourceKit (https://github.com/royratcliffe/ActiveResourceKit). From what I've seen, it's the most straight forward to use, and the most feature-complete framework for consuming RESTful web services. I also looked into AFIncrementalStore and RESTKit. Kudos to Steve Steinitz, Jens Alfke, Chris Hanson and Alexander Spohr for the tips. Cheers, Flavio On 18/07/2012, at 16:00, Flavio Donadio wrote: Steve, I agree with Apple, SQLite, you and every other sensible developer out there: I won't try this! :) Cheers, Flavio On 18/07/2012, at 04:49, Steve Steinitz wrote: Hi Flavio, While Apple, SQLite, myself and any sensible software developer advise against it, Core Data can run multi-user by placing the database on a server which supports AFP (e.g. a fast Synology NAS over gigabit ethernet). SQLite has limited optimistic locking support, but the record locking will only work over AFP. As mentioned elsewhere, you still have the (big) problem of keeping the cached objects of each Mac up to date. We do it by getting fresh data from the database, then saving, every minute (plus or minus random seconds) during idle time. The refresh code is complicated, ugly and big -- with bad smells abounding. To make it work at all in Leopard and beyond (when Apple finally put their foot down on this abomination) you need to set a special Apple SQL pragma when creating your persistent store. Our line of code looks like this: [pragmaOptions setObject: [NSNull null] forKey: @lock_proxy_file]; A retailer has been doing this for their Point of Sale (and back-office) on seven Macs for six years. We lost a little data a couple times in the early days and we occasionally get a glitch under heavy Saturday load, but we've tamed the beast and now it works surprisingly well -- and fast. Be warned that there are, as Ben Trumbull once colorfully observed, sharp edges. Cheers, Steve ___ Cocoa-dev mailing list
Re: Core Data Multiuser
On 08/10/2012, at 17:56, Alex Zavatone wrote: Thank you Flavio. Out of curiosity, did you encounter pessimistic vs. optimistic locking performance/data reliability issue in having many clients writing to potentially the same places at once? If so, how did each of the candidate solutions answer the problem that this poses? The problem being if there are multiple users potentially writing to the same place at once, locking records during each write is too slow, but if you don't do this, you end up with the potential of two (or more) people writing to a record at once. An example of this in real life is if both of us try to book a ticket for the last seat on a plane at the same time. I don't think I'll have performance problems. I'll never have more than, say, 20 users at any given time and these race conditions will be rare. The database server can handle this easily, *in my case*. The real problem is in the user interface. The interface will be like in Address Book: the user opens a card/record for viewing, but has to click an Edit button to make changes. If the record is locked, the user will get an alert when he/she clicks the button. I need: 1. A mechanism to avoid users opening records for editing and leaving them open forever (timer?); 2. Some kind of feedback for the users when a record is unlocked, without having to refresh manually. Ideas are very welcome. Cheers, Flavio ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Hi Flavio, While Apple, SQLite, myself and any sensible software developer advise against it, Core Data can run multi-user by placing the database on a server which supports AFP (e.g. a fast Synology NAS over gigabit ethernet). SQLite has limited optimistic locking support, but the record locking will only work over AFP. As mentioned elsewhere, you still have the (big) problem of keeping the cached objects of each Mac up to date. We do it by getting fresh data from the database, then saving, every minute (plus or minus random seconds) during idle time. The refresh code is complicated, ugly and big -- with bad smells abounding. To make it work at all in Leopard and beyond (when Apple finally put their foot down on this abomination) you need to set a special Apple SQL pragma when creating your persistent store. Our line of code looks like this: [pragmaOptions setObject: [NSNull null] forKey: @lock_proxy_file]; A retailer has been doing this for their Point of Sale (and back-office) on seven Macs for six years. We lost a little data a couple times in the early days and we occasionally get a glitch under heavy Saturday load, but we've tamed the beast and now it works surprisingly well -- and fast. Be warned that there are, as Ben Trumbull once colorfully observed, sharp edges. Cheers, Steve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Steve, I agree with Apple, SQLite, you and every other sensible developer out there: I won't try this! :) Cheers, Flavio On 18/07/2012, at 04:49, Steve Steinitz wrote: Hi Flavio, While Apple, SQLite, myself and any sensible software developer advise against it, Core Data can run multi-user by placing the database on a server which supports AFP (e.g. a fast Synology NAS over gigabit ethernet). SQLite has limited optimistic locking support, but the record locking will only work over AFP. As mentioned elsewhere, you still have the (big) problem of keeping the cached objects of each Mac up to date. We do it by getting fresh data from the database, then saving, every minute (plus or minus random seconds) during idle time. The refresh code is complicated, ugly and big -- with bad smells abounding. To make it work at all in Leopard and beyond (when Apple finally put their foot down on this abomination) you need to set a special Apple SQL pragma when creating your persistent store. Our line of code looks like this: [pragmaOptions setObject: [NSNull null] forKey: @lock_proxy_file]; A retailer has been doing this for their Point of Sale (and back-office) on seven Macs for six years. We lost a little data a couple times in the early days and we occasionally get a glitch under heavy Saturday load, but we've tamed the beast and now it works surprisingly well -- and fast. Be warned that there are, as Ben Trumbull once colorfully observed, sharp edges. Cheers, Steve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Mon, 16 Jul 2012 14:39:42 -0700, Jens Alfke j...@mooseyard.com wrote: (1) Client-server. The database lives on one server machine, as does the business logic (I hate that term) that manages your app. This could definitely be implemented with Core Data if you like. The client app just focuses on the UI, and there is some protocol by which it talks to the server to fetch data and to tell it to do stuff. In other words, the client app will not use Core Data. Using the CoreDataIncrementalStore-API you can write your own persistence layer under CoreData and use the technology you want to. I've written a CoreDataIncrementalStore to support the Valentina Database-Server. Now I can use all given Apple technology in the GUI but for a multi user environment. Of course you still need to think about how to keep the clients synchronized or not or concurrency, but THIS has nothing todo with CoreData but is a general question when designing a multi-user db-app. regards Thorsten Hohage -- objectmanufactur.com - Hamburg,Germany ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Chris, I already took a look at NSIncrementalStore and it seems to solve one of my problems. I am fairly good with PHP, but I could always create a web service with Rails or something else... One of my gripes with using HTTP as the client-server base protocol is the request-response loop. This breaks a lot of desirable features. In my particular case, I want my users to receive real-time updates when other users edit records on the database (not really real-time, but at least after a COMMIT on the database). I know there are ways to do this with HTTP nowadays, but it feels so cumbersome (I mean, at least when compared to the way KVO implements similar behavior) that I don't even want to touch that. Maybe I am too focused on the beauties of Cocoa and can't see any further... But... So far, IMO, the best option in terms of functionality for my project is the BaseTen framework. It feels like Core Data, uses Core Data model documents and supports PostgreSQL's LISTEN and NOTIFY commands (and a lot more). I think I would have to buy a license because, although my app will not be sold, it will be used in my business and I don't think the GPL allows that. My only fear is the project's future and the fact that [currently] I am not so proficient in Cocoa to fiddle with BaseTen's internals, if I ever need to... I am still open to ideas... Cheers, Flavio On 16/07/2012, at 23:43, Chris Hanson wrote: On Jul 16, 2012, at 2:39 PM, Jens Alfke j...@mooseyard.com wrote: (1) Client-server. The database lives on one server machine, as does the business logic (I hate that term) that manages your app. This could definitely be implemented with Core Data if you like. The client app just focuses on the UI, and there is some protocol by which it talks to the server to fetch data and to tell it to do stuff. In other words, the client app will not use Core Data. Another option for client-server is to create an NSIncrementalStore subclass to use on the client, regardless of what you use on the server. The server could be an XML or JSON-based REST web service written using any of a variety of frameworks, the server could be a Mac running a Core Data-based server using a custom protocol you design, the server could be an old mainframe running COBOL... Your NSIncrementalStore subclass can act as an adaptor between it and the rest of your application, allowing your application to be written using Core Data and allowing it to take advantage of its features. -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Jul 17, 2012, at 7:05 AM, Flavio Donadio fla...@donadio.com.br wrote: One of my gripes with using HTTP as the client-server base protocol is the request-response loop. This breaks a lot of desirable features. In my particular case, I want my users to receive real-time updates when other users edit records on the database (not really real-time, but at least after a COMMIT on the database). There are alternative message-oriented protocols that allow either side of the connection to send messages (and are more efficient than HTTP, too.) Google's SPDY[1] is one, and my own BLIP[2] is another. —Jens [1]: http://www.chromium.org/spdy/ [2]: https://bitbucket.org/snej/mynetwork/wiki/BLIP/Overview ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Jul 17, 2012, at 7:05 AM, Flavio Donadio fla...@donadio.com.br wrote: I already took a look at NSIncrementalStore and it seems to solve one of my problems. I am fairly good with PHP, but I could always create a web service with Rails or something else… On the client side, it doesn’t matter what you use on the server side to create a web service. And vice-versa. One of my gripes with using HTTP as the client-server base protocol is the request-response loop. This breaks a lot of desirable features. In my particular case, I want my users to receive real-time updates when other users edit records on the database (not really real-time, but at least after a COMMIT on the database). Very few systems will actually do this for you, as it’s almost always *not* a desirable feature. For example, even if you use NSIncrementalStore to implement Core Data access to a web service, you won’t get this kind of functionality. In general, users A and B may both be looking at their own internally-consistent data sets. If user A changes something that’s also part of what user B is looking at, you almost always want to keep user B’s view of the data the same until they either explicitly choose to refresh their view, or until they actually attempt to save their own changes. At that point you can allow user B to resolve the conflict between their own changes and user A’s changes to the same objects. This is part of why there’s no “easy multiuser” in data management frameworks: The choices that need to be made often boil down to user experience, and can vary dramatically from one application to the next. -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Jul 13, 2012, at 12:38 PM, Flavio Donadio fla...@donadio.com.br wrote: On chapter 11, the book talks about distributed Core Data, using Distributed Objects to exchange NSManagedObjects between a client app and a server app. The latter deals with the MOC and the persistent store. Zarra warns about scalability problems, since NSManagedObjectContext is not thread-safe and, the, all clients' data would be dealt with serially... But, what if I used one MOC per client? In my experience — and yes I have tried it — using DO between multiple computers is a nightmare. I know it sounds so simple and appealing, but that's because it tries to sweep all the hard problems of networking[1] under the rug. The problems remain, and will bite you, hard. The inconvenient truth is that sending a message over a network is not at all the same as sending an Objective-C message between two objects, no matter what kind of clever wrapping is used to make it look like it. Network messages are orders of magnitude slower, they are unreliable for many different reasons, and they're not trustable unless you are very, very careful about authentication and sandboxing. There are basically two realistic ways to do what you want to do: (1) Client-server. The database lives on one server machine, as does the business logic (I hate that term) that manages your app. This could definitely be implemented with Core Data if you like. The client app just focuses on the UI, and there is some protocol by which it talks to the server to fetch data and to tell it to do stuff. In other words, the client app will not use Core Data. (2) Synchronized. Every client has a copy of the database, and the app operates on the local database. But the clients have to stay in sync by sending messages to the server whenever they make changes, and receiving notifications from the server when some other client makes a change. If conflicting changes are made, there has to be a way to resolve them. The bad news: Approach #1 is straightforward but means you have to abandon Core Data on the client, and design and implement your own network protocol, which is time-consuming. Approach #2 is lovely when it works but I assure you from experience that synchronization is very, very difficult to implement from scratch. I hate to make this post sound like an ad, but I'm developing (for my employer, Couchbase) a framework that implements #2. It's based on CouchDB[2], a very popular nonrelational (NoSQL) distributed database that is really, really good at synchronization. My framework, TouchDB,[3] lets Mac or iOS or Android apps store databases locally, operate on them locally, and then replicate in real time with a CouchDB server. If there are multiple clients syncing with the same server, it's exactly the solution #2 I outlined above. Now, TouchDB isn't compatible with Core Data. But it does have a pretty solid Cocoa API that has an object-model layer a bit like a simplified Core Data. The people who've been using it like it a lot. —Jens [1]: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing [2]: http://couchdb.apache.org [3]: http://touchdb.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On 16/07/2012, at 18:39, Jens Alfke wrote: In my experience — and yes I have tried it — using DO between multiple computers is a nightmare. I know it sounds so simple and appealing, but that's because it tries to sweep all the hard problems of networking[1] under the rug. The problems remain, and will bite you, hard. [...] The bad news: Approach #1 is straightforward but means you have to abandon Core Data on the client, and design and implement your own network protocol, which is time-consuming. Approach #2 is lovely when it works but I assure you from experience that synchronization is very, very difficult to implement from scratch. Well... This is one of the more down-to-earth arguments about why I should steer away from this technique. Coming from you, Jens, I can't ignore it. I hate to make this post sound like an ad, but I'm developing (for my employer, Couchbase) a framework that implements #2. It's based on CouchDB[2], a very popular nonrelational (NoSQL) distributed database that is really, really good at synchronization. My framework, TouchDB,[3] lets Mac or iOS or Android apps store databases locally, operate on them locally, and then replicate in real time with a CouchDB server. If there are multiple clients syncing with the same server, it's exactly the solution #2 I outlined above. I've just took a look at the links you sent and I'm downloading TouchDB. I'll have a careful look at it soon. Now, TouchDB isn't compatible with Core Data. But it does have a pretty solid Cocoa API that has an object-model layer a bit like a simplified Core Data. The people who've been using it like it a lot. To be honest, I know a little about Cocoa and can write almost any simple app you can imagine. Core Data is not, by any measure, a simple framework. I think I understand it, so it feels comfortable for me to try and stick with it. But it doesn't have to be Core Data. It must be Cocoa, though. Cheers, Flavio ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Jul 16, 2012, at 4:11 PM, Flavio Donadio fla...@donadio.com.br wrote: To be honest, I know a little about Cocoa and can write almost any simple app you can imagine. Core Data is not, by any measure, a simple framework. I think I understand it, so it feels comfortable for me to try and stick with it. But it doesn't have to be Core Data. It must be Cocoa, though. To be honest, I never really got comfortable with Core Data. It always seemed to be very complex to do anything real with it, and there was a lot of boilerplate to set it up. (That was 5+ years ago, though. Maybe it's gotten simpler ;-) One of the nice things about CouchDB-like databases is that everything is JSON, which is a kissing cousin of a PList, so you can treat your data like property-lists if you want. Or alternatively, the CouchModel class lets you treat data items as objects with custom properties, which can often make the code cleaner. But the choice is yours, and you can in fact mix the two approaches. (I did a presentation about this a few months ago: http://www.youtube.com/watch?v=U4h90TgWan0. Just wherever it says Couchbase Mobile, think TouchDB.) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Jul 16, 2012, at 2:39 PM, Jens Alfke j...@mooseyard.com wrote: (1) Client-server. The database lives on one server machine, as does the business logic (I hate that term) that manages your app. This could definitely be implemented with Core Data if you like. The client app just focuses on the UI, and there is some protocol by which it talks to the server to fetch data and to tell it to do stuff. In other words, the client app will not use Core Data. Another option for client-server is to create an NSIncrementalStore subclass to use on the client, regardless of what you use on the server. The server could be an XML or JSON-based REST web service written using any of a variety of frameworks, the server could be a Mac running a Core Data-based server using a custom protocol you design, the server could be an old mainframe running COBOL... Your NSIncrementalStore subclass can act as an adaptor between it and the rest of your application, allowing your application to be written using Core Data and allowing it to take advantage of its features. -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
On Jul 14, 2012, at 5:18 AM, Alexander Spohr wrote: Am 13.07.2012 um 21:38 schrieb Flavio Donadio: What do you guys think about it? Is it a bad idea? I've studied a lot of alternatives (BaseTen, ODBC, Web Services), but I can't wrap my head around them... Use WebObjects and EOF (the big mature brother of CoreData) on the server! We feed multiple hundred thousand iOS devices daily with it - as does Apple with iTunes and the Store. Um, what? Hasn't WebObjects effectively been orphaned [as in, Apple may still be using it internally, but they are no longer publicly updating it or providing support for it]? And yes, I agree it was kickass technology that I wish Apple would at least sell to somebody else to make a product out of instead just letting it die. As for the OP's request, might I suggest using the BaseTen framework. Its an open-source PostgreSQL-backed database framework that works like CoreData [it even uses the CoreData database layout file to configure PostgreSQL]. Eli ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Am 15.07.2012 um 08:12 schrieb Eli Bach2: On Jul 14, 2012, at 5:18 AM, Alexander Spohr wrote: Am 13.07.2012 um 21:38 schrieb Flavio Donadio: Use WebObjects and EOF (the big mature brother of CoreData) on the server! We feed multiple hundred thousand iOS devices daily with it - as does Apple with iTunes and the Store. Um, what? Apple may still be using it internally, but they are no longer publicly updating it or providing support for it? Support is here: http://www.wocommunity.org/ We started our current project a year ago. WebObjects still does fine with heavy workloads. atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data Multiuser
Am 13.07.2012 um 21:38 schrieb Flavio Donadio: What do you guys think about it? Is it a bad idea? I've studied a lot of alternatives (BaseTen, ODBC, Web Services), but I can't wrap my head around them... Use WebObjects and EOF (the big mature brother of CoreData) on the server! We feed multiple hundred thousand iOS devices daily with it - as does Apple with iTunes and the Store. atze ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
re: Core Data : Multiuser ?
Can more than one process be accessing the same Core Data sqlite file? This post from author Marcus Zarra says no∑ http://forums.pragprog.com/forums/90/topics/1476 But this post from Ben Trumbull seems to say yes, as long as the two processes are accessing it via the same filesystem: http://www.cocoabuilder.com/archive/cocoa/184606-core-data-file-sharing-via-an-afp-alias.html Which one am I misunderstanding? There is a big difference between multiple processes accessing the same Core Data file and multiple machines. Multiple processes on the same local machine work fine. Several Apple products do this. Multiple processes across multiple physical machines will not work well (AFP) or at all (NFS). So we don't recommend targeting a multi-user configuration. As I mentioned in that earlier post, your best bet is probably write the proper service that uses Core Data, and vends to your client processes via IPC (like a web service). The client processes might independently use Core Data for local caching (replication). It possible, but inefficient, for a very limited number of clients to share over AFP. NFS doesn't work correctly at all. This is restricted by file caching issues underneath us. There are a lot of limitations and sharp edges here, so we actively recommend against multiple computers simultaneously accessing the same db. Support for it is disabled by default for projects built with a deployment target = 10.6 - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
re: Core Data : Multiuser ?
p.s. http://www.cocoabuilder.com/archive/cocoa/283632-coredata-database-sharing-and-migration.html#283632 - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Multiuser ?
Given those limitations, how does one enable support for a 10.6+ target? On Aug 6, 2010, at 11:38 PM, Ben Trumbull wrote: It possible, but inefficient, for a very limited number of clients to share over AFP. NFS doesn't work correctly at all. This is restricted by file caching issues underneath us. There are a lot of limitations and sharp edges here, so we actively recommend against multiple computers simultaneously accessing the same db. Support for it is disabled by default for projects built with a deployment target = 10.6 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Multiuser ?
I've been developing an app meant to run strictly on a local network. I'd like to have the capacity to run 50 clients and a single server (although most installations will have fewer than 20 clients). My plan has been to have each client maintain its own Core Data database and sync with the Core Data db on the server. I've been using BLIP to message over TCP. Communication should work like this: 1. Client sends command to server 2. Server updates its CD db 3. On a didSave notification, server messages changes to all connected clients 4. Connected clients receive the update message and update their db's accordingly 5. If a client is offline for a period of time, when it rejoins the network, it asks the server for a batch update (I haven't decided whether this will request the entire data file as it stands at that moment, or just ask for incremental changes since the client's last save, but I'm leaning towards re-sending the entire db, which is typically smaller than 1 MB) In my app, objects are infrequently being created and destroyed. The changes are primarily just attributes of existing objects being updated. I don't believe this runs afoul of the patterns Ben is describing, does it? I'm not sharing the Core Data db, I'm just keeping several Core Data db's in sync by providing methods on the server that each client can call remotely. Also, I attended a session at WWDC this year that describes extending Core Data for use in a multi-user environment. I'd have to watch the video again to get the specifics, but, I think the gist of it was to keep a local copy of the data and sync with the server. I hope rampant speculation about an unannounced OS doesn't run afoul of any NDAs, but, I've got to believe that Apple is working on extending Core Data for use in a multi-user environment. With iPhone, iPad and desktop users and Apple's recent push into SMB, accessing a central database from each of these devices via Core Data just makes too much sense. Maybe it isn't exactly Core Data and maybe it's some tie-in to FileMaker, but, I've got to believe it's a priority for them. It's just too big of a nut to ignore. Brad On Aug 6, 2010, at 11:38 PM, Ben Trumbull wrote: Can more than one process be accessing the same Core Data sqlite file? This post from author Marcus Zarra says no∑ http://forums.pragprog.com/forums/90/topics/1476 But this post from Ben Trumbull seems to say yes, as long as the two processes are accessing it via the same filesystem: http://www.cocoabuilder.com/archive/cocoa/184606-core-data-file-sharing-via-an-afp-alias.html Which one am I misunderstanding? There is a big difference between multiple processes accessing the same Core Data file and multiple machines. Multiple processes on the same local machine work fine. Several Apple products do this. Multiple processes across multiple physical machines will not work well (AFP) or at all (NFS). So we don't recommend targeting a multi-user configuration. As I mentioned in that earlier post, your best bet is probably write the proper service that uses Core Data, and vends to your client processes via IPC (like a web service). The client processes might independently use Core Data for local caching (replication). It possible, but inefficient, for a very limited number of clients to share over AFP. NFS doesn't work correctly at all. This is restricted by file caching issues underneath us. There are a lot of limitations and sharp edges here, so we actively recommend against multiple computers simultaneously accessing the same db. Support for it is disabled by default for projects built with a deployment target = 10.6 - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/bradgibbs%40mac.com This email sent to bradgi...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Multiuser ?
Which session are we talking about? I'd like to go watch that video and I don't recall seeing it. As for the second bit, I'm not so sure... If they had wanted to port EOF they would have just ported EOF. Of course, I could be wrong but I'm not holding my breath for robust, multi-user Core Data. Hunter On Aug 7, 2010, at 8:43 AM, Brad Gibbs wrote: Also, I attended a session at WWDC this year that describes extending Core Data for use in a multi-user environment. I'd have to watch the video again to get the specifics, but, I think the gist of it was to keep a local copy of the data and sync with the server. I hope rampant speculation about an unannounced OS doesn't run afoul of any NDAs, but, I've got to believe that Apple is working on extending Core Data for use in a multi-user environment. With iPhone, iPad and desktop users and Apple's recent push into SMB, accessing a central database from each of these devices via Core Data just makes too much sense. Maybe it isn't exactly Core Data and maybe it's some tie-in to FileMaker, but, I've got to believe it's a priority for them. It's just too big of a nut to ignore. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Multiuser ?
When you add the persistent store to the coordinator, in the store options dictionary, use the option NSSQLitePragmasOption (which is a sub dictionary of pragma keys values) to pass the @lock_proxy_file key with a value of NSNull. - Ben On Aug 7, 2010, at 7:17 AM, Hunter Hillegas wrote: Given those limitations, how does one enable support for a 10.6+ target? On Aug 6, 2010, at 11:38 PM, Ben Trumbull wrote: It possible, but inefficient, for a very limited number of clients to share over AFP. NFS doesn't work correctly at all. This is restricted by file caching issues underneath us. There are a lot of limitations and sharp edges here, so we actively recommend against multiple computers simultaneously accessing the same db. Support for it is disabled by default for projects built with a deployment target = 10.6 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Multiuser ?
It's Session 117 - Building a Server-Driven User Experience. About half-way through they move to a discussion involving Core Data. It's clear that at least some people at Apple have spent some time thinking about this. On Aug 7, 2010, at 8:53 AM, Hunter Hillegas wrote: Which session are we talking about? I'd like to go watch that video and I don't recall seeing it. As for the second bit, I'm not so sure... If they had wanted to port EOF they would have just ported EOF. Of course, I could be wrong but I'm not holding my breath for robust, multi-user Core Data. Hunter On Aug 7, 2010, at 8:43 AM, Brad Gibbs wrote: Also, I attended a session at WWDC this year that describes extending Core Data for use in a multi-user environment. I'd have to watch the video again to get the specifics, but, I think the gist of it was to keep a local copy of the data and sync with the server. I hope rampant speculation about an unannounced OS doesn't run afoul of any NDAs, but, I've got to believe that Apple is working on extending Core Data for use in a multi-user environment. With iPhone, iPad and desktop users and Apple's recent push into SMB, accessing a central database from each of these devices via Core Data just makes too much sense. Maybe it isn't exactly Core Data and maybe it's some tie-in to FileMaker, but, I've got to believe it's a priority for them. It's just too big of a nut to ignore. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Multiuser ?
On Fri, Aug 6, 2010 at 4:51 PM, Jerry Krinock je...@ieee.org wrote: Which one am I misunderstanding? Neither, but the world has changed: http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01026.html Short answer: it's not supported. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Multiuser ?
On 2010 Aug 06, at 17:03, Kyle Sluder wrote: http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01026.html Short answer: it's not supported. I'm not sure, Kyle. In the message you linked to, Ben was talking about access from multiple machines. But in an earlier message in that thread, http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01000.html Ben said, Yes, several Apple frameworks use Core Data databases from multiple processes simultaneously with a single user account and single physical machine. which is what I'm interested in. Two processes, same Mac, same user. Reason: While testing an app earlier today, I saw some Core Data errors which seemed to stop when I killed a background process which may have been accessing the same non-document sqlite store. It may do this in real life. I need to go back and try to reproduce and isolate the trouble, but would appreciate any more advice on this topic. In that 2007 thread, Ben referred the poster to the sqlite documentation on file locking, which I presume is this: http://www.sqlite.org/lockingv3.html But that's not very helpful since I have no idea if, when, how or why Core Data acquires the various locks discussed in there. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data : Multiuser ?
On Aug 6, 2010, at 6:27 PM, Jerry Krinock je...@ieee.org wrote: which is what I'm interested in. Two processes, same Mac, same user. Okay, when you said same filesystem, I immediately thought you wanted clarification on AFP vs. SMB vs. NFS. --Kyle Sluder___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
