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:

Core Data Multiuser

Hello, people! I'll bring this subject to surface again. I know it pops here and there from time to time, but I've never seen anything conclusive, besides advice to steer off this idea. For a long time, I have wanted to develop a "pseudo-CRM" software for my small business. It will be used fo

Re: Core Data : Multiuser ?

On Fri, Aug 6, 2010 at 4:51 PM, Jerry Krinock 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

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 threa

Re: Core Data : Multiuser ?

On Aug 6, 2010, at 6:27 PM, Jerry Krinock 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___

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

re: Core Data : Multiuser ?

p.s. - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the

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 un

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 Co

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.

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:

Re: Core Data : Multiuser ?

On Aug 7, 2010, at 8:43 AM, Brad Gibbs wrote: > 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

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 w

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

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 an

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

Re: Core Data Multiuser

On Jul 13, 2012, at 12:38 PM, Flavio Donadio 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 scal

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 r

Re: Core Data Multiuser

On Jul 16, 2012, at 4:11 PM, Flavio Donadio 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

Re: Core Data Multiuser

On Jul 16, 2012, at 2:39 PM, Jens Alfke 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

Re: Core Data Multiuser

On Mon, 16 Jul 2012 14:39:42 -0700, Jens Alfke 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

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. Thi

Re: Core Data Multiuser

On Jul 17, 2012, at 7:05 AM, Flavio Donadio 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 rec

Re: Core Data Multiuser

On Jul 17, 2012, at 7:05 AM, Flavio Donadio 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

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 locki

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 mu

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 c

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 >

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. > > Pers

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 be

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 solutio

Re: Core Data Multiuser

On 9 Oct 2012, at 04:54, Flavio Donadio 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

Re: Core Data Multiuser

Flavio Donadio 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 openi

Re: Core Data Multiuser

uct. 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 L

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 m

Re: Core Data Multiuser

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 &g

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 error

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