Develop Reference

How to have PyCharm show the tables in a Django SQLite database?

I'm not very familiar with Django (I've used more Flask, Web.py, and Falcon), and one thing that I'm finding strange is that when I look at the 'Database' tab in PyCharm, I don't see a list of all of the tables that seem to be getting used in the database:
If I use python manage.py dbshell to start a sqlite3 session and then type .tables, this is the list of tables that I see:
How do I get those tables to be browsable from within the PyCharm database viewer?

Posting the comment as an answer:
PyCharm is occasionally a little slow on the uptake for new tables.
The Refresh/Synchronize button on the Database panel usually fixes that.

Sqlite3 or QtSql

Need to make a small database for a desktop app built using PySide. I don't know if both(sqlite3 and QtSql) are similar or not, but I'm leaning towards sqlite3. This is because, well, its Pythonic! I wanna know if I'll be missing out on something or not, such as performance, features, etc. (Or is there a convention to use each one considering the project at hand?)
I know this question will get closed because it may not seem constructive enough, and I'm sorry for that.

QtSql isn't a database engine like SQLite is, rather it is software for accessing databases through the Qt environment.
The Qt SQLite plugin makes it possible to access SQLite databases.
SQLite is an in-process database, which means that it is not necessary
to have a database server. SQLite operates on a single file, which
must be set as the database name when opening a connection. If the
file does not exist, SQLite will try to create it. SQLite also
supports in-memory databases, simply pass ":memory:" as the database
name. - Source

medium - large portable database options for python program

I am creating a simple python program that needs to search a somewhat large database ( ~40 tables, 6 Million or so rows all together ).
Currently, I use MySQLdb to query my local MySQL database then I have some other python function that work with the data and returns some statistics and other stuff. I would like to share this with others that do not want to construct their own database. At this point the database is used for queries only.
How best can I share the database and python program as a "package". Do I have to give up on the SQL method and switch to some sort of text file database or is there an easier way... sqlite maybe?
If the answer is sqlite how do I go about exporting my current SQL database to the sqlite database? Is there any gotchas I should know about?
Currently I use simple SELECT quarries with a few WHERE statements to locate the data I need. I am afraid that if I switched to text based database I would end up having to write a large amount of code to make these queries.
Thank you in advance for any suggestions.
EDIT
So I wrote my little python program with an sqlite3 database and it works perfectly.
I ended up using using a shell script called mysql2sqlite.sh found here to convert my MySQL database to sqlite. It worked flawlessly.
I only had to change 2 lines of python code. Awesome.
My little program runs in osx, windows and linux (ubuntu and redhat) without any changes or hassle. Thanks for the advise!

Converting your database could be as easy as an sql-dump and then an import, depending on the complexity of your db. See this post for strategies and alternatives.

Create sqlite virtual table in Python

I want to create a SQL-like interface for a special data source which I can query using Python. That is, I have a data source with a number of named iterable containers of entities, and I would like to be able to use SQL to filter, join, sort and preferably update/insert/delete as well.
To my understanding, sqlite3's virtual table functionality is quite suitable for this task. Is it possible to create the necessary bindings in Python? I understand that the glue has to be c-like, but my hope is someone already wrote a Python wrapper in C or using ctypes.
I will also accept an answer for a better/easier way of doing this.

You can do this by registering a virtual table in SQLite with the APSW Python bindings.
An example for talking to CouchDB using APSW.
There's a similar capability for Perl, namely:
Create SQLite Virtual Table extensions in Perl
Finally, if you want to make a Python-based virtual table in PostgreSQL 9.1, check out http://multicorn.org/.

Sounds like you can use SQLAlchemy to persist these objects to sqlite3, possibly to an in :memory: db, and issue both object and table level (raw sql) queries. You can also update/insert/delete them easily.

Setting up Pyramid to use MySQL raw instead of SQLAlchemy

We're trying to set up a Pyramid project that will use MySQL instead of SQLAlchemy.
My experience with Pyramid/Python is limited, so I was hoping to find a guide online. Unfortunately, I haven't been able to find anything to push us in the right direction. Most search results were for people trying to use raw SQL/MySQL commands with SQLAlchemy (many were re-posted links).
Anyone have a useful tutorial on this?

Pyramid at its base does not assume that you will use any one specific library to help you with your persistence. In order to make things easier, then, for people who DO wish to use libraries such as SQLALchemy, the Pyramid library contains Scaffolding, which is essentially some auto-generated code for a basic site, with some additions to set up items like SQLAlchemy or a specific routing strategy. The pyramid documentation should be able to lead you through creating a new project using the "pyramid_starter" scaffolding, which sets up the basic site without SQLAlchemy.
This will give you the basics you need to set up your views, but next you will need to add code to allow you to connect to a database. Luckily, since your site is just python code, learning how to use MySQL in Pyramid is simply learning how to use MySQL in Python, and then doing the exact same steps within your Pyramid project.
Keep in mind that even if you'd rather use raw SQL queries, you might still find some usefulness in SQLAlchemy. At it's base level, SQLAlchemy simply wraps around the DBAPI calls and adds in useful features like connection pooling. The ORM functionality is actually a large addition to the tight lower-level SQLAlchemy toolset.

sqlalchemy does not make any assumption that you will be using it's orm. If you wish to use plain sql, you can do so, with nothing more than what sqlalchemy already provides. For instance, if you followed the recipe in the cookbook, you would have access to the sqlalchemy session object as request.db, your handler would look something like this:
def someHandler(request):
rows = request.db.execute("SELECT * FROM foo").fetchall()

The Quick Tutorial shows a Pyramid application that uses SQL but not SQLAlchemy. It uses SQLite, but should be reasonably easy to adapt for MySQL.