Yeah, Jonathan was headed in the right direction. I'm a bit wary of my own
coding practices, but I wanted to get what worked for me out there
somewhere, and this seemed like a convenient place for it.
Another point that comes to mind is that as I'm developing, I often drop
all the keyspaces and recreate them. However, I've noticed that sometimes,
maybe 30% of the time, uwsgi will continue to return data that was in the
dropped dataset. To fix this I'll restart the uwsgi server... I'd guess it
has to do with Cassandra clearing it's heap space related to a connection..
but I haven't gotten to the point to dig into Java much.
Aside from that and what I mentioned picking a row_factory, working with
Cassandra has gone pretty smoothly - hope it works for you.
Just to mention a few more things that confused me starting out: I would
recommend anyone considering using Cassandra read ebay's data modeling best
practices guides - but keep in mind MOST of the articles about Cassandra
don't apply to version 2+. A real big one was that "wide rows" don't
really exist anymore - but you can achieve the same effect with a layer of
composite columns. I think one draw to Cassandra is row slicing, but now
it's composite-column slicing. Note that you can't slice across the primary
key, unless you use one of the 'ordered' partitioners, which is not
recommended.
On Thursday, October 23, 2014 9:34:23 PM UTC-4, Rafael Riedel wrote:
>
> Howdy Taylor!
>
> Sorry about the delay to answer your message, I was busy with another
> project... :(
>
> You answer is simply amazing! I think this is what I'm looking for, and
> Jonanthan is right about the @postfork. Right now I'm trying using the
> cqlengine instead of pure datastax driver. I'll be starting coding right
> now and I hope in a couple of days have this correctly implemented. Stay
> tuned!
>
> Thank you very much! You helped me alot!
>
> Em quinta-feira, 9 de outubro de 2014 16h51min31s UTC-3, Taylor Gronka
> escreveu:
>>
>> Howdy Rafael. It's not so hard. here's something like my folder
>> structure, using the datastax driver:
>>
>> /www/mywebsite/cassandraconnection/simpleclient.py
>> # datastax imports
>> class SimpleClient():
>> session = None
>> def connect(self, nodes, certificate):
>> # some certification stuff here
>> cluster = Cluster(nodes, protocol_version=2, cql_version='3.1.7',
>> port=9042, ssl_options=ssl_options)
>> self.session = cluster.connect()
>> self.session.row_factory = dict_factory
>> # i like using the dict_factory - check out the other options if
>> you want though.
>> # but if you don't use the dict_factory then you might have to
>> zip your own results from cassandra, and results will be formatted in
>> different ways - that is, a single row will return as a list of dict items
>> iirc, while multiple rows will return as a list of dicts, but that list is
>> the first item of a list ( a list wtihin a list).. just kind of awkward
>> results
>>
>> def close(self):
>> self.session.cluster.shutdown()
>> self.session.shutdown()
>> log.info('Connection closed.')
>>
>> /www/mywebsite/pyramidstuff/models.py
>> from cassandraconnection import SimpleClient
>> Session = SimpleClient()
>> # because this is imported into the __init__.py, this creates the
>> SimpleClient() object when your code runs - but note that it does not
>> connect yet - it just sits there
>>
>> /www/mywebsite/pyramidstuff/__init__.py
>> # import the SimpleClient code to expose it
>> from cassandraconnection import SimpleClient
>> # import the simple client object
>> from .models import Session
>>
>> # because i use uwsgi, i run multiple 'forks' of cassandra. if you don't
>> fork here, you'll have clashes between your multiple instances of a single
>> connection to the database clashing. this step in effect creates a separate
>> connection for each client
>> from uwsgidecorators import *
>> @postfork
>> def connect_cassandra_client():
>> CaSession.connect(['127.0.0.1'], certificate='/path/here')
>> print("connection to cassandra made")
>>
>> # the new version of cassandra highly recommends a clean shutdown, i think
>> import atexit
>> @atexit.register
>> def shutdown_cassandra_client():
>> Session.close()
>> print("cassandra conn closed")
>>
>>
>> having said all that, the new version of cqlengine uses the datastax
>> driver as a backend, which might be a lot easier to work with - they made
>> that change in june/july iirc. However, Cassandra updates very, very
>> often, and I'm doing some unique stuff with it, so I chose not to use
>> cqlengine, although chances are it's what you want to use.
>>
>> Oh actually the crummy part is waitress doesn't work well with the
>> datastax driver for some reason - you'll probably get weird errors and
>> disconects. I changed to nginx + uwsgi, which isn't very hard to do at all
>> with pyramid. In the simplest case, set up nginx, and just add a [uwsgi]
>> section to your development.ini with the necessary things, and use:
>> $VENV/bin/pip install uwsgi
>> $VENV/bin/uwsgi --ini-paste /www/mywebsite/pyramidstuff/development.ini
>>
>> I'm writing parts of this off memory, and trying to summarize the code I
>> am looking at, so excuse my mistakes please, but it should give you an idea
>> of a method that works.
>>
>> use from .models import Session to access the connection, and from there
>> I either write code in classes which write directly to cassandra, or for a
>> select few functions I import SimpleClient.py to do like simpler things. I
>> have to go so I can't finish this gl tho
>>
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.
