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

[Patrick Coskren]

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