I noticed that every array element, and Solr document field is prepended with a numeric key which is a sequential element index. So, these i:0 might be pretty valid.
On Mon, Dec 4, 2023 at 4:04 PM Mikhail Khludnev <m...@apache.org> wrote: > It looks like https://github.com/apache/solr/pull/2114 > I see 'i:0' in actual output. I'm not sure whether it's wrong or right. > > On Mon, Dec 4, 2023 at 3:23 PM Thomas Corthals <tho...@klascement.net> > wrote: > >> Hello Mikhail >> >> I wrote the Luke functionality for the Solarium PHP client. There is no >> use >> case here, just the desire to fully support the functionality. >> >> If we can agree this is a bug in the PHPS output (JSON output doesn't >> contain errors) I'll open a JIRA issue for it and implement a forward >> compatible workaround in the client. >> >> Thomas >> >> Op ma 4 dec 2023 om 10:15 schreef Mikhail Khludnev <m...@apache.org>: >> >> > Hello Thomas. >> > It's not really my wheelhouse. There might be a problem in LukeHandler >> or >> > its' compatibility with phps. e.g. under "solr" key it puts Lucene's >> > Document but not SolrDocument really (see >> > LukeRequestHandler.handleRequestBody). >> > Do you really need /luke can't you obtain a doc via /select or /get? >> > >> > On Sun, Dec 3, 2023 at 11:49 AM Thomas Corthals <tho...@klascement.net> >> > wrote: >> > >> > > Hi all, >> > > >> > > >> > > The output of a Luke request for a specific document with wt=phps >> can't >> > be >> > > unserialized in PHP because it contains an error. >> > > >> > > >> > > > curl ' >> > > http://localhost:8983/solr/techproducts/admin/luke?id=apple&wt=phps' >> > > >> > > >> > > The output is structured like this, I'm omitting some details for >> > brevity. >> > > >> > > >> > > >> > > >> > >> a:4:{s:14:"responseHeader";a:2:{s:6:"status";i:0;s:5:"QTime";i:1;}s:5:"index";a:0:{}s:3:"doc";a:3:{s:5:"docId";i:7;s:6:"lucene";a:3:{s:2:"id";a:0:{}s:10:"compName_s";a:0:{}s:9:"address_s";a:0:{}}s:4:"solr";i:0;a:3:{s:2:"id";s:5:"apple";s:10:"compName_s";s:5:"Apple";s:9:"address_s";s:28:"1 >> > > Infinite Way, Cupertino >> > > CA";}}s:4:"info";a:2:{s:3:"key";a:0:{}s:4:"NOTE";s:116:"Document >> > Frequency >> > > (df) is not updated when a document is marked for deletion. df values >> > > include deleted documents.";}} >> > > >> > > >> > > The Solr document in this output should be an array item with key >> "solr" >> > > and an array of fields as value. It's represented by this bit: >> > > >> > > >> > > >> > > >> > >> s:4:"solr";i:0;a:3:{s:2:"id";s:5:"apple";s:10:"compName_s";s:5:"Apple";s:9:"address_s";s:28:"1 >> > > Infinite Way, Cupertino CA";} >> > > >> > > >> > > The i:0; part doesn't belong there. It makes PHP think the value of >> key >> > > "solr" is integer 0 and then it bails because it doesn't expect an >> array >> > > a:3: to follow next. I suspect writeSolrDocument() in the >> > > PHPSerializedResponseWriter is to blame. It starts with writeKey(idx, >> > > false); assuming it's always writing a document to an array? >> > > >> > > >> > > Thomas >> > > >> > >> > >> > -- >> > Sincerely yours >> > Mikhail Khludnev >> > >> > > > -- > Sincerely yours > Mikhail Khludnev > -- Sincerely yours Mikhail Khludnev
