"First was that cache models are not namespace aware. Should they be?"
Probably, but, if we change this we will break code for folks who are referencing cache models across sqlmaps files. "Second was that cache models are processed even if cacheModelsEnabled is false. If they are disabled, we could skip them and save some startup time and memory." I would think it should not process. But, you would want to check the other areas where the statement has a cachemodel specified and make sure that when the configs are processed it also knows to use a GenericStatement/ProcedureStatement rather than a CachingStatement. "The next one was that the BaseParser's applyNamespace(id) method does not apply the namespace if the id passed in has a "." in it. So if you name a statement "my.foo" and put it in a sql map named "bar", it will not end up being named "bar.my.foo", but instead will silently be left as "my.foo"." I can't think of a reason why we wouldn't want to do this. These nodes are processed once. There should be no multi processing. Besides, if there was you could always check for a startsWith(namespace+"."). That's my .02, Brandon On 4/21/05, Larry Meadors <[EMAIL PROTECTED]> wrote: > I was looking at the configuration code this morning and saw some things > that made me scratch my head. > > First was that cache models are not namespace aware. Should they be? The > resultMap and parameterMap elements are, so it seems that for consistency, > cacheModels should be as well. That would be convenient, because you could > name all your cache models "cache" if you wanted, and not have to worry > about naming collisions. > > Second was that cache models are processed even if cacheModelsEnabled is > false. If they are disabled, we could skip them and save some startup time > and memory. > > The next one was that the BaseParser's applyNamespace(id) method does not > apply the namespace if the id passed in has a "." in it. So if you name a > statement "my.foo" and put it in a sql map named "bar", it will not end up > being named "bar.my.foo", but instead will silently be left as "my.foo". > > I am trying to think of a way (other than a user naming an object with a > ".") that this would happen, and can't. Maybe if it was called twice for the > same node? > > So my question on this one is: Should the config parsers be modified to gag > on a user-supplied id containing a "." if namespaces are enabled or should > this check be removed from the applyNamespace method? > > Right now, I am leaning more toward the first option: If namespaces are > enabled, the "." character is reserved in namespace aware components - if an > id has a "." in it, an exception is thrown from the SqlMapParser. > > Thoughts? Opinions? > > Larry > >
