Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of asaf.mesika@gmail.com
 designates 74.125.82.169 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: Composing your own timestamp
From: Asaf Mesika <asaf.mesika@gmail.com>
In-Reply-To: 
 <CAKTawbLHEKncqW5usbOxAtJtid3W_MkLe4-tpyYJ-5y2vHRKqA@mail.gmail.com>
Date: Mon, 9 Jul 2012 20:08:09 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F9B9B49-A4EB-4B11-98C3-CC1E5948F220@gmail.com>
References: <ABB2F6E5-2B94-4A9C-B18A-F54DFA1400FB@gmail.com>
 <CAKTawbLHEKncqW5usbOxAtJtid3W_MkLe4-tpyYJ-5y2vHRKqA@mail.gmail.com>
To: user@hbase.apache.org

No.
My index is composed of several fields. Some goes to the RowKey, some to =
the column name, and some  - and hence the question - to timestamp.
Those that goes to the timestamp are of types Integer, Short and short =
which together form 8 bytes  - the size of the Timestamp in hbase.

So my question was if that's ok? I mean, it seems that the normal usage =
for the timestamp is to have a timestamp (ms since epoch) and to have =
values there which always increasing - meaning: you'll never see value 7 =
enters *before* value 3, for example.

On Jul 9, 2012, at 18:54 PM, Sonal Goyal wrote:

> Sorry I did not understand your question. Are you planning to use the
> concatenated long as the rowkey to your secondary table?
>=20
> Best Regards,
> Sonal
> Crux: Reporting for HBase <https://github.com/sonalgoyal/crux>
> Nube Technologies <http://www.nubetech.co>
>=20
> <http://in.linkedin.com/in/sonalgoyal>
>=20
>=20
>=20
>=20
>=20
> On Mon, Jul 9, 2012 at 6:49 PM, Asaf Mesika <asaf.mesika@gmail.com> =
wrote:
>=20
>> Hi,
>>=20
>> We've been tinkering around ideas of implementing secondary index.
>> One of the ideas is based on concatenating three meaningful fields =
into a
>> long: int, short (2 bytes), short. This long will be used as =
timestamp when
>> issuing a put to the secondary index table.
>> This means an puts, timestamp wise, will not occur chronologically. =
since
>> this is not a real timestamp.
>>=20
>> Will this create any issues?
>>=20
>>=20
>> Thanks!
>>=20
>> Asaf
>>=20
>>=20