drill-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Givre <cgi...@gmail.com>
Subject Re: [DISCUSS] Deprecation policy in Drill
Date Mon, 27 Aug 2018 11:38:48 GMT
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 <tongweijie178@gmail.com> 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 <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
View raw message