Hi Ashish, I think your approach is generally right. It's bit annoying while type of paragraph.result varies.
I think 'angularObject' field is another field that you also need to take care. object inside 'angularObject' might also vary their types. Another approach would be serialize part of / entire json structure and store it as 'string' or 'binary' in elasticsearch, if search is not necessary. Thanks, moon On Tue, Jun 14, 2016 at 8:09 AM ashish rawat <dceash...@gmail.com> wrote: > I could think of another hack. While saving, when paragraphs.result type > is string, move that to another field paragraphs.stringResult before saving > to elastic. And do the reverse when serving reading notes. > > This might just work and looks relatively clean, but can there be more > such cases in Zeppelin note. > > In general, is it a good strategy to save note.json to elastic search? > > Regards, > Ashish > > On Tue, Jun 14, 2016 at 7:53 PM, ashish rawat <dceash...@gmail.com> wrote: > >> Hi All, >> >> I was trying to write an implementation of storage interface for elastic >> search, so that notebooks can be highly available in a cluster. The >> implementation of basic interface looked simple but I got stuck while >> importing note.json data into elastic search. Unfortunately, the type of >> paragraphs.result varies. In my sample notebook, for one paragraph, it was >> an object containing fields "code", "type" and "msg", while in another >> paragraph, it was a string >> "org.apache.zeppelin.interpreter.InterpreterException: >> org.apache.thrift.transport.TTransportException: java.net.ConnectException: >> Connection refused". >> This is not acceptable in elastic search, since the type of a field >> should be same for an index. There might be some complex alternative, where >> once can split notebook into multiple indices, based on the type of >> paragraphs.result, but that is more of a hack. >> >> Can someone please suggest a simple and clean alternative for this. I am >> also curious about the reason for keeping different types for the same >> variable in Zeppelin. >> >> Regards, >> Ashish >> > >
