Re: EOModeler
Re: EOModeler
- Subject: Re: EOModeler
- From: james cicenia <email@hidden>
- Date: Sun, 11 Jan 2004 22:54:16 -0600
On Jan 11, 2004, at 10:27 PM, Arturo Pirez wrote:
On Jan 11, 2004, at 10:24 PM, james cicenia wrote:
Arturo,
I do understand what you are suggesting. But wouldn't it just be
quicker
and easier to use the database for this? In other words, my graph
object
would just issues a simple, for example:
Select count(department) from project_request
where status=open group by department.
And then just turn this simple result into a list which would be part
of my graph object?
-James
I seem incapable of crafting a response that won't seem condescending
or
that won't irritate you further. So just let me leave it at.
Sure. You can do that. The database IS good at that sort of thing.
But it's
the wrong approach.
LOL - You are such the purist! Hey, and don't worry I am certainly not
irritated, just trying to understand all of this as well as possible
and part
of that is to try to separate database work vs. programmatic work. And,
your strong opinion about the full object instantiation is having its
intended
affect on my thinking, especially knowing that you had a big hit on your
portal application. That alone has forced to re-think all my assumptions
about memory, database vs. programmatic calculations, etc.
On Jan 11, 2004, at 9:11 PM, Arturo Pirez wrote:
On Jan 11, 2004, at 9:55 PM, james cicenia wrote:
What collection of your objects would benefit by being grouped?
The groupings would be for graphing. For instance the count of all
open project requests
by department.
That's a reporting use of WO. Not my forte. When faced with that
sort of thing I would do
the following.
Assumption: There are Department objects and Project objects.
There is a relationship
between them so one can say department.allProjects() that is a
one-to-many (one department
can have many projects). Project objects have a status field with
values: open, closed, cancelled.
So, I would write a fetch spec on Department that looks something
like
department->allProjects->status == open
and I would have a list of departments with open projects. At this
point there are two strategies.
One is to write in the WOComponent an EOQualifier.filteredArray...
to get the open projects for
each department. Alternatively you could add to the Department.java
a method called openProjects()
that does the filtering. Either way you'll end up with an NSArray
of projects with status == open
(call it openProjectsNSArray).
In that case you bind to a WOString
openProjectsNSArray.@count
Notice above that the fetch spec is on Department not Project. This
is because you're paginating
your report by Department. Otherwise you'd have to find all open
projects and then "slice" the
resulting array into departmental subsets which feels more
cumbersome to me.
Does that all make sense to you?
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.
--arturo
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.