Re: Best Strategy for Cacheing
Re: Best Strategy for Cacheing
- Subject: Re: Best Strategy for Cacheing
- From: David Avendasora <email@hidden>
- Date: Thu, 23 Oct 2008 11:33:41 -0400
Two reasons:
1) This is an expensive thing to run and I use it all over the place.
Running it once per session worked, but even that was a lot of
overhead, now using more ECs is only going to multiply the number of
times it's being generated.
2) It would be handy to have access to this "flattened" version of the
part/components hierarchy by reporting software like Crystal Reports.
I'm _assuming_ that having it stored as data in the DB instead of
having to generate it is going to be hugely faster and the tradeoff is
the complexity of keeping it fresh.
Am I wrong about the trade-off being worth the speed gain?
Dave
On Oct 23, 2008, at 10:33 AM, James Cicenia wrote:
If the data is read only why would you have to change your current
strategy?
Just wondering?
- James Cicenia
On Oct 23, 2008, at 5:21 AM, David Avendasora wrote:
Hi all,
I've got a recursive structure in my model:
Part <->> Routing <->> RoutingStep <->> RoutingComponent <<-> Part
Which could be simplified to:
Part <->> Part <->> Part <->> Part...
So basically, a given part is made up of multiple other parts,
which in turn can be made up of other parts, and so on, and so on.
In theory this nesting can be infinite but in practical terms it is
usually less than 5 levels deep.
The problem is that each part needs to know what all the possible
parts are that go into making it, how much of that component is
needed, which WorkCenter it is used in, on which ManufacturingLine,
etc - no matter how deeply nested they are. The trick is that there
can be different ways of making it on different manufacturing
lines, and other complicating factors. Simply traversing the object
graph and compiling the information each time I want it is a lot of
overhead.
Right now, I simply have an inner class on Part called "Component"
that has all this information and the first time I need the
information for a Part for a given session I generate all the
Components for that Part and then store them in a
NSArray<Part.Component> instance variable on the Part. I use this
information in lots of places. But now that I'm moving to using
multiple ECs instead of the default EC so I'm going to have to do
the work of compiling the list of Components for each EC instead of
once per session.
I think I've reached the point where having the data persisted in
the DB and actually part of the model and therefor managed by EOF
is going to be more efficient. I know I'll have data-freshness
issues with this strategy, but it will also make this data more
easily accessible from the outside of the WO system through things
like Crystal Reports.
I'm wondering what the best way to handle this will be. Am I going
down the wrong road in the first place?
Thanks,
Dave
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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