Elasticsearch: Deprecate Groovy, Python, and Javascript Languages
Let's move Groovy to a plugin. Expressions and Painless are both secure, performant, and have a simplicity that encourages the use of scripts that make sense in a search engine. Painless is now the default language and covers a large portion of the Groovy space, there is no reason to ship with Groovy as a module.
jdconrad
All 10 comments
+1
rmuir
on 23 Aug 2016
I disagree with the no reason. We don't know at this point how people use it and more importantly how people upgrade their scripts. I'd much prefer that folk can go to a version X that has both by default. My suggested plan is:
- deprecate groovy in 5.0 but ship as a module for easy upgrade
- announce on a blog with the deprecation notice (maybe we can even think of doing the move to a plugin in a minor?)
- remove it in 6.0 unless shit hits the fan
it will prevent the angry user that did all the work to upgrade and then realized that they where missing a plugin? I feel folks should be happily surprised that painless is there instead of having pain due to too fast moving. It really costs us nothing but a couple of bytes in the zip file. If I'd upgrade with scripts in an index or a file. I'd first get the upgrade done then work on my scripts to cut over to painless. Painless is such a beautiful addition I really don't want to move to fast to hide the joy it should bring to the user by angry issues from users that required the BWC.
s1monw
on 23 Aug 2016
I'm happy with @s1monw proposal here to deprecate Groovy first as long as we stick to the plan to ultimately remove it.
jdconrad
on 23 Aug 2016
It really costs us nothing but a couple of bytes in the zip file. If I'd upgrade with scripts in an index or a file.
Only risks such as CVE-2015-5377
rmuir
on 23 Aug 2016
Editing this issue to propose we deprecate Groovy, Javascript, and Python, and ultimately follow @s1monw proposed path to move them all to plugins and eventually out of Elasticsearch.
jdconrad
on 23 Aug 2016
++ @jdconrad
s1monw
on 23 Aug 2016
Yes! I was just about to type up an issue to deprecate/remove Python scripting. I don't think we need anymore discussion, so I am going to remove the discuss tag.
pickypg
on 30 Aug 2016
The two main issues got merged so I'm closing this.
jdconrad
on 2 Sep 2016
At Nimble inc. we use python scripting as currently Elasticsearch doesn't have "reverse child" aggregation. This is pretty huge module generating aggregations code and optimized to work fast. The need to rewrite it in Painless actually makes it painful.
serj-p
on 21 Mar 2017
Sorry @serj-p! Jython's total lack of security model means we can't support it. This is certainly a change from us, but it has been a long time coming.
Does your missing aggregation have an open issue? Maybe we should make it?
You certainly don't have to rewrite it in Painless. You could make a plugin with it. It'd likely be more efficient that way.
nik9000
on 22 Mar 2017
Related issues
clintongormley
路
3Comments
jpountz
路
3Comments
ppf2
路
3Comments
clintongormley
路
3Comments
ttaranov
路
3Comments
Most helpful comment
I disagree with the no reason. We don't know at this point how people use it and more importantly how people upgrade their scripts. I'd much prefer that folk can go to a version X that has both by default. My suggested plan is:
it will prevent the angry user that did all the work to upgrade and then realized that they where missing a plugin? I feel folks should be happily surprised that painless is there instead of having pain due to too fast moving. It really costs us nothing but a couple of bytes in the zip file. If I'd upgrade with scripts in an index or a file. I'd first get the upgrade done then work on my scripts to cut over to painless. Painless is such a beautiful addition I really don't want to move to fast to hide the joy it should bring to the user by angry issues from users that required the BWC.