[
https://issues.apache.org/jira/browse/SOLR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671739#action_12671739
]
Jared Flatow commented on SOLR-993:
-----------------------------------
bq. In that case if I add a Map to a namespace, you won't be able to iterate
over the keys and find out ones which have a '.' character. How do we handle
those cases?
Are there any cases of dynamic maps right now that don't look like function
calls? In my mind, any dynamic variables should look like "a.b.c.d(...)", where
"a.b.c" is the namespace in which you can find the variable/function "d(...)".
I think this is consistent with the way these are added to namespaces right
now? The only problem is if you want to have the function called "d.e(...)" in
the namespace "a.b.c", which I don't think should be supported. Is it
unreasonable to say you can't use '.' characters in naming those functions? If
you really want to call "a.b.c.d.e(...)", then have your dynamic namespace be
"a.b.c.d" with a function "e(...)".
WRT iterating over the maps: to be clear, I would prefer the implementation be
changed to how the patch is now: if you add "b.c" to "a", then thats how you
have to retrieve it; therefore you should add "c" to "a.b" if you want "a.b.c"
to be resolvable. Perhaps if you have a specific map which you know will have
'.' separated names (like request), there should be a flag in the add* methods
for whether to check or not.
Nonetheless I understand that I might be the only one that cares about these
things and that these changes are not backwards compatible. Still, the API
explicitly mentions that it is unstable so perhaps changing it slightly is not
a big deal. I think this will make some steps towards solidifying the API. The
other thing the patch does towards this goal is to make consistent use of what
the null and empty string "" namespace refer to (the patch follows the
convention that null is the top-level namespace, and empty string is treated
the same as any other string).
bq. I think this is a good change to make. However, we need to be careful with
this. With the current way of resolving variables, one may get a lot of false
alarms.
How so?
> VariableResolverImpl addNamespace overwrites entire namespace instead of
> adding
> -------------------------------------------------------------------------------
>
> Key: SOLR-993
> URL: https://issues.apache.org/jira/browse/SOLR-993
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
> Affects Versions: 1.4
> Reporter: Jared Flatow
> Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-993.patch, SOLR-993b.patch
>
> Original Estimate: 0.08h
> Remaining Estimate: 0.08h
>
> The addNamespace method in VariableResolverImpl does not so much add the
> namespace as overwrite it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
