[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDL2/EOF scaling (was: Re: GNUstep roadmap)

From: Helge Hess
Subject: Re: GDL2/EOF scaling (was: Re: GNUstep roadmap)
Date: Tue, 28 Oct 2003 20:30:36 +0100

On 28.10.2003, at 19:33, David Ayers wrote:
I wasn't sure whether I should reply to this, but since people on #GNUstep now started to ask me why EOF doesn't scale


let me give you some from an EOF based app I maintain :
# of EOModels: 8
# of EOEntities in a large model: 165
# of rows in large tables: multiple millions (at some installations)

Yes. I think I made my point not clear enough, of course you can write scalable applications using EOF - after all you can go down to the adaptor level if you wish. (there are of course other pretty big EOF projects (eg HDT which Nat! works on), and also at least 10 times as many projects as big and bigger based on "regular" access technology)

The issue is that to accomplish that you must go down a *lot* in the abstraction, so you basically loose a *lot* if not all of the advantages of EOF. And I more or less claim (though this is also very much depends on whether you are a EOF hardcore expert or not!) that for applications which deals with "usual" RDBMS datasets (which are *always* 10000+ rows, otherwise the use of an RDBMS in front is clearly overkill), EOF is way more trouble than gain.

Like with any tool set, you need to chose the correct tools for a specific task. EOF gives a wide range of tools. If you select the correct one for the task at hand, it scales rather well.

I wouldn't in general disagree. Strip down EOF to adaptor level and add some stuff which makes things easier (like an adaptor-datasource ;-) and you'll have a pretty performant toolset - I really do not disagree. But on the other side you do not have any "killer" advantages anymore, its still pretty good and certainly better than most of the raw DB APIs of other environments. The reasons why EOF is hyped are mostly (not completely!) the high level features which are based on the idea to map enterprise objects to database rows and this just doesn't scale. If you have 50.000 person entries with 150.000 address entries you just cannot afford to load all that as objects into memory just because you want to display "name", "city" and "street". Objects have a deep and inherent mismatch with the set approach taken by RDBMS. And yes, I know about all the hacks to workaround the issue like artificially creating subset entities etc, this is
a) only available to experts which know the hacks
b) those are hacks which you wouldn't need if you would access RDBMS as intended

Agreed, in a complex integrated framework like EOF it is a bit more tedious than the theory sounds, but with language features like poseAs: nearly the most internal techniques can be adapted to fit your needs. And when we get that far in GDL2 then we can attempt to find a superior solution.

Well, as mentioned before I *really* do not want to educate someone about EOF! ;-) If it does the task for you - fine. I just found out of me that EOF just doesn't provide me anything I need but in contrary does a lot of things I certainly do not need.

Now I'm sure that there are DB-tools sets that have better implicit scaling, and I know that people/companies have developed EOF extensions that add some asyncronous API that may belong in GDL2/EOF. Maybe we will see some of those in a GDL2 Additions library someday.

I definitely do not think that in the object-relation mapping area a lot of products exist which are as good as EOF! (well, I'm no expert on other products either ;-) You can basically extend my scalability issue to most other OR tools as well.

So yes, you can develop non-scalable applications with GDL2/EOF, but yes, you can make highly scalable applications with GDL2/EOF also.


Please lets stop the discussion right here, so while I am open for further arguments, I do not really think that it takes us anywhere.

best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]