Re: Jolt specification registry

2019-11-21 Thread Otto Fowler
I think the idea would be to provide API support for the schema registry where you could work with it as just versioned blobs, and then the level of support on top of that ( to the ui etc ) would be dependent on the implementation, with AVRO being the first concrete implementation. You could

Re: Jolt specification registry

2019-11-20 Thread Pierre Villard
A while back, I suggested (there is a JIRA for it) something similar for Grok patterns (being able to have a global CS managing the grok patterns instead of relying on local files to be distributed on the NiFi nodes). Not the same but wanted to mention it in case it would drive towards something

Re: Jolt specification registry

2019-11-20 Thread Mark Payne
Well, not really. The Avro Schema Registry does perform validation of the Avro Schema. Which is something that a 'generic blob store' type of mechanism would not really provide. I think I recant my recommendation of making it more generic. There are definitely benefits to it being more

Re: Jolt specification registry

2019-11-20 Thread Mark Payne
Fair enough. I forgot that we had the advanced UI for the Jolt Spec. That would definitely be beneficial. On Nov 20, 2019, at 10:47 AM, Joe Witt mailto:joe.w...@gmail.com>> wrote: ...specific or generic - tradeoffs. A specific service would allow Jolt Spec editing to have context and

Re: Jolt specification registry

2019-11-20 Thread Etienne Jouvin
Does it means that AvroSchemaRegistry is "not a good idea actually" ? I am pretty sure I misunderstood, because in this case there is a kind of compilation on schema. But you are right, the registry for JOLT specification is just a storage of blob. Le mer. 20 nov. 2019 à 16:36, Mark Payne a

Re: Jolt specification registry

2019-11-20 Thread Joe Witt
...specific or generic - tradeoffs. A specific service would allow Jolt Spec editing to have context and meaning. A generic service for just blobs would not. I think our Jolt stuff has an advanced UI that makes writing the specs a bit easier. If true a more specific service would make sense.

Re: Jolt specification registry

2019-11-20 Thread Mark Payne
I would recommend that we also be careful about the naming here and tying this to Jolt. Really, this is just a mechanism for externalizing a big blob of text (or bytes). There are several other processors and controller services that do this, such as scripted components, Hadoop related

Re: Jolt specification registry

2019-11-20 Thread Etienne Jouvin
For the PR... If only I would have enough time for that ;) Soon it will be end year holidays, may be... Le mer. 20 nov. 2019 à 16:28, Joe Witt a écrit : > Yeah filing a JIRA would be good. Contributing a PR for it would be even > better. It should have no impact on the schema registry

Re: Jolt specification registry

2019-11-20 Thread Etienne Jouvin
Yes it would be a ControllerService as you described. There is currently three implementation : * AvroSchemaRegistry * ConfluentSchemaRegistry * HortonworksSchemaRegistry It could be based on something like them. May be I should send something on Jira or somewhere else to submit the idea to

Re: Jolt specification registry

2019-11-20 Thread Joe Witt
Hello Is the idea to have a place to store Jolt specifications that you could then access in various components? If so a simple ControllerService such as 'JoltSpecControllerService' which has a list of keys (names of specs) and values (the spec) would probably do the trick. Thanks On Wed, Nov

Re: Jolt specification registry

2019-11-20 Thread Otto Fowler
I think that is a great idea, I’d suggest the same thing for protobuf specs as well. Even if the first step is the registry supporting raw bytes access and support…. On November 20, 2019 at 09:28:23, Etienne Jouvin (lapinoujou...@gmail.com) wrote: Hello all. For reader and writers, there