[Top][All Lists]

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

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

From: Patrick Coskren
Subject: Re: GDL2/EOF scaling (was: Re: GNUstep roadmap)
Date: Tue, 28 Oct 2003 19:45:48 -0500

On Tuesday, October 28, 2003, at 06:25  PM, Helge Hess wrote:

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.

But in an RDBMS, many of the values are relations to other sets. In other words, you have a bunch of rows linked in some graph. I fail to see where rows vs. objects is a critical distinction, unless you're complaining about the fact that the list of values in an object is static rather than dynamic.

If that's what you're saying, then I can see the point, but in my experience having an object model for your data makes the overall application far more maintainable. In some cases I've had that object wrap the results of a Perl DBI call (let's say), but I've still had the object. I can see why people prefer a more dynamic approach.

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.

I don't understand what you mean. As for breaking relationships, why couldn't your second entity define the relationships it needs, same as the first entity? Yes, you have to redo some references, but the tools make it easy. As for identity, I don't see it being a problem as long as you never have more than one object in the same EOEditingContext for a particular table row. But, if I'm remembering correctly, that's a restriction even when you only have one entity for a given table.

And why would subclassing "break semantics"? Because you're more accurately talking about a subsetting operation than a subclassing one?

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 like. I personally do this manually (if I'm understanding you) even when I'm using raw database calls in a non-EOF context. I find it makes the code clearer.

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.

I'll give you this one. Subclassing might get around this, but I never used it much. In 5.0, the support was still a little shaky, and that was the last time I used EOF.

No. I mean usual amounts of rows for RDBMS (10000+ at least) with usual amounts of columns (I would say around 10+)

I think I'm following you: you're not worried about the size of the table per se, but the size of the result set. Yes?

and of course with a result set being joined (which is the hardest part for OO mapping).

It is? I always found that the easiest. purchaseOrder().customer().phoneNumber(). Joining 3 tables.

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

Okay, fair enough. It's clear that you have a lot more experience with EOF than I do. But I'm still trying to figure out why we have such different perceptions of EOF's scalability.

But again, I do *really* not expect to be able to convince you.

Well, you never know.

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 thinking about this, I think I begin to see where you're coming from. When I used EOF, it was in the context of WebObjects. In a web app, you'd rarely have a result set with 10,000 items, because you couldn't reasonably display that much data on a web page. A case where you might need to resort to raw rows is if you want your app to generate a report for the user to download, and you really would need to process a result set with that many items.

On the desktop, however, I can see where you would have 10,000 items in a result set easily. To use your mail example, an Inbox can easily have that many. While a web app would display that 20-50 at a time, a desktop app would dump them all at once. In that case, yeah, you'd want to use raw rows. I can see how EOF *on the desktop* wouldn't scale well.

Hmmm.... I think I begin to see why Apple rolled EOF into WebObjects and has been resistant to releasing it on its own. It's a decision I've decried in the past, but maybe they have a point.

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.

*Chuckle* I like Java. Works great for web applications. Although Python's been tickling my fancy of late, to be sure. *sigh*... really must take another look at Zope. The last time I looked, there was no good documentation out there.

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

Which is why it can be well automated. :-) Seriously, I like it when my tools take care of the easy stuff. That's a personal choice, of course.

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.

Even with non-EOF apps, I tend to constraint-check in both the app and the database. The app has the ability to give more immediate feedback to the user, and I don't need to go grunging through the database errors to find out what failed. But the database needs to have the constraints as the final line of defense.

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" ;-)

I meant inherently killer as in "killer, dude!" not killer as in "lo, he has killed." I don't think market success is a reasonable measure of the quality of a technology. If I did, I wouldn't be using a Mac, singing the praises of WebObjects, and hanging out on the GNUstep mailing list. I'd be using JDBC. :-P

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 ;-)

Well, I think it depends on context. I'll concede the point for desktop apps.


reply via email to

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