discuss-gnustep
[Top][All Lists]
Advanced

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

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


From: David Ayers
Subject: GDL2/EOF scaling (was: Re: GNUstep roadmap)
Date: Tue, 28 Oct 2003 19:33:55 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

Manuel Guesdon wrote:

Hi Helge,

On Thu, 23 Oct 2003 02:40:21 +0200 Helge Hess <address@hidden> 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






reply via email to

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