drill-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From weijie tong <tongweijie...@gmail.com>
Subject Re: [DISCUSS] Deprecation policy in Drill
Date Mon, 27 Aug 2018 11:01:56 GMT
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 <arina@apache.org> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message