[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: Wed, 29 Oct 2003 00:25:23 +0100

On 28.10.2003, at 23:32, Patrick Coskren wrote:
It is an absolutely usual situation that you display some few attributes of a large table and has nothing to do with batch processing (which is working on the whole set of the data).
I was responding to the "50,000 person and 150,000 address" bit. That's a whole set of data, and I stand by my statement.

Whether we are talking about 10000 or 50000 or 150000 records doesn't change the issue that OO is about objects (self contained objects which are linked in some graph) and RDBMS is about sets of values.

If you're just talking about having a table with 50 columns where you only want to display name, city, and street, then yes, that's a completely normal situation, which EOF handles with aplomb: just create another entity.

Only that this completely breaks identity and the relationships. Now you can also to some degree do subclassing in EOF, but this would even break semantics.

Besides that, since something like a tableview is usually freely configurable from the available attribute set you would need to recreate a dynamic entity all the time. Hack.

If you want to call that a hack, fine: I call it a technique. Just create another entity from the handy menu, point it at the table, select "name, city, street", boom. Done. Scales great.

This does not only break interobject relationships, it also breaks internal encapsulation of the objects. That is, you cannot really reuse/write methods anymore.

EOF will do that just fine: you just have more than one entity mapped to your table, one for each context you use it in (listing mail vs. reading mail).

See above.

I never claimed that. I'm talking about regular database applications and database applications imply that you are dealing with large tables (and in the usual case not display just one or two of them at the same time ...).
I think there's a terminology issue here. I thought that by "large tables" you mean tables with lots of data in them. I'm beginning to think that's not the case and you mean tables with lots of columns in them. Is that right?

No. I mean usual amounts of rows for RDBMS (10000+ at least) with usual amounts of columns (I would say around 10+) and of course with a result set being joined (which is the hardest part for OO mapping).

No, it isn't. It almost sounds like you have the idea that Entity = Table.

No. I use GDL (and EOF before) for about 6 or 7 years and I added a whole lot of EOF 2 additions to our GDL, even wrote an EOObjectStore that works on Palm databases. I *do* know how EOF works and I very well know the internals and the various hacks to workaround issues (batch faulting is my favorite absolute nonsense EOF "hack").
But again, I do *really* not expect to be able to convince you.

That's just not true, and that's by design: there's nothing hackish about it. You can have more than one entity per table, or more than one table per entity. EOF handles the mapping under the hood.

Of course ...

Sure, there are times when, for performance reasons, you want to load raw rows.

Hm, I wonder in which cases you would resort to that if EOF can deal quite fine with the issues I raised. Where is the performance barrier in your opinion? When did you need to resort to raw rows?

In that case, you're right that EOF isn't really doing anything you couldn't do with JDBC. But my point is that such cases are much less common than you're making them out to be.

JDBC (I *really* do not want to take that as an example as it has inherently bad taste because of the Java origin, lets take Perl DBI for example or Zope SQLMethods), does exactly what an RDBMS was build for, selecting, joining, sorting.

And this is just because you want to do a "select a,b,c from d,e where d.pkey=e.foreignkey".
Which is what EOF is doing for you under the hood.

I can perfectly express that myself. SQL is really easy.

It's always a good idea to run your app once with SQL logging turned on to look for easy points of optimization.

If this is the case I can write SQL in the first place instead of hoping that EOF does the right thing. A typical EOF weirdness in that respect is constraints processing which you basically need to redo in your model to get it right.

Hmmm, I think you misunderstand me. EOF lower levels are roughly as productive as JDBC, IMHO. But the higher levels rock, and everything you've mentioned so far can be easily done at the higher levels.

Well, and they can be easily done at the adaptor level. EOF doesn't buy me anything in that context since result rows *are not objects* but arbitary sets of values.

And this is the core of our disagreement: I think EOF is fantastic, downright killer, for the majority of applications.

It is proven by history that EOF is not killer at all. Its available for a very long time now and never took off, neither for desktop applications on OpenStep, nor for WO ObjC applications nor now in the Java form.
Or we also have a different definition of "killer" ;-)

But it seems our differing opinions stem from an architecture that I think is elegant and you think is hackish, and that's probably at root an aesthetic thing.

No this is very wrong. I love the architecture and implementation of EOF. Its the best thing I know for what it does (OR mapping). But unfortunately this isn't something which is really useful in practice ;-)


reply via email to

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