Re: Invoice program made in Objective c/Cocoa
Re: Invoice program made in Objective c/Cocoa
- Subject: Re: Invoice program made in Objective c/Cocoa
- From: Michael Ash <email@hidden>
- Date: Sun, 17 May 2009 22:01:15 -0400
On Sun, May 17, 2009 at 11:42 AM, Andreas Grosam <email@hidden> wrote:
> On May 16, 2009, at 5:09 PM, Michael Ash wrote:
>
>> On Sat, May 16, 2009 at 8:48 AM, Andreas Grosam <email@hidden>
>> wrote:
>>>>>
>>>>> I really can‘t believe this. It would be a great faux-pas! Do I really
>>>>> miss
>>>>> something? Is this limitation anywhere documented?
>>>>
>>>> You say "limitation," the rest of the world says "design principle."
>>>
>>> A design "principle"? Call it how you like but a database application
>>> does
>>> not have this principle. The opposite is true - it is an anti principle,
>>> or
>>> in other words, any framework that supports any database application
>>> shall
>>> not be single user, single transaction context, non-transactional.
>>>
>>> This design "principle" severely limits the number of useful
>>> applications.
>>
>> It also severely limits the design complexity and implementation work.
>>
>> I really don't understand what the problem is here.
>
> The problem here is, that although Core Data is really great to implement
> your application model it appears that you cannot use Core Data for storing
> your data model in multi user databases. As a consequence, Core Data is
> basically inapplicable for multi user database applications.
I don't understand why that's a problem. That's how it works. That's
how it's *designed*. It's like complaining that your car doesn't fly.
>> CoreData never
>> claimed to do what you want it to do. It is VERY CLEAR about what it's
>> for and how it works.
>
> No, at the first glance it is/was not very clear to me (and many others,
> too) that Core Data is not and will never be for multi user applications.
> What Core Data else is, and how it works is largely unrelated to this
> limitation, anyway.
Perhaps you should have taken more than a first glance. For example, here:
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdBasics.html#//apple_ref/doc/uid/TP40001650
"Core Data is not a relational database or a relational database
management system (RDBMS)."
>> Whining about how it doesn't support massive
>> multi-user applications makes absolutely no sense.
>
> Now, I'm starting to wonder whether you had ever designed a database
> application (or framework). Then you should have noticed that this is a
> fundamental requirement. Maybe I'm biased, but I cannot think of any modern
> third party framework related to the database domain that does not support
> multi user.
Why would you think I had ever designed a database application or
framework? All I know is, CoreData is *not* a database framework, so
your whining about how it fails some fundamental requirement for
database frameworks makes no sense.
> Since it is very likely that an object graph management framework like Core
> Data is a part of a framework for database applications I think this is a
> valid question.
Sure, it's a valid question. And you received a valid answer (no).
>> You might as well
>> complain that Cocoa has no support for digital audio processing, or
>> that your Mac makes a poor platform for embedded computing.
>
> The opposite is true: I know Mac OS (or better iPhone OS) is a great
> example for an embedded application, and my Mac makes a great development
> platform for this kind of devices. ;)
I didn't say Mac OS, I said your Mac, as in the computer.
> Anyway, I think the OPs requirement is multi user, and in this case Core
> Data is not applicable. Which is too bad since it is great otherwise.
You're absolutely correct about this. I don't disagree at all. My only
objection is to your attitude that CoreData's intended design
limitation constitutes some kind of insurmountable failing for any
usage whatsoever.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden