Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ABCBC10BE3 for ; Tue, 27 May 2014 23:58:34 +0000 (UTC) Received: (qmail 1503 invoked by uid 500); 27 May 2014 23:58:34 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 1452 invoked by uid 500); 27 May 2014 23:58:34 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 1444 invoked by uid 99); 27 May 2014 23:58:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 May 2014 23:58:34 +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 (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.219.42] (HELO mail-oa0-f42.google.com) (209.85.219.42) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 May 2014 23:58:30 +0000 Received: by mail-oa0-f42.google.com with SMTP id j17so10461754oag.29 for ; Tue, 27 May 2014 16:58:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=a/JxaMRjrlc/EPlTUyQRO9npqePUwsqN8mEMcfo6dqE=; b=jQwolPdpgA6RRGjKC1z0y0nh75hI3FNaxKaLLhPBwjbJq+ZoldlSy4Yvc7VvLonWkb jHWua4pipBvhthOBIypiN/b9D5H5KYszq1w2YjnImfbWCOGFVVG11sBA8tVjnEih+wyP 2uEcZWnwbAP/j0h8nO3dV88j+bwWF3NUfb0tNnwoy2DVGx2d7i3ShkIpqFFTwA8ZFABD xVcT+9jAeT4lk1eMYxSU5Zl717WmykMNGZMZKJyFOpQmvYUFnAHlaPE+xZ/wKVcHy6Pu Lx9+VDwUQlLNcbKtoyURss1so8aFASN1gzacTwD7p478+fWG3EnagsDQtZWqfbTltrze MsRQ== X-Gm-Message-State: ALoCoQk/9bdAqpR2B7wX0TKEzZ0zP9zDqDyRr4nQYxpWVdpxkXWYDHR3daYrvDjiJljl7oHqWjFO MIME-Version: 1.0 X-Received: by 10.60.134.175 with SMTP id pl15mr7796942oeb.81.1401235086044; Tue, 27 May 2014 16:58:06 -0700 (PDT) Received: by 10.182.229.6 with HTTP; Tue, 27 May 2014 16:58:05 -0700 (PDT) X-Originating-IP: [173.73.117.65] In-Reply-To: References: <53850BEF.2040705@gmail.com> Date: Tue, 27 May 2014 19:58:05 -0400 Message-ID: Subject: Re: Updating Metadata of a Table From: Chris Bennight To: user@accumulo.apache.org Content-Type: multipart/alternative; boundary=047d7b41ce128d03b204fa6a7731 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b41ce128d03b204fa6a7731 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I can confirm that the metadata (at least what is handled by the geotools DataStore.updateSchema method) is completely different that the !METADATA table. Your question is really going to entirely defined by the software you are using to provide the accumulo based DataStore implementation - most authoritative answer is going to be to ping / ask on their list / file a ticket Moving to a new version of geotools may not help if the underlying code doesn't implement the updateSchema method -- (if it does, you can just look and see what it does & mimic that). Depending on the persistence model the updateSchema method might require more than just editing the type definition - you might have to mutate existing entries as well. Since people are accessing the data as is my suggestion would be to write some code to copy the data from the old feature type to the new one (the one you want to update to), vet everything works, then move over to the new feature type. (basically the copy-on-write version of what updateSchema would do) On Tue, May 27, 2014 at 6:08 PM, Tiffany Reid wrote: > Josh, > > I believe you are correct. I'm looking through another 3rd party code > that extends GeoTools AbstractDataStore class for use with Accumulo. > > Tiffany > > > > -----Original Message----- > From: Josh Elser [mailto:josh.elser@gmail.com] > Sent: Tuesday, May 27, 2014 6:05 PM > To: user@accumulo.apache.org > Subject: Re: Updating Metadata of a Table > > What exactly is the metadata that you want to update? It sounds like this > might be a part of what is provided by this GeoTools product. Not sure. > > There aren't any built-in metadata attributes in 1.4. The data in the > !METADATA table is used to track which servers are hosting what parts of > each table, the files in HDFS that make up each table, etc. Maybe GeoTool= s > is tracking their own metadata in a custom table? > > On 5/27/14, 5:58 PM, Tiffany Reid wrote: > > I=E2=80=99ve created a couple of tables via a third party API, GeoTools= that I > > cannot delete and re-create because other projects are now using the > > data from those tables. Unfortunately, in the version of GeoTools > > that we are using for our project =E2=80=9CupdateSchema=E2=80=9D is cur= rently not > available. > > I wanted to handle this update of the metadata myself since the schema > > is written as the part of the Metadata for the table. > > > > I am still fairly green to Accumulo and have no idea the structure of > > the Metadata, how it is represented for each table. > > > > ** > > > > *Thanks,* > > > > *Tiffany* > > > > *From:*Mike Drob [mailto:madrob@cloudera.com] > > *Sent:* Tuesday, May 27, 2014 5:53 PM > > *To:* user@accumulo.apache.org > > *Subject:* Re: Updating Metadata of a Table > > > > I'm not sure I understand what you are trying to do. Can you give us > > an example and a use case? > > > > The metadata table is just like any other table where you can do > > inserts/deletes/etc. > > > > On Tue, May 27, 2014 at 4:49 PM, Tiffany Reid > > wrote: > > > > Or even via the Java API? I haven=E2=80=99t found any examples to upd= ate the > > MetaData for a specific table, only read the current entries. > > > > *From:*Tiffany Reid > > *Sent:* Tuesday, May 27, 2014 5:39 PM > > *To:* user@accumulo.apache.org > > *Subject:* Updating Metadata of a Table > > > > Hi, > > > > Does anyone know how to go about updating the metadata for a table in > > Accumulo via shell command tool? I=E2=80=99m using 1.4 and I cannot up= grade > > to the latest due to project requirements. > > > > Thanks, > > > > Tiffany > > > --047d7b41ce128d03b204fa6a7731 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I can confirm that the metadata (at least what is handled = by the geotools DataStore.updateSchema method) is completely different that= the !METADATA table.

Your question is really going to e= ntirely defined by the software you are using to provide the accumulo based= DataStore implementation - most authoritative answer is going to be to pin= g / ask on their list / file a ticket

Moving to a new version of geotools may not help if the= underlying code doesn't implement the updateSchema method =C2=A0-- =C2= =A0(if it does, you can just look and see what it does & mimic that). = =C2=A0=C2=A0

Depending on the persistence model the updateSchema met= hod might require more than just editing the type definition - you might ha= ve to mutate existing entries as well. =C2=A0=C2=A0

Since people are accessing the data as is my suggestion would be to write= some code to copy the data from the old feature type to the new one (the o= ne you want to update to), vet everything works, then move over to the new = feature type. =C2=A0 (basically the copy-on-write version of what updateSch= ema would do)


On Tue,= May 27, 2014 at 6:08 PM, Tiffany Reid <treid@eoir.com> wrote:<= br>
Josh,

I believe you are correct. =C2=A0I'm looking through another 3rd party = code that extends =C2=A0GeoTools AbstractDataStore class for use with Accum= ulo.

Tiffany



-----Original Message-----
From: Josh Elser [mailto:josh.elser= @gmail.com]
Sent: Tuesday, May 27, 2014 6:05 PM
To: user@accumulo.apache.org
Subject: Re: Updating Metadata of a Table

What exactly is the metadata that you want to update? It sounds like this m= ight be a part of what is provided by this GeoTools product. Not sure.

There aren't any built-in metadata attributes in 1.4. The data in the != METADATA table is used to track which servers are hosting what parts of eac= h table, the files in HDFS that make up each table, etc. Maybe GeoTools is = tracking their own metadata in a custom table?

On 5/27/14, 5:58 PM, Tiffany Reid wrote:
> I=E2=80=99ve created a couple of tables via a third party API, GeoTool= s that I
> cannot delete and re-create because other projects are now using the > data from those tables. =C2=A0Unfortunately, in the version of GeoTool= s
> that we are using for our project =E2=80=9CupdateSchema=E2=80=9D is cu= rrently not available.
> I wanted to handle this update of the metadata myself since the schema=
> is written as the part of the Metadata for the table.
>
> I am still fairly green to Accumulo and have no idea the structure of<= br> > the Metadata, how it is represented for each table.
>
> **
>
> *Thanks,*
>
> *Tiffany*
>
> *From:*Mike Drob [mailto:
madrob= @cloudera.com]
> *Sent:* Tuesday, May 27, 2014 5:53 PM
> *To:* user@accumulo.apache= .org
> *Subject:* Re: Updating Metadata of a Table
>
> I'm not sure I understand what you are trying to do. Can you give = us
> an example and a use case?
>
> The metadata table is just like any other table where you can do
> inserts/deletes/etc.
>
> On Tue, May 27, 2014 at 4:49 PM, Tiffany Reid <treid@eoir.com
> <mailto:treid@eoir.com>>= ; wrote:
>
> Or even via the Java API? =C2=A0 I haven=E2=80=99t found any examples = to update the
> MetaData for a specific table, only read the current entries.
>
> *From:*Tiffany Reid
> *Sent:* Tuesday, May 27, 2014 5:39 PM
> *To:* user@accumulo.apache= .org <mailto:user@accumu= lo.apache.org>
> *Subject:* Updating Metadata of a Table
>
> Hi,
>
> Does anyone know how to go about updating the metadata for a table in<= br> > Accumulo via shell command tool? =C2=A0I=E2=80=99m using 1.4 and I can= not upgrade
> to the latest due to project requirements.
>
> Thanks,
>
> Tiffany
>

--047d7b41ce128d03b204fa6a7731--