Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Console: Escaping results in differently stored documents #13528

Open
spinscale opened this issue Aug 16, 2017 · 7 comments
Open

Console: Escaping results in differently stored documents #13528

spinscale opened this issue Aug 16, 2017 · 7 comments
Labels
bug Fixes for quality problems that affect the customer experience Feature:Console Dev Tools Console Feature Feature:Dev Tools Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more

Comments

@spinscale
Copy link
Contributor

Escaping using the three ticks syntax in combination with backslashes can result in differently stored documents (maybe this is documented and I didnt find it, but I think it's worth mentioning somewhere). Take this example

PUT foo/bar/1
{
  "message" : """
*\\!DMAlock*_
"""
}

PUT foo/bar/2
{
  "message" : "*\\!DMAlock*_"
}

GET foo/bar/_mget
{"ids":["1","2"]}

# response
{
  "docs": [
    {
      "_index": "foo",
      "_type": "bar",
      "_id": "1",
      "_version": 3,
      "found": true,
      "_source": {
        "message": """*\\!DMAlock*_"""
      }
    },
    {
      "_index": "foo",
      "_type": "bar",
      "_id": "2",
      "_version": 1,
      "found": true,
      "_source": {
        "message": "*\\!DMAlock*_"
      }
    }
  ]
}

As you can see, the response looks fine. However returning the documents via curl reveal, that the source is actually different

curl -u elastic:changeme localhost:9200/foo/bar/_mget?pretty -d '{"ids":["1","2"]}'
{
  "docs" : [
    {
      "_index" : "foo",
      "_type" : "bar",
      "_id" : "1",
      "_version" : 3,
      "found" : true,
      "_source" : {
        "message" : "*\\\\!DMAlock*_"
      }
    },
    {
      "_index" : "foo",
      "_type" : "bar",
      "_id" : "2",
      "_version" : 1,
      "found" : true,
      "_source" : {
        "message" : "*\\!DMAlock*_"
      }
    }
  ]
}

As you can see the number of backslashes is different, two versus four.

@gmoskovicz gmoskovicz added Feature:Dev Tools bug Fixes for quality problems that affect the customer experience labels Aug 16, 2017
@gmoskovicz
Copy link
Contributor

I think that this is a DevTools issue.

@tylersmalley tylersmalley added the Feature:Console Dev Tools Console Feature label Aug 16, 2017
@cjcenizal cjcenizal added Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more and removed :Management DO NOT USE labels Jun 14, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/es-ui

@jloleysens
Copy link
Contributor

@spinscale AFAIK this is the intended behaviour of using """ strings. They remove a level of escape sequences which enables, for instance, rendering text with actual new lines instead of \n.

Closing for now.

@cjcenizal
Copy link
Contributor

@jloleysens I'm not quite following -- can you explain why using triple quotes will store \\\\ instead of \\?

@jloleysens
Copy link
Contributor

Given the following two strings:

Without triple quotes:

"This is a string with a newline\nthat is valid JSON"

With triple quotes:

"""This a string with a newline
that is valid JSON"""

When converted to JSON, they will both be: "This is a string with a newline\nthat is valid JSON". This because of how escaped chars are encoded when converted, and as I understand it the intended behaviour. Let me know if there is something I am missing though!

@cjcenizal
Copy link
Contributor

Based on the issue @spinscale reported, it seems like the problem we need to solve is the confusion he experienced, as opposed to something misbehaving on a technical level. Maybe the solution could lie on the technical level (e.g. by changing the way we encode stuff in triple quotes), or maybe it's simply documenting the expected behavior as he suggests. Either way, I think this is still a valid problem we can solve.

@cjcenizal cjcenizal reopened this May 4, 2021
@alexwizp alexwizp assigned mibragimov and unassigned mibragimov Feb 7, 2022
@alisonelizabeth alisonelizabeth removed the Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more label Sep 17, 2024
@botelastic botelastic bot added the needs-team Issues missing a team label label Sep 17, 2024
@alisonelizabeth alisonelizabeth added the Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more label Sep 17, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-management (Team:Kibana Management)

@botelastic botelastic bot removed the needs-team Issues missing a team label label Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes for quality problems that affect the customer experience Feature:Console Dev Tools Console Feature Feature:Dev Tools Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more
Projects
None yet
Development

No branches or pull requests

8 participants