On Dec 31, 2008, at 8:31 AM, Adrian Crum wrote:
--- On Tue, 12/30/08, David E Jones <david.jo...@hotwaxmedia.com>
wrote:
If you're really worried about it you could do
something to load all existing simple-method, screen, etc
files and see what the actual size of the cache is. This is
really easy to do since if you run the Artifact Info stuff
(just go to the main page) it will load everything.
That's a great idea! I'll give it a try.
My concern is with simple methods using IDs as identifiers. Let's
say an accounting method creates a Map of invoices that need some
kind of reconciling done on them. Each invoice ID is a Map key. A
high volume user might have 10,000 invoices, so 10,000 expressions
are generated and kept in the cache. Then in another simple method,
orders are analyzed for backordered items and the same approach is
used. There are 10,000 orders so another 10,000 expressions are
created and cached. There is no limit to how many places and how
many times this happens. I foresee a serious problem.
Well, that would be a problem. Previously the expression evaluation
cached the interpreted code based only on the straight text from the
file, so no IDs unless they were hard-coded.
Are you saying that in the UEL implementation it does one (inner)
expansion and then parses the result, and caches that? In other words,
there is no support for nested expressions?
Ouch. I don't think we can get around that as a limitation... either
we'll have to somehow get nested expressions working, or just stop
using nested expressions now that we have alternatives in UEL and we
really don't need them any more. My vote would be for the second
option, BTW... much cleaner and may actually be easier.
-David
