Best Strategy for Cacheing
Best Strategy for Cacheing
- Subject: Best Strategy for Cacheing
- From: David Avendasora <email@hidden>
- Date: Thu, 23 Oct 2008 06:21:08 -0400
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