Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7C695F5A3 for ; Fri, 5 Jul 2013 14:33:45 +0000 (UTC) Received: (qmail 56397 invoked by uid 500); 5 Jul 2013 14:33:45 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 56231 invoked by uid 500); 5 Jul 2013 14:33:45 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 56181 invoked by uid 99); 5 Jul 2013 14:33:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jul 2013 14:33:41 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ekohlwey@gmail.com designates 209.85.219.53 as permitted sender) Received: from [209.85.219.53] (HELO mail-oa0-f53.google.com) (209.85.219.53) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Jul 2013 14:33:36 +0000 Received: by mail-oa0-f53.google.com with SMTP id k14so3497932oag.12 for ; Fri, 05 Jul 2013 07:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=D0L23xsXu40WhY/seUp1tIxII2SrwWrOi+GSbaQwHXQ=; b=cWuNs2llKSMbDokzUwkbp2Tt7mkdC3VlFRRHJsdzWUjvEaBzr4Bj6g0kAN3Ihbx230 8vzQO4p+AqzXSCF8XbVw9zgtXcVgAFumwPjc8a5udT+HUG6xNycF+851lISlSXUhpVcu /X9uZMFENaHuwU7EzV8it93xVEznHatTpeljbWpq5oY9+h25NKeDx8EjbY1Tyrid0Qp6 vozQNgIeVFDOgc2dDSdzZ/zRsyls+A5WWooSjAtbwYrx2Y6bgmktYtEX3pC+q7hXzpFN x5f1gdhVgIgK9c7ksDJByPJtc94plZb6tjJK1leQI7ylTmrh349vymMhLEUSZbsDBuBo KuvQ== MIME-Version: 1.0 X-Received: by 10.182.134.229 with SMTP id pn5mr11452665obb.9.1373034795410; Fri, 05 Jul 2013 07:33:15 -0700 (PDT) Received: by 10.76.169.70 with HTTP; Fri, 5 Jul 2013 07:33:15 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Jul 2013 10:33:15 -0400 Message-ID: Subject: Re: Generic Supertypes/Pluggable Client From: Ed Kohlwey To: dev@accumulo.apache.org Content-Type: multipart/alternative; boundary=001a11c2570e3eae9104e0c49300 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2570e3eae9104e0c49300 Content-Type: text/plain; charset=ISO-8859-1 > Just a knee-jerk reaction here, but allowing a user to provide Text, String > or byte[] is painful? > > I've always viewed it as String if I want to be lazy, and byte[] or Text > when I'm more concerned about performance and don't want to be making new > objects for every record I need insert into Accumulo. The problem isn't that people are allowed to provide different types, the problem is that the types are inconsistent. Value still has only one method to get data out, which is get() and returns a byte array. Key has the option of Text or ByteSequence, neither of which are easily compatible with CharSequence. CharSequence, Text, or byte[] are allowed as parameters to Range. Scanner.fetchColumn() is only for Text, unless you use the version that takes a Column but that is also very inelegant. Every single application I've worked on with Accumulo has a utility class with methods to help convert between these types, and then also the application's own data model. The application code is always unnecessarily inelegant and confusing to new people on the project. Explaining the necessity of the (frankly bizarre) type conversion scaffold always makes programmers who are new to the platform make a stinkface and ask why it is still written the way it is. --001a11c2570e3eae9104e0c49300--