Possible namespace issues?

[Larry Meadors <la...@gmail.com>]

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

Re: Possible namespace issues?

[Larry Meadors <la...@gmail.com>]

I am going to put this into JIRA later today as an enhancement request so we 
do not lose it.

On 4/21/05, Brandon Goodin <br...@gmail.com> wrote:
> 
> >"Second was that cache models are processed even if cacheModelsEnabled is 
> false. 


> 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.


Good idea, I will look into that, and verify the behavior - that is how it 
should work.

"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.
> 

> 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+".").


I like that better than the existing check. It may be slower, but the 
behavior seems to be more what I would expect.

Larry

Re: Possible namespace issues?

[Brandon Goodin <br...@gmail.com>]

"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 <la...@gmail.com> 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
>  
>

Re: Possible namespace issues?

[Larry Meadors <la...@gmail.com>]

On 4/21/05, Larry Meadors <la...@gmail.com> 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.



I was apparently on crack that morning. After looking more at this, I found 
that cache models are indeed namespace aware, it was just that the code was 
not where I was expecting it. Please disregard that comment. :-)