FWIW, since we seem to have a habit of leaving deprecated items hang around in Drill for some time, I would be in favor of having Drill throw warnings in the next version for use of deprecated items (not just options) and then removing them in version n+2. — C
> On Aug 27, 2018, at 07:01, weijie tong <[email protected]> wrote: > > I think we should reserve these deprecated options to let users upgrade > easier. Another solution is if we remove these deprecated ones, we should > add a startup checking to let users know these options are removed . > > On Mon, Aug 27, 2018 at 3:54 PM Arina Ielchiieva <[email protected]> wrote: > >> Hi all, >> >> when it should be considered OK to remove deprecated options / tables in >> Drill? >> Some projects mark some notion as deprecated in one release, and then >> remove in the next. >> Will this policy be ok in Drill? >> >> Here are two latest examples: >> >> 1. store.hive.optimize_scan_with_native_readers was introduced for parquet >> tables, when native readers support was added for other table type, we had >> to come up with better option naming to distinguish between table >> types: store.hive.parquet.optimize_scan_with_native_reader and >> store.hive.maprdb_json.optimize_scan_with_native_reader. >> store.hive.optimize_scan_with_native_readers was deprecated in 1.14 and is >> planned to be removed in 1.15. >> >> 2. We plan to swap sys.options and sys.options_val tables, then depracte >> sys.options_val table in 1.15 and completely remove it in 1.16. >> >> Any thoughts? >> >> Kind regards, >> Arina >>
