Re: Embedded database server or CoreData?
Re: Embedded database server or CoreData?
- Subject: Re: Embedded database server or CoreData?
- From: Marcel Weiher <email@hidden>
- Date: Sat, 13 Jan 2007 23:48:14 -0800
On Jan 11, 2007, at 21:11 , Bill Bumgarner wrote:
On Jan 11, 2007, at 8:56 PM, Marcel Weiher wrote:
Funny that. I keep hearing that this "object graph management" is
interesting and useful, but somehow I've never wanted an object-
graph management system, and can't come up with any reasons for
wanting one apart from when I am *forced* to deal with external
databases.
Apart from that specific case, my object graphs have always managed
themselves just dandy, and persistence is a quick'n'easy process.
So I keep wondering: why is this useful?
Automatic Undo / redo. Relationship management. Automatic
validation. Transaction management (that editing context thing).
To name a few.
My non-database apps have never had or needed an editing context or
transaction management and what goes for the object-graph goes just as
much for the object relationships: they manage themselves very nicely
once I've defined my object-model (and I am not restricted to sets,
natch!).
"Automatic" validation doesn't seem possible to me unless there is ESP
involved, or how else is the system going to figure out what values
are valid? That leaves automatic undo/redo, which sounds kinda nice
except that I also have a hard time believing it can actually be done
both fully automatically (what is a logical op?) and efficiently/
appropriately except in very trivial situations.
So what I see is, at best, a couple of minor nice-to-haves, but tied
into a big system with lots of complexities, restrictions and
overheads. I still don't see why I would want/need "object graph
management" except in the context of an OR mapping. My object graphs
just "are", they don't need management.
Personally, I don't like re-writing any of that code
I'll see your "no re-write", with which I totally agree, with a "re-
factor when and if necessary" and raise you a "YAGNI". :-))
(nor have I built up piles of solutions to these problems that I can
move forward across new projects)
Is this a contracting issue? In that you can't refactor recurring
solutions into common code because of contract restrictions?
and, as such, I use CoreData to manage the model layer of all of my
apps, typically using an in-memory store and often using various
completely standalone models in isolated Core Data stacks.
Wow!
And, of course, there is actually a tremendous amount of subtlety in
all of the above. Having trained Cocoa / OpenStep / NeXTSTEP
classes over the years, dealing with model related issues was one of
the most difficult areas for new developers to grasp, architect and
debug.
Interesting. With the systems I architected and/or developed and the
people I mentored, this tended not to be the case, but then again I
was using and teaching plain old objects, not complex object-
relational models.
Cheers,
Marcel
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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