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

[David Ayers]

Manuel Guesdon wrote:

> Hi Helge,
>
> On Thu, 23 Oct 2003 02:40:21 +0200 Helge Hess <helge.hess@opengroupware.org> 
> wrote:
> >| GDL (or EOF) is impressive for demonstrations purposes. You can rapidly 
> >| constructs very nice apps since you don't have to think about the 
> >| storage. But as soon as you have actual data in the database, the whole 
> >| idea behind EOF collapses and you start working "around" EOF to get the 
> >| work done. EOF just doesn't scale and for the simplistic problems it 
> >| solves, you are better of using simple OO database - like ZODB.
>
> What do you mean by it "doesn't scale" ? Is is that problems came with 
> records counts, tables count or database complexity ? Do you have example 
> some examples ?
>  

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)

But yes I agree, if you develop applications with the simplistic 
approach suggested by some of the EOF demo's (like always relying on PID 
techniques and having a table view syncronously populated by a fetch on 
tables with > 10.000 rows, and having to fire mutliple to-1 faults for 
each object to get the descriptions of the corresponding objects, i.e. 
using flattened attributes to avoid redundancy in such tables) then, 
yes, that design / programming technique doesn't scale.  That would be 
like basing a word processor document on manipulationg a single 
NSMutableAttributedString.  For apps like Ink this works rather well to 
rather large file sizes.  But you would hardly write a book with it.

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.  Foundation, 
AppKit, EOF all do not supply a complete tool set for any app.  They 
provide templates to build upon.  I'm sure large applications never used 
NSTableView 'as is' for all cases.  It was subclassed and customized and 
optimized.  That's what OO is all about.

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.

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.

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

Cheers,
David