@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/ >
