SQL abstraction layer (such as SQLAlchemy)

[posativ]

Support for MySQL and PostgreSQL should also be added for users or hosting environments that prefer MySQL/PGSQL. As database abstraction layer SQLAlchemy seems to be the best solution for Python (supports Python2/3, available in Debian, extensive documentation).

This also (hopefully) eases the task of changing the database schema to support new features such as #27 (which is currently non-functional).

If possible, SQLAlchemy can use its own connection pool or set up on the existing locking mechanism for threads/processes/uWSGI.

[lucian1900]

SQLAlchemy is indeed great and Alembic is quite nice for migrations.

[khromov]

This would be very nice!

[shulegaa]

As much as I'm a fan of both PostgreSQL and SQLAlchemy, timing is everything. First, notice that comments on web pages (e.g. blog posts) is neither big data nor complex data. This isn't like some enterprise resource planning application - or an electronic medical records application.

IMHO, a maximally simple data schema (drawn over a maximally simple data model - e.g. relational) is a darn good fit. Witness the success of SQLite with isso already. Martin Fowler, and Eric Evans (off DDD fame), has complained about the proliferation of "anemic domain models" - but when you do without object relational mapping (ORM) - to step up to a richer domain model - it would be tragic to miss the opportunity to do keep it simple and straight-forward (KISS).

I can see going for ORM/SQLAlchemy, and all the good reasons for adding SQLAlchemy ... and maybe even more pressing good reasons to support PostgreSQL. I'm just saying that this might we pretty far down the list of upcoming isso features/functions.

For example, I was just noticing that isso doesn't (yet) install/operate behind a NATing firewall - even when co-resident with a static (Pelican-generated) blog. Then there's boring stuff like documentation and packaging and logging/diagnostics ... and who knows ... maybe even more comprehensive QA automation. I get the feeling that SQLAlchemy (and PostgreSQL support) might wait for the v2.x (second generation) of isso.

Heck, I'd love to see isso --version supported before PostgreSQL and/or ORM (internals). Not my call - but just trying to help isso win the most traction/success in the shortest possible amount of time ...

[posativ]

If isso --version is not working for you, please open a new ticket ;)

But I get your point. An ORM is admittedly an overkill currently, but what is really needed is glue code for writing SQL queries compatible with SQLite, MySQL and PostgreSQL as well as managing different databases and connection pooling (managing three different lock types is really ugly).

While SQLite is really simple to use and works out-of-the-box(tm), it has its drawbacks that it may not integrate well in backups. If you use PostgreSQL or MySQL you or your provider automatically backups the whole database. For SQLite there's an API not used by rsync and you may end up with an inconsistent database (unless you backup read-only filesystem snapshots which I do ;-). For the reason I dislike projects which do only work with MySQL or PostgreSQL, people may dislike project with some weird single-file database writeable by www-data.

I do not work on this issue. You are right, there are higher prioritory issues. But if someone else implements an adapter, I'll happily merge it.

[lucian1900]

I think it would be a good strategy to move to the SQL-only layer in SQLAlchemy and ignore the ORM for now. That should be a mostly mechanical transformation and give database portability almost automatically.

Later on Alembic migrations and ORM can be used, if deemed useful.

I also am not working on this, though :)

[wprater]

It would be great to get this running on the Google App Engine, but is not currently possible because the lack of support for their Datastore or Cloud SQL.

[posativ]

I've been working on SQLAlchemy integration, which supports the db dialect of GAE. The feature is not yet merged into the master, though.

[wprater]

@posativ nice to hear! If end up using isso over here, I can help with your integration, if needed!

[skylord123]

Just going to give this a little bump. MySQL support would be nice.

5 years without any progress, hopes are low.

[colindembovsky]

@posativ @skylord123 I've forked the repo to add MySQL support here. I'm using this version on my ghost blog running in Azure Web App for Linux using Azure MySQL backend. I don't use voting, so I haven't tested that thoroughly and I removed the migration tasks that spin up in__init.py__ for the db module (I assume these are to convert older sqlite3 databases) which I didn't need.

[skylord123]

@colindembovsky nice work!

I would try it out but I already jumped ship to commento. I kept running into issues with running ISSO in a docker container and it was also lacking a lot of features I wanted (and by the looks of it new features aren't coming anytime soon).

[antont]

Just FYI that have been testing this fork now and it seems to be working ok so far, https://github.com/jingwanhsu/isso-postgresql

[ix5]

Collecting: https://github.com/jingwanhsu/isso-postgresql, https://github.com/colindembovsky/isso-mysql, https://github.com/posativ/isso/pull/108