SOLR-15546: ShortestPathStream to handle ids with colons.

[cpoerschke]

https://issues.apache.org/jira/browse/SOLR-15546

[madrob]

What happens if there are quotes in the id?

[KennyKnecht]

Good remark

[cpoerschke]

What happens if there are quotes in the id?

Good question! I'd briefly wondered about the backwards compatibility aspects w.r.t. adding surrounding quotes in the code when the caller already added them as a workaround, and then I had lost track of that.

One difference between the code adding surrounding quotes vs. the caller adding them is that the code also adds them for interim nodes. I've amended the test coverage to explore that further.

Also adjusted the code change to not add surrounding quotes if there are some already but obviously quotes could also be in the middle of the id, say Alice ("Ally") or Robert ("Bob") both of which also contain parentheses as it happens, hmm.

[madrob]

I didn’t even consider the “quoted” case, I was thinking of text with a quote character in the middle. But I’m glad that we are thinking about that one too!

[cpoerschke]

... text with a quote character in the middle. ...

I would speculate that somehow encoding the id might be one approach? The text could contain quotes in the middle or apostrophe or colon or space or other stuff too.

[cpoerschke]

Hmm, have tried but not yet found a way to support quotes in the middle.

And if there is a space in the text then the code adding surrounding quotes changes the results, so with that behaviour change in mind perhaps any fix would be for 9x only and then no need to consider the scenario of the caller having added surrounding quotes since backwards compatibility is not retained anyhow?

Either way, I've amended the test coverage to include space and single and double quotes.

[madrob]

perhaps any fix would be for 9x only and then no need to consider the scenario of the caller having added surrounding quotes since backwards compatibility is not retained anyhow

I think we still want to back port a fix for colons at least to 8x? Maybe there are parts that stay 9x only, but I think this is probably something important to have in our release line

[cpoerschke]

perhaps any fix would be for 9x only and then no need to consider the scenario of the caller having added surrounding quotes since backwards compatibility is not retained anyhow

I think we still want to back port a fix for colons at least to 8x? Maybe there are parts that stay 9x only, but I think this is probably something important to have in our release line

One way for a backwards compatible or "backwards compatible friendly" change for the 8x release line could be via an optional flag:

shortestPath(
  collection,
  from="john@company.com",
  to="jane@company.com",
  ...
)

or

shortestPath(
  collection,
  from="john@company.com",
  to="jane@company.com",
  ...
  solr15546fix=true
)

for fixed behaviour with the option of

shortestPath(
  collection,
  from="john@company.com",
  to="jane@company.com",
  ...
  solr15546fix=false
)

for backwards compatible behaviour. So solr15546fix as an opt-out, solr15546fix would have to be some other name of course, and depending on name and whether or not it would be in 9.x also it could also be opt-in rather than opt-out though for this type of fix opt-out seems best.

[github-actions]

This PR had no visible activity in the past 60 days, labeling it as stale. Any new activity will remove the stale label. To attract more reviewers, please tag someone or notify the dev@solr.apache.org mailing list. Thank you for your contribution!