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 >
