On May 17, 2009, at 8:42 AM, Andreas Grosam wrote:
On May 16, 2009, at 5:09 PM, Michael Ash wrote:
On Sat, May 16, 2009 at 8:48 AM, Andreas Grosam <agro...@onlinehome.de
> 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.
Exactly as it was designed to be. Core Data was not designed to be a
client/server database access layer. It was specifically designed to
solve the problem of complex object graph management within an
application, including persistency.
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html
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.
Actually, the Core Data Basics makes it abundantly clear that there
are no client/server features within Core Data.
http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdBasics.html#/
/apple_ref/doc/uid/TP40001650-TP1
Never is the word "server", "connection", "network", or "client"
mentioned in that document (outside of the sentence "nor is there an
expectation of client-server behavior").
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.
I have designed a handful of database applications and database access
frameworks over the years.
Client/server access is absolutely not a requirement unless your goal
is to support multiple users with a centralized (or distributed, for
that matter) server.
Since Core Data is quite explicitly designed to solve the problem of
complex object graph management and persistency within Cocoa
applications, more specifically in Document based Cocoa applications,
there was no requirement for client/server support when Core Data was
designed.
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.
Valid question, sure. And you have your answer; CD intentionally
doesn't solve that particular problem.
Some day Core Data might. Client/server database access layers are
incredibly difficult to create. Doubly so if the goal is
generalized, multi-user, database connectivity. Triply so if there
is a need to support multiple vendor's databases and have any kind of
support for schemas not owned by the object-relational mapping layer.
If there proves to be a need for such functionality that is a high
enough priority that it outweighs the rather high cost of development,
Core Data could grow said functionality.
And that is where you come in; if you have a need for this feature,
file a bug (http://bugreport.apple.com) that describes your particular
business case for said feature. It will be returned as a duplicate as
this particular feature request was logged when Core Data 1.0 was in
development. However, logging real world need for this is critical
to properly setting priorities -- your duplicate is valuable ("me to"
is not useful -- if you don't have a business case for it, don't file
the bug).
b.bum_______________________________________________
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
