Develop Reference

Purpose of SQLAlchemy over MYSQL CONNECTOR PYTHON

I am new to working with databases and couldn't find any relevant answers for this.
What are the uses of SQLAlchemy over MYSQL CONNECTOR for python.

I do not have much experience with MYSQL CONNECTOR for Python. However, from what I know SQLAlchemy primarily uses ORM (Object-Relational Mapping) in order to abstract the details of handling the database. This can help avoid errors some times (and also introduce possibly introduce others). You might want to have a look at the ORM technique and see if it is for you (but don't use it as a way to avoid learning SQL). Generally, ORMs tend not to be as scalable as raw SQL either.

I am also a newbie. In my understanding SQLAlchemy is an ORM (Object-Relational Mapping) that allows you to abstract the database and query data from the DB more easily in your coding language treating query data as another object. Pros is that that you can more easily switch your DB under the hood. But it has some learning curve.
Whereas MySQL Connector is "just" a plain simple direct connection to the DBMS at your database and you write SQL queries to get the data.
For now I am sticking with the mysql connector to just train SQL queries more. But later on I will definitely test out SQLAlchemy.

Does Python's SQLAlchemy support server side cursor (for MSSQL)?

I would like to query a MSSQL database using Python's SQLAlchemy. There could be tens of millions of matched rows. In order to use less memory at the server side, I consider using server-side cursor (SSCursor) to slice the matched rows. However, I cannot find examples or resources about SSCursor with SQLAlchemy.
Is it possible to use SSCursor with SQLAlchemy? If this is do-able, can someone show me examples or point out references? If not, any suggested workarounds?
Thanks!

Yes. You just specify the 'cursorclass' option in the connect_args argument. Here is an example with mysql. You'll need to use an MSSQL connector that implements server side cursors like MySQLdb does for mysql as shown below.
from sqlalchemy import create_engine, MetaData
import MySQLdb.cursors
engine = create_engine('mysql://your:details#go/here', connect_args={'cursorclass': MySQLdb.cursors.SSCursor})

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.

SQLAlchemy and django, is it production ready?

Has anyone used SQLAlchemy in addition to Django's ORM?
I'd like to use Django's ORM for object manipulation and SQLalchemy for complex queries (like those that require left outer joins).
Is it possible?
Note: I'm aware about django-sqlalchemy but the project doesn't seem to be production ready.

What I would do,
Define the schema in Django orm, let it write the db via syncdb. You get the admin interface.
In view1 you need a complex join
def view1(request):
import sqlalchemy
data = sqlalchemy.complex_join_magic(...)
...
payload = {'data': data, ...}
return render_to_response('template', payload, ...)

I've done it before and it's fine. Use the SQLAlchemy feature where it can read in the schema so you don't need to declare your fields twice.
You can grab the connection settings from the settings, the only problem is stuff like the different flavours of postgres driver (e.g. with psyco and without).
It's worth it as the SQLAlchemy stuff is just so much nicer for stuff like joins.

I don't think it's good practice to use both. You should either:
Use Django's ORM and use custom SQL where Django's built-in SQL generation doesn't meet your needs, or
Use SQLAlchemy (which gives you finer control at the price of added complexity).
Of course, if you need Django's admin, then the first of these approaches is recommended.

Jacob Kaplan-Moss admitted to typing "import sqlalchemy" from time to time. I may write a queryset adapter for sqlalchemy results in the not too distant future.

Nowadays you can use Aldjemy. Consider using this tutorial.

cx_Oracle and the data source paradigm

There is a Java paradigm for database access implemented in the Java DataSource. This object create a useful abstraction around the creation of database connections. The DataSource object keeps database configuration, but will only create database connections on request. This is allows you to keep all database configuration and initialization code in one place, and makes it easy to change database implementation, or use a mock database for testing.
I currently working on a Python project which uses cx_Oracle. In cx_Oracle, one gets a connection directly from the module:
import cx_Oracle as dbapi
connection = dbapi.connect(connection_string)
# At this point I am assuming that a real connection has been made to the database.
# Is this true?
I am trying to find a parallel to the DataSource in cx_Oracle. I can easily create this by creating a new class and wrapping cx_Oracle, but I was wondering if this is the right way to do it in Python.

You'll find relevant information of how to access databases in Python by looking at PEP-249: Python Database API Specification v2.0. cx_Oracle conforms to this specification, as do many database drivers for Python.
In this specification a Connection object represents a database connection, but there is no built-in pooling. Tools such as SQLAlchemy do provide pooling facilities, and although SQLAlchemy is often billed as an ORM, it does not have to be used as such and offers nice abstractions for use on top of SQL engines.
If you do want to do object-relational-mapping, then SQLAlchemy does the business, and you can consider either its own declarative syntax or another layer such as Elixir which sits on top of SQLAlchemy and provides increased ease of use for more common use cases.

I don't think there is a "right" way to do this in Python, except maybe to go one step further and use another layer between yourself and the database.
Depending on the reason for wanting to use the DataSource concept (which I've only ever come across in Java), SQLAlchemy (or something similar) might solve the problems for you, without you having to write something from scratch.
If that doesn't fit the bill, writing your own wrapper sounds like a reasonable solution.

Yes, Python has a similar abstraction.
This is from our local build regression test, where we assure that we can talk to all of our databases whenever we build a new python.
if database == SYBASE:
import Sybase
conn = Sybase.connect('sybasetestdb','mh','secret')
elif database == POSTRESQL:
import pgdb
conn = pgdb.connect('pgtestdb:mh:secret')
elif database == ORACLE:
import cx_Oracle
conn = cx_Oracle.connect("mh/secret#oracletestdb")
curs=conn.cursor()
curs.execute('select a,b from testtable')
for row in curs.fetchall():
print row
(note, this is the simple version, in our multidb-aware code we have a dbconnection class that has this logic inside.)

I just sucked it up and wrote my own. It allowed me to add things like abstracting the database (Oracle/MySQL/Access/etc), adding logging, error handling with transaction rollbacks, etc.