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

[Helge Hess]

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.

Sure.

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,
  Helge
--
OpenGroupware.org
http://www.opengroupware.org/