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

[Patrick Coskren]

On Tuesday, October 28, 2003, at 02:30  PM, Helge Hess wrote:

> 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.

If you've got an app that's loading all those entries at once, then 
it's a batch app.  And EOF isn't designed for batch processing.  You're 
right as far as that goes.  But in any end-user app, you're only 
loading a subset of the rows (and probably a small subset at that) into 
memory.  So the object paradigm of EOF works very well.

> 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

One man's hacks are another man's techniques, I guess.  It's not like 
these things aren't documented.  Setting display attributes, 
pre-fetching, auto-faulting (it's been a while, so I might be getting 
the terminology a bit wrong) are all features of the framework that are 
supported by the tools, and work as they were designed to.  It's really 
not very complicated in practice: I was able to dramatically increase 
the performance of one web app just by making a couple of tweaks to 
checkboxes in EOModeler.

> 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.

Personally, I found EOF no harder to learn than JDBC, and I was a hell 
of a lot more productive with it.  YMMV, I suppose.

-Patrick