Thought I'd supply a few answers to some of these questions. (See below.) On Mar 30, 2011, at 3:45 PM, Michael_google gmail_Gersten wrote:
>>>> No one has ever been able to give me a convincing answer as to why EOF was >>>> ditched in favor of CoreData. I can understand EOF, it feels >>>> object-oriented and ObjC-like. CoreData is a like a plate of spaghetti to >>>> my mind, very C++ like, syntaxy, and hard to get your head around ... >>> >>> How about this for a good reason: EOF was huge and in need of a major >>> overall. >>> >>> EOEditingContext was three different classes lumped into one big mess. >> >> Heh, that's how I see CoreData: one big mess. EOF did have one major >> redeeming quality: I could understand it! :) I've given up on CoreData for >> now. Maybe someday I'll revisit it... > > I only took a quick look at Core Data, and it didn't seem that hard to > understand -- about 75% of EO with much less confusion. What did I > miss that was confusing? > > EOEditingContext ... > I think you're confusing EOEditingContext with EOControl. > Well, lets see. At the bottom was EOAccess, which was in two parts. > One stock, and one was "roll your own" database specific. There was no > real sample code to base your work on, other than flat file -- no > actual sample SQL database example. I'm assuming that's changed now. > The whole "No basic DB adaptor included for any free DB other than > flat files" thing kinda stank as well. > > Then, you had a portion of EOEditingContext designed to get stuff out > of EOAccess. > > Then, a portion of EOEditingContext designed to edit. > > Then, a portion of EOEditingContext designed to provide data to the display. > > Then, * Two different display classes, with different interfaces, with > no unifying access protocol *. > > It wasn't always clear what the details of routine X actually did -- > the documentation was horribly lacking in places, and "determine by > experimentation" is a really bad way to go. I started with WO in 1997, but I'm having trouble remembering the state of documentation back then. By the time WO 5 came out, the javadocs were pretty complete, as I recall. > The whole object's primary key generation seemed to only be half > documented. The whole "you need to know what class this row is > expected to turn into ahead of time" was a problem. While "Encode the > class in the primary key" was the quoted answer, there was no sample > "How to" to make it work. And despite everything that was done, > duplicate default primary keys could still be generated -- they were > not unique enough. I never had a problem just using a sequence as the primary key generation method. For very high transaction volumes, generating keys within the application should have some advantages. > There were hooks to allow you to save a session state, but how to use > them wasn't really well explained. At the time, A magazine (I think it > was Byte) had a challenge to the three big database systems (Apple's > Wo/EOF was one of them) to implement a fictional "nile.com" -- an > amazon-like book seller. One of the test cases was pulling the power > plug on one of the three servers, to see if there was automatic > failover -- and Apple did not. WebObjects has a pretty decent deployment system built-in, but if you prefer you can deploy using a J2EE container using any J2EE-compliant server. > And, I don't know if the "raw rows memory leak" was ever fixed -- > every time you fetched an object, the raw database row was brought > into memory, and never discarded. > > I'm assuming a database adaptor code base now exists, and now that I > know of project wonder, I'm assuming that there's "specify class in > the primary key" stuff in there. Heck, I'm assuming that there's a > good "store/fetch list/array/other ordered collection into database" > method by now. The move to Java simplified this, as all the connections are now JDBC-based. > Last time I used EOF was 2001; how has it improved in 10 years? > _______________________________________________ > MacOSX-talk mailing list > MacOSX-talk@omnigroup.com > http://www.omnigroup.com/mailman/listinfo/macosx-talk
_______________________________________________ MacOSX-talk mailing list MacOSX-talk@omnigroup.com http://www.omnigroup.com/mailman/listinfo/macosx-talk
