Re: EOModeler and more
Re: EOModeler and more
- Subject: Re: EOModeler and more
- From: Jim Pearson <email@hidden>
- Date: Mon, 12 Jan 2004 10:01:30 -0500 (GMT-05:00)
James,
With respect to the generated classes part of your question:
The approach that has worked best for me over the past few years is to keep the EO-generated Java classes "as is", with no changes in their code. That way I can change the model and regenerate classes as needed with few issues. If I need non-EOF logic to be based in my EOs I make subclasses and add them to my project. I then use the subclasses to place all my app-specific logic as overrides and overloads. This makes maintenance of the original EO Java classes much easier.
It also makes things quite a bit easier when adding application-specific logic to EOs where the EOs are used in different applications, but the logic is not used among the applications.
jimp
----------------------------
Jim Pearson
-----Original Message-----
From: james cicenia <email@hidden>
Sent: Jan 12, 2004 9:19 AM
To: Arturo Pirez <email@hidden>
Cc: email@hidden
Subject: Re: EOModeler and more
OK -
I will take the naive approach... make all my objects complete and use
EOF and its caching etc.
By the way, when I did create those Fetch Specifications.. where do
they go?
I ran the "java" and I don't see them anywhere? Maybe it was late for
me last
night or I missed it in the EOModeler documentation.
Now that I have thoroughly (I believe) modeled my database objects in
EOModeler, what approach does one do next? Do you subclass the generated
java so that you can run EOModeler again?
-James
On Jan 11, 2004, at 11:13 PM, Arturo Pirez wrote:
>
> On Jan 11, 2004, at 11:46 PM, james cicenia wrote:
>
>>
>> On Jan 11, 2004, at 10:14 PM, Arturo Pirez wrote:
>>
>>> In any case, thousands of users may be viewing a page that displays
>>> two dozen objects. If you fully
>>> utilize EOF object caching then you will hit the database once no
>>> matter how many times the page is
>>> displayed. Your implementation will hit the database every time the
>>> page is displayed. Which is
>>> more expensive?
>>
>> Is that because the "raw" fetch is not cached? Hmmm. Then there must
>> be a way so that my
>> smaller objects will be fetched and cached.
>
> See, now you starting to duplicate work that is already in EOF. Just
> do it the "naive" way
> and then come back to the list if there's actually a problem :-)
>
> BTW, no fetch spec result is cached. That will always go to the
> database. I'm not certain if
> the resultant objects are cached or not. So I try to write things
> such that I only go through
> relationships. Those are cached and offer amazing performance. But
> it's not always possible.
>
>>
>>>
>>> As an FYI, our portal was featured on the CBS morning show (whatever
>>> it's called). We didn't know
>>> and we didn't do the above level of optimization before it happened;
>>> i.e. we instantiated full
>>> objects for EVERYTHING. The portal continued to function just fine
>>> when the tens of thousands
>>> of CBS morning show watchers fired up their browsers.
>>
>> Well that sounds very reassuring to me on all levels. By the way what
>> was your environment?
>
> That environment had a few (2?) Solaris X86 boxes running only Apache
> and the WO adaptor, a
> (redundant) pair of Sun clones (2U?) running WO and the equivalent of
> a Sun 450 running Oracle.
> Cisco LocalDirector load balancing in front of the web servers. IIRC.
>
> ----
> WO in philadelphia - wanna cheesesteak with that?
> Please visit webobjects.meetup.com.
_______________________________________________
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.
_______________________________________________
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.