You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jonathan Ellis <jb...@gmail.com> on 2011/09/01 05:58:36 UTC
Re: CQL Drivers
On Wed, Aug 31, 2011 at 4:24 PM, Eric Evans <ee...@acunu.com> wrote:
> CASSANDRA-2936 is in progress (patches attached), but is there any
> reason not to get started with the Python driver now?
Heads up that test/system/test_cql.py depends on the Python driver.
It should probably be moved to the Python driver's test suite. (Which
then needs the same kind of "start a Cassandra server" ability that
the Cassandra system tests have.)
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: CQL Drivers
Posted by Jonathan Ellis <jb...@gmail.com>.
On Sun, Sep 4, 2011 at 10:12 AM, Eric Evans <ee...@acunu.com> wrote:
>> I'm rather fond of how user-friendly the Python suite is (taking care
>> of server setup/teardown transparently) but realistically, now that we
>> have robust truncate, it's probably fine to require an existing server
>> and just use that.
>
> I like it too, but it pretty much requires that you have a complete
> Cassandra tree around (you need config, scripts, and both run and
> build deps), and obviously it needs to have been built.
>
> This is how the JDBC driver was setup when it was moved out of tree
> and at least a couple of people (yourself included I believe), found
> it to be less-than-friendly. If it looks like I'm trying to steer the
> discussion away from this option, that's why.
Well, IMO there's a qualitative difference between "you need to have
the source tree around and edit a file to point the JDBC build to it"
and "you need to have the server listening on 9160, a packaged release
is fine."
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: CQL Drivers
Posted by Eric Evans <ee...@acunu.com>.
On Sat, Sep 3, 2011 at 10:21 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Sat, Sep 3, 2011 at 9:36 PM, Rick Shaw <wf...@gmail.com> wrote:
>> For what it is worth, my preference would be to have unit tests that would form a regression testing package in the tree with the client sources.
>
> Ditto.
>
>> I think that makes me favor option #3.
>
> I'm rather fond of how user-friendly the Python suite is (taking care
> of server setup/teardown transparently) but realistically, now that we
> have robust truncate, it's probably fine to require an existing server
> and just use that.
I like it too, but it pretty much requires that you have a complete
Cassandra tree around (you need config, scripts, and both run and
build deps), and obviously it needs to have been built.
This is how the JDBC driver was setup when it was moved out of tree
and at least a couple of people (yourself included I believe), found
it to be less-than-friendly. If it looks like I'm trying to steer the
discussion away from this option, that's why.
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
Posted by Jonathan Ellis <jb...@gmail.com>.
On Sat, Sep 3, 2011 at 9:36 PM, Rick Shaw <wf...@gmail.com> wrote:
> For what it is worth, my preference would be to have unit tests that would form a regression testing package in the tree with the client sources.
Ditto.
> I think that makes me favor option #3.
I'm rather fond of how user-friendly the Python suite is (taking care
of server setup/teardown transparently) but realistically, now that we
have robust truncate, it's probably fine to require an existing server
and just use that.
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: CQL Drivers
Posted by Rick Shaw <wf...@gmail.com>.
For what it is worth, my preference would be to have unit tests that would form a regression testing package in the tree with the client sources. Ideally the build package (whether dedicated or mixed in with the server) would have specific tasks to build, test and install/deploy devoted to the individual client in question.
I suggest that the client should not need to rely on anything but JAR files and local configuration to do the build and test. If they needed to be coordinated with a server build then perhaps some utility tasks to copy current jars for the server build site to the client build site would be useful. Config files local to the client build/test would point to test C* configs as appropriate. I think that makes me favor option #3.
On Sep 2, 2011, at 4:52 PM, Eric Evans wrote:
> On Thu, Sep 1, 2011 at 9:08 AM, Eric Evans <ee...@acunu.com> wrote:
>> On Wed, Aug 31, 2011 at 10:58 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>>> On Wed, Aug 31, 2011 at 4:24 PM, Eric Evans <ee...@acunu.com> wrote:
>>>> CASSANDRA-2936 is in progress (patches attached), but is there any
>>>> reason not to get started with the Python driver now?
>>>
>>> Heads up that test/system/test_cql.py depends on the Python driver.
>>> It should probably be moved to the Python driver's test suite. (Which
>>> then needs the same kind of "start a Cassandra server" ability that
>>> the Cassandra system tests have.)
>>
>> I posed a similar question about the JDBC driver in CASSANDRA-2936.
>>
>> Should these tests be considered functional tests of Cassandra, and
>> left be left where they are? I know that was my intention WRT
>> test_cql.py (the driver itself has a few tests of its own that do not
>> require a server).
>>
>> I guess I don't have a strong opinion either way, though it seems
>> easier to say that Cassandra's tests will require you to have a driver
>> installed, versus having to configure the build/test of a driver to
>> point to a Cassandra tree.
>
> No opinions on this? To summarize, the options as I see them are:
>
> 1. Keep the tests that query Cassandra, as-is, with the drivers they use.
> 2. Leave the tests that query Cassandra with Cassandra, (i.e. consider
> them Cassandra tests).
> 3. Keep the tests that query Cassandra, but alter them to be
> idempotent and to connect to an existent node, instead of spinning
> up/down an instance in test setup/teardown.
>
> (1) requires that you have some way of pointing the build at a local
> copy of a Cassandra tree (as I remember it, there were some that
> didn't care for this). (2) means that you'd need the corresponding
> driver installed (or an embedded copy as the case may be) in order to
> run those tests. (3) seems to be most consistent with how other
> people do it for code that connects to some service.
>
> --
> Eric Evans
> Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
Posted by Eric Evans <ee...@acunu.com>.
On Thu, Sep 1, 2011 at 9:08 AM, Eric Evans <ee...@acunu.com> wrote:
> On Wed, Aug 31, 2011 at 10:58 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>> On Wed, Aug 31, 2011 at 4:24 PM, Eric Evans <ee...@acunu.com> wrote:
>>> CASSANDRA-2936 is in progress (patches attached), but is there any
>>> reason not to get started with the Python driver now?
>>
>> Heads up that test/system/test_cql.py depends on the Python driver.
>> It should probably be moved to the Python driver's test suite. (Which
>> then needs the same kind of "start a Cassandra server" ability that
>> the Cassandra system tests have.)
>
> I posed a similar question about the JDBC driver in CASSANDRA-2936.
>
> Should these tests be considered functional tests of Cassandra, and
> left be left where they are? I know that was my intention WRT
> test_cql.py (the driver itself has a few tests of its own that do not
> require a server).
>
> I guess I don't have a strong opinion either way, though it seems
> easier to say that Cassandra's tests will require you to have a driver
> installed, versus having to configure the build/test of a driver to
> point to a Cassandra tree.
No opinions on this? To summarize, the options as I see them are:
1. Keep the tests that query Cassandra, as-is, with the drivers they use.
2. Leave the tests that query Cassandra with Cassandra, (i.e. consider
them Cassandra tests).
3. Keep the tests that query Cassandra, but alter them to be
idempotent and to connect to an existent node, instead of spinning
up/down an instance in test setup/teardown.
(1) requires that you have some way of pointing the build at a local
copy of a Cassandra tree (as I remember it, there were some that
didn't care for this). (2) means that you'd need the corresponding
driver installed (or an embedded copy as the case may be) in order to
run those tests. (3) seems to be most consistent with how other
people do it for code that connects to some service.
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
Posted by Eric Evans <ee...@acunu.com>.
On Fri, Sep 2, 2011 at 3:49 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Thu, Sep 1, 2011 at 9:08 AM, Eric Evans <ee...@acunu.com> wrote:
>> I posed a similar question about the JDBC driver in CASSANDRA-2936.
>>
>> Should these tests be considered functional tests of Cassandra, and
>> left be left where they are? I know that was my intention WRT
>> test_cql.py (the driver itself has a few tests of its own that do not
>> require a server).
>>
>> I guess I don't have a strong opinion either way, though it seems
>> easier to say that Cassandra's tests will require you to have a driver
>> installed, versus having to configure the build/test of a driver to
>> point to a Cassandra tree.
>
> I'd lean towards "the tests should be in the client trees." It feels
> odd to move the drivers out, but leave their test suites in core.
> (Keeping in mind that, as you pointed out, we have two more drivers
> almost done.)
Referring to the mail I sent before seeing this.... does that mean
option #1 or #3, require a Cassandra tree, or point to running
instance?
--
Eric Evans
Acunu | http://www.acunu.com | @acunu
Re: CQL Drivers
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Sep 1, 2011 at 9:08 AM, Eric Evans <ee...@acunu.com> wrote:
> I posed a similar question about the JDBC driver in CASSANDRA-2936.
>
> Should these tests be considered functional tests of Cassandra, and
> left be left where they are? I know that was my intention WRT
> test_cql.py (the driver itself has a few tests of its own that do not
> require a server).
>
> I guess I don't have a strong opinion either way, though it seems
> easier to say that Cassandra's tests will require you to have a driver
> installed, versus having to configure the build/test of a driver to
> point to a Cassandra tree.
I'd lean towards "the tests should be in the client trees." It feels
odd to move the drivers out, but leave their test suites in core.
(Keeping in mind that, as you pointed out, we have two more drivers
almost done.)
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: CQL Drivers
Posted by Eric Evans <ee...@acunu.com>.
On Wed, Aug 31, 2011 at 10:58 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Wed, Aug 31, 2011 at 4:24 PM, Eric Evans <ee...@acunu.com> wrote:
>> CASSANDRA-2936 is in progress (patches attached), but is there any
>> reason not to get started with the Python driver now?
>
> Heads up that test/system/test_cql.py depends on the Python driver.
> It should probably be moved to the Python driver's test suite. (Which
> then needs the same kind of "start a Cassandra server" ability that
> the Cassandra system tests have.)
I posed a similar question about the JDBC driver in CASSANDRA-2936.
Should these tests be considered functional tests of Cassandra, and
left be left where they are? I know that was my intention WRT
test_cql.py (the driver itself has a few tests of its own that do not
require a server).
I guess I don't have a strong opinion either way, though it seems
easier to say that Cassandra's tests will require you to have a driver
installed, versus having to configure the build/test of a driver to
point to a Cassandra tree.
--
Eric Evans
Acunu | http://www.acunu.com | @acunu