On 5/19/15 1:51 PM, Rich Shepard wrote:
I thought there was a thread on this but I cannot find it so please
point
me to that thread if it exists.
An application will be provided in two versions: a single-user version
with SQLite3 as the backend, and a multi-user version with PostgreSQL
as the
backend.
Am I correct that the only necessary change in the SQLAlchemy code
is the
engine specification?
There's not a simple yes or no answer to that question. Yes, if you
change the engine specification, a simple SQLAlchemy application and
even a very complex one will successfully interact with SQLite and
Postgresql with no other changes. This is very common.
But also, no, in that if your application relies upon special, or even
not-so-special features of SQLite or Postgresql and provides no
equivalent operation for the other, the use of these features would have
to be developed such that an equivalent operation is performed on each
backend. Examples: date and time functions are entirely different on
both platforms, schema migration operations e.g. ALTER are generally not
supported on SQLite, SQLite has very different behavior regarding
foreign key constraints (in that they do nothing unless special
directives are emitted per-connection), transactional features like
SAVEPOINT have caveats on SQLite, Postgresql has a vast array of
datatypes like HSTORE, JSON that are not supported on SQLite, SQLite has
a very restrictive concurrency model compared to Postgresql and pretty
much any other database, SQLite does not support RETURNING, does not
support right-nested JOINs, etc. etc. etc., there are literally many
hundreds of behavioral and feature differences.
However, it's very possible that your application is not making use of
any of these features or behaviors, or is making adequate use of
SQLAlchemy Core/ORM such that a subset of these differences are
abstracted away; examples: RETURNING for primary key retrieval is used
internally only if available, right-nested joins are abstracted away in
many ORM scenarios, platform-agnostic datatypes like Boolean and
DateTime provide emulation for these non-existent types on SQLite.
The only way to know is via research of backend capabilities and
thorough testing. SQLAlchemy's job is just to expedite the
communication with these backends and provide a modicum of commonality
between them, but it does not limit all operations to the lowest common
denominator of database features; such a system would be largely
unusable especially given SQLite's extremely limited capabilities.
A good amount of starting detail is available in the documentation for
both backends:
http://docs.sqlalchemy.org/en/rel_1_0/dialects/sqlite.html
http://docs.sqlalchemy.org/en/rel_1_0/dialects/postgresql.html
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
