Also now we that we support Hadoop conf, we don't require below API. we can remove them from CarbonWriterBuilder.
*setAccessKeysetAccessKeysetSecretKeysetSecretKeysetEndPointsetEndPoint* Thanks, AB On Thu, Sep 20, 2018 at 11:16 PM Ajantha Bhat <ajanthab...@gmail.com> wrote: > > @xuchuanyin: > > yes, method signatures will be like you specified. > > @kanaka: I still think we should keep only table properties Map as we > validate "wrong_spells and names". More options will create more confusion. > So, just keeping table properties Map can simplify configurations. End > user can form a map and pass. Just like existing withLoadOptions map > > Any other suggestions are welcome > > Thanks, > AB > . > > On Thu, Sep 20, 2018 at 10:55 PM kanaka <kanakakumaravv...@gmail.com> > wrote: > >> +1 for the proposal to clear SDK APIs. >> Thanks Ajantha for initiating the code changes. >> >> For schema input for writer creation, I also feel we should unify to all >> writer creation methods to Builder. API looks cleaner if we provide just >> build() without out any more arguments. >> >> >> "withTableProperties(Map<String, String> options) vs >> sortBy(..),withBlockSize(...),etc" >> ----- I think both of these methods can serve for different purposes. >> withTableProperties(Map<String, String> options) can be used by customer >> apps which takes property input directly by end users who is familiar with >> carbon create table syntax. >> Individual methods can be used by customers app code to avoid problems >> like >> wrong spells or wrong names. >> >> "public CarbonWriterBuilder isTransactionalTable(boolean >> isTransactionalTable)" >> -- I think we can remove if we are not clear on the usecase at this moment >> and to avoid confusions >> >> >> >> >> >> >> -- >> Sent from: >> http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/ >> >
