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

[Helge Hess]

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

regards,
  Helge
--
OpenGroupware.org
http://www.opengroupware.org/