Sqlalchemy ORM operates on database not created from sqlalchemy

[Ni Wesley]

Hi guys,

   I have a question here.

Just as the title, I mean, for example:

I am using mysql as the database engine.

Now, I use sqlalchemy ORM to map python class to database table.

My question is here:

Actually, there are specified teams to do the database design and tables creation work.

Which means that, I won't sync table structures from sqlalchemy something like from session.create_all().

So,if I keep my model class synced with the database table structure, can I still use ORM operations, say, session.query(Class), session.add, session.commit .etc 

Thanks.

Wesley

[Simon King]

Yes, absolutely. SQLAlchemy doesn't care how the database was created.
You should be able to use all the normal operations on a database
created by some other means.

Hope that helps,

Simon

[Ni Wesley]

I mean sqlalchemy ORM, that is, use python class mapping to database table.

I know sqlalchemy core expression does work, this guy doesn't care how database is created.

Wesley

--
You received this message because you are subscribed to a topic in the Google Groups "sqlalchemy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sqlalchemy/l94LE3Am2f8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sqlalchemy+...@googlegroups.com.
To post to this group, send email to sqlal...@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Rogers]

On Wednesday, January 22, 2014 6:34:59 PM UTC-5, Ni Wesley wrote:

I mean sqlalchemy ORM, that is, use python class mapping to database table.

I know sqlalchemy core expression does work, this guy doesn't care how database is created. 

SQLAlchemy certainly works fine regardless of how tables were defined. SQLAlchemy's ability to create database objects is a convenience only. I'm using SQLAlchemy within an application that mostly uses a different ORM. All tables and other database objects are created by hand-written SQL. I use SQLAlchemy's Declarative extension to define mapped classes for those tables which I care about. Sometimes, I use SQLAlchemy's introspection to build queries. Declarative, introspection and the non-SQLAlchemy parts of the system all coexist just fine.

[Simon King]

All the ORM really cares about is that the tables that you map classes to have some combination of columns that will uniquely identify each row. Normally that will be the table's primary key, but it doesn't have to be.

That's the only restriction on the ORM that comes to mind.

Hope that helps,

Simon

You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com.

[Jonathan Vanasco]

Just to rephrase everyone else's "It doesn't matter" response:

Many ORMs out there REQUIRE the database be built by the ORM or designed by the ORM.  This is because the ORM stores and accesses data in a very particular manner -- so tables and columns must adhere to certain naming conventions, and tables must have certain types of primary keys or cross-table joins.  The ORM ends up designing the database to be what is easiest/best for the ORM.

SqlAlchemy is the exact opposite.  It lets you map ORM classes to new or existing database structures of your choice.  You can map virtually any legacy database you have onto a set of SqlAlchemy ORM classes.  You're fully able to define the table and column names, their content types, and their relations across the database.  You have nearly no restrictions.  [ I've never encountered a restriction, but there could be. ]  You can design the database to be what is best for your application logic or data warehousing needs.