Things take a while usually because messaging is done on a period; most
of the elapsed time is just waiting on the period to pass. See in
src/test where we have an hbase-site.xml with different config. from
hbase defaults. Most of the config. here are tunings to make stuff run
faster in the u
Jean-Daniel Cryans wrote:
> Przemek,
>
> Just delete all rows in your tables. Unless you create thousands of rows, it
> should be faster.
>
> J-D
imho tests should not depend on any "prepared" or "assumed" state (all
should be created in setUp and closed in tearDown - ideally of course),
so setU
Przemek,
Just delete all rows in your tables. Unless you create thousands of rows, it
should be faster.
J-D
On Sat, Nov 15, 2008 at 5:27 AM, Przemek <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to ask about a potential workaround/pattern. Let's say you
> have a schema with 10 tables and wa
Hi,
I would like to ask about a potential workaround/pattern. Let's say you
have a schema with 10 tables and want to have unit tests with embedded
HBase (similar way as in HBase tests). The way we do that is having
@Before that starts the cluster and then something like init method for
creating ta
