[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.
-Patrick
- Environment? (was: Re: GNUstep roadmap), (continued)
- Environment? (was: Re: GNUstep roadmap), Stefan Urbanek, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/22
- Re[2]: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Manuel Guesdon, 2003/10/23
- Re: Re[2]: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/23
- GDL2/EOF scaling (was: Re: GNUstep roadmap), David Ayers, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Helge Hess, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Patrick Coskren, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Helge Hess, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Patrick Coskren, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Helge Hess, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap),
Patrick Coskren <=
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Helge Hess, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Marco Scheurer, 2003/10/29
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Patrick Coskren, 2003/10/29
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Dennis Leeuw, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Richard Frith-Macdonald, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philippe C . D . Robert, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/22