Re: Using EO
Re: Using EO
- Subject: Re: Using EO
- From: Arturo Perez <email@hidden>
- Date: Wed, 25 May 2005 14:19:59 -0400
Just an anecdote to back this up.
I built an authentication system using WO. I used a lot of objects.
Very O-O if I do say so myself. When it was part of a portal (also
built with WO) everyone said it was too slow. Too many objects doing
too many fancy things. I moved it into a standalone app with a
webservicey kind of interface. Did _not_ change any of the underlying code.
Someone made a mistake. The app using it to authenticate accidentally
authenticated for every single page served. They didn't discover this
until the load test. The authentication system was authenticating 1800
requests/(sec? min? don't recall probably minutes).
No more talk of it being slow or rewriting it in J2EE (yech!).
Especially for WebApps, where the web itself is so slow, performance
isn't usually a problem. Now, scalability...
-arturo
Chuck Hill wrote:
I'll follow up on Jerry's reply with a focus on Jon's comment, "I guess
my only question is which way has the best performance. " This is a
common concern for new comers to WO and IMHO a common mistake. Heed
Jerry's advice: get your objects well designed and working and only
then and only if you see a real problem, start to optimize. I recall
someone else who wandered in here with the same concerns. Again and
again I said "don't worry about optimization". Finally, he relented,
but there was a lot of fretting. :-) After he finally deployed, he
came back with the comment "It's so fast that my user's won't believe
that it is a real, deployed web app and not a local demo."
Chuck
On May 25, 2005, at 6:27 AM, Jerry W. Walker wrote:
Though I don't disagree with specific point made in this thread, I
hate the direction that it has taken.
If this is your first WO project, then there are a few reasons to do
this without using raw SQL. Probably the first, and foremost, is to
get used to doing things with objects rather than with tables. My
first concern is the statement of the original question:
"is there a way to build a FetchSpecification that would accomplish
the sql equivalent of "SELECT SUM(COLUMN_NAME) FROM TABLE_NAME"
This question is clearly framed from the perspective of "I have a
table of rows with which I want to do something, now how do I get WO
to help me do that thing to my table in the same way I've always done
these things with SQL?"
Experienced WO developers would think instead of the object graph
that we are manipulating in our object oriented java application
rather than the rows we have stored in our relational database.
Rephrasing the question, "I have a set of objects 'O' with an
attribute 'a'. How do I obtain the sum of that attribute across those
objects?"
The obvious first answer is Sacha's first answer:
"My preferred method is to use the NSArray @sum key value coding
(note: no need to do an enumeration). "
Perhaps those objects have already been cached and we don't need to
fetch raw rows. Perhaps the sum could be obtained as a side effect of
another necessary operation on those objects later when they have
already been fetched.
Failing either of those two possibilities, I would still first write
the fetch without referencing raw rows and get it to work. Finally,
if the result is clearly taking too long, I would profile where the
delays are occurring and, if in database fetches, then would start to
consider raw rows. The point being that referencing raw rows is a
last resort rather than a way to move into the comfort zone of old
habits with result sets.
So what are the down sides to just moving immediately to raw rows?
* a missed opportunitiy to get used to the WO way
* the short circuiting of several elegant features built into WO to
help one deal with objects rather than rows
* the higher probability of weak object oriented design built up
from this raw row decision
I'm sure others could add more with a little more thought, but I have
to catch a train.
Good luck with WebObjects and welcome to the fold.
Best regards,
Jerry
On May 25, 2005, at 3:37 AM, Sacha Mallais wrote:
On May 25, 2005, at 12:15 am, Jonathan Miller wrote:
Hmm... I guess my only question is which way has the best
performance. To answer my own question I would assume it to by
passing raw SQL. This is my first web site with WO and I was
hoping I could avoid doing that however(it's just too cool not to
have to use SQL).
My preferred method is to use the NSArray @sum key value coding
(note: no need to do an enumeration). However, if you have many
many values to aggregate, then you're best bet is indeed raw SQL.
sacha
On May 24, 2005, at 5:19 PM, Sacha Mallais wrote:
On May 24, 2005, at 8:00 pm, Jonathan Miller wrote:
is there a way to build a FetchSpecification that would
accomplish the sql equivalent of "SELECT SUM(COLUMN_NAME) FROM
TABLE_NAME"
I know you can select the objects and then add them using a java
enumeration but I was wondering if there is another way.
The most obvious is to construct the SQL yourself and send it
directly using the low-level EOF stuff (or even the JDBC
stuff...). I mention it because, as WO developers, we sometimes
forget that there's SQL back there ;-)
A more interesting (if not hackish...) way to accomplish this
would be to create a new entity with the same table name and a
single derived attribute of "sum(column_name)". You can then
either generate a full Java class for that or just use raw rows.
Also, the PracticalWO frameworks (and the GVC frameworks -- also
to be released soon, and, come to think about it, probably the
ProjectWOnder frameworks too...) have a helper method that makes
aggregate queries more simple.
HTH,
sacha
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden