When I run my Python scripts that use Cassandra, I get the following warning:
/home/ubuntu/.local/lib/python2.7/site-packages/cassandra/cqlengine/management.py:545: UserWarning: CQLENG_ALLOW_SCHEMA_MANAGEMENT environment variable is not set. Future versions of this package will require this variable to enable management functions.
Sounds reasonable enough, but I searched and I searched and couldn't figure out what CQLENG_ALLOW_SCHEMA_MANAGEMENT is or how to set it.
What is it and what should I set it to?
Looking at the code of the driver, it seems that it is a boolean flag that will indicate if the application will be allowed or not to modify the schema with the application.
There are several examples like this fix for a django project or this eventsourcing code that solves the issue with a quick and dirty approach, setting explicitly the value with something like:
if os.getenv('CQLENG_ALLOW_SCHEMA_MANAGEMENT') is None:
os.environ['CQLENG_ALLOW_SCHEMA_MANAGEMENT'] = '1'
Doing some additional research, Srikanth Bemineni's post in the driver forum, mentioned that he was able to solve the issue using the new integrated cqlengine in the cassandra python driver instead of using the cqlengine from the module, but I couldn't figure out what was he referring to.
Related
The project I'm working in is still using google-api-python-client which is deprecated and the official documentation has no examples for it. I've gotten BigQuery working with it but I can't seem to figure out how to set configuration properties, specifically so that I can run a query with BATCH priority.
Can anyone point me in the right direction?
The answer is to use jobs().insert() rather than jobs().query(). Inserting a new job asynchronously gives the caller the ability to specify a wide range of options but requires them to run another command to get the results.
So assuming gs is your authenticated service object:
# insert an asynchronous job
jobr = gs.jobs().insert(projectId='abc-123', body={'configuration':{'query':{'query':'SELECT COUNT(*) FROM schema.table'}}}).execute()
# get query results of job
gs.jobs().getQueryResults(projectId='abc-123', jobId=jobr['jobReference']['jobId']).execute()
Using python-keyring, can one dump all of the available passwords? I'm looking for an iterate_passwords() or similar, but it doesn't seem to exist.
According to this blog post, this is possible using gnomekeyring, but I can't find anything similar in python-keyring, which appears to be a much more prevalent library.
According to the python-keyring documentation, the keyring backends only specify get_, set_ and delete_ methods for single passwords. For example, see the Gnome backend.
There is an open issue on this, which states:
The current API does not provide a way to enumerate keys.
I want to be able to add daily info to each object and want to have the ability to delete info x days old easily. With the tables I need to look at the trends and do stuff like selecting objects which match some criteria.
Edit: I asked this because I'm not able to think of a way to implement deleting old data easily because you cannot delete tables in sqlite
Using sqlite would it be the best option, is file based, easy to use, you can use Lookups with SQL and it's builtin on python you don't need to install anything.
→ http://docs.python.org/library/sqlite3.html
If your question means that you are just going to be using "table like data" but not bound to a db, look into using this python modul: Module for table like snytax
If you are going to be binding to a back end, and not* distributing your data among computers, then SQLite is the way to go.
A "proper" database would probably be the way to go. If your application only runs on one computer and the database doesn't get to big, sqlite is good and easy to use with python (standard module sqlite3, see the Library Reference for more information)
take a look at the sqlite3 module, it lets you create a single-file database (no server to setup) that will let you perform sql queries. It's part of the standard library in python, so you don't need to install anythin additional.
http://docs.python.org/library/sqlite3.html
I'm wondering if someone can recommend a good pattern for deploying database changes via python.
In my scenario, I've got one or more PostgreSQL databases and I'm trying to deploy a code base to each one. Here's an example of the directory structure for my SQL scripts:
my_db/
main.sql
some_directory/
foo.sql
bar.sql
some_other_directory/
baz.sql
Here's an example of what's in main.sql
/* main.sql has the following contents: */
BEGIN TRANSACTION
\i some_directory/bar.sql
\i some_directory/foo.sql
\i some_other_directory/baz.sql
COMMIT;
As you can see, main.sql defines a specific order of operations and a transaction for the database updates.
I've also got a python / twisted service monitoring SVN for changes in this db code, and I'd like to automatically deploy this code upon discovery of new stuff from the svn repository.
Can someone recommend a good pattern to use here?
Should I be parsing each file?
Should I be shelling out to psql?
...
What you're doing is actually a decent approach if you control all the servers and they're all postgresql servers.
A more general approach is to have a directory of "migrations" which are generally classes with an apply() and undo() that actually do the work in your database, and often come with
abstractions like .create_table() that generate the DDL instructions specific to whatever RDBMS you're using.
Generally, you have some naming convention that ensures the migrations run in the order they were created.
There's a migration library for python called South, though it appears to be geared specifically toward django development.
http://south.aeracode.org/docs/about.html
We just integrated sqlalchemy-migrate which has some pretty Rails-like conventions but with the power of SQLAlchemy. It's shaping up to be a really awesome product, but it does have some downfalls. It's pretty seamless to integrate though.
I'm working on a small project, and I wanted to provide multiple caching options to the end user. I figured with Django it's pretty simplistic to swap memcached for database or file based caching. My memcached implementation works like a champ without any issues. I placed time stamps on my pages, and curl consistently shows the older timestamps in locations where I want caching to work properly. However, when I switch over to the database caching, I don't get any entries in the database, and caching blatantly doesn't work.
From what I see in the documentation all that should be necessary is to change the backend from:
CACHE_BACKEND = 'memcached://localhost:11211'
To:
CACHE_BACKEND = 'db://cache_table'
The table exists after running the required manage.py (createcachetable) line, and I can view it just fine. I'm currently in testing, so I am using sqlite3, but that shouldn't matter as far as I can tell. I can confirm that the table is completely empty, and hasn't been written to at any point. Also, as I stated previously, my timestamps are 'wrong' as well, giving me more evidence that something isn't quite right.
Any thoughts? I'm using sqlite3, Django 1.0.2, python 2.6, serving via Apache currently on an Ubuntu Jaunty machine. I'm sure I'm just glossing over something simple. Thanks for any help provided.
According to the documentation you're supposed to create the table not by using syncdb but with the following:
python manage.py createcachetable cache_table
If you haven't done that, try and see if it doesn't work.