zzzeek - Latest Comments

Re: zzzeek : Patterns Implemented by SQLAlchemy

Henrique Bastos — Thu, 09 Feb 2012 12:36:40 -0000

Awesome references! Anyone working with ORMs should read this!

Re: zzzeek : Patterns Implemented by SQLAlchemy

Guest — Tue, 07 Feb 2012 15:33:53 -0000

I started using SQLAlchemy couple of weeks/months after reading this great book and I must say I learned it very quickly as everything seemed very natural. I suggest mentioning the patterns in the documentation.

Re: zzzeek : Django-style Database Routers in SQLAlchemy

Samir Mamude — Mon, 30 Jan 2012 16:53:08 -0000

Thanks a lot!!!! I was looking for a solution to enable queries by subdomains and your example, works like a charm!

Re: zzzeek

vincent — Sun, 29 Jan 2012 17:27:14 -0000

Hi,
here my hack just to replace the accents by their corresponding letters
http://pastebin.com/JUL9BQdm
example :
"l'agilité" become l-agilite
Thanks for the original hack

Re: zzzeek : Django-style Database Routers in SQLAlchemy

zzzeek — Sat, 28 Jan 2012 18:28:53 -0000

yeah in reality I like having explicit control the best as well. I usually like to organize it in as coarse-grained a way as possible - like having @with_db('slave') on the whole web request, for example... or @using_shard(shard_for_user(current_user)). It means you're just using one database for the whole request and don't need to complicate how the ORM does things.

Re: zzzeek : Django-style Database Routers in SQLAlchemy

Jonathan Vanasco — Thu, 26 Jan 2012 22:40:48 -0000

i had something like this working under pylons a while back.

i only bring it up, because i did something slightly different... i set it up so my syntax is:

m1 = dbSession('master').query(Model1).first()

i found that to be much better - just always having an explicit db handle

Re: zzzeek : Alembic Documentation Ready for Review

andyparsons — Mon, 02 Jan 2012 17:17:51 -0000

Gotcha. It's helpful in a team setting where one could say to another developer "look at the create_users migration. Great for the files to be sortable on the filesystem, but appending a friendly name would be a requirement for us FWIW. Thanks.

Re: zzzeek : Alembic Documentation Ready for Review

zzzeek — Mon, 02 Jan 2012 17:00:31 -0000

It is a possible enhancement. For me, it wouldn't be super helpful, I still find I have to do the "history" call no matter what to see which file is which as it will put them in order. If there were some way to get the files to list out in order, maybe a letter-based sort key like "aaaa", "aaab", etc., if you wanted to splice in the middle you'd say "aaaba", shrugs..

Re: zzzeek : Alembic Documentation Ready for Review

andyparsons — Mon, 02 Jan 2012 16:50:37 -0000

Nice work. One quick question- why not use human readable filenames, a la ActiveRecord migrations? e.g. 45329072ab2d_create_users.py

Re: zzzeek : The Enum Recipe

danc86 — Wed, 14 Dec 2011 21:17:08 -0000

This is really handy! Any chance of it becoming a blessed ORM feature, or at least an official extension, in future releases?

Re: zzzeek : SQLAlchemy - an Architectural Retrospective

zzzeek — Thu, 24 Nov 2011 10:45:19 -0000

that is planned; a full book would make use of lots of the online documentation content for the reference material. Though we had in mind a new series of "examples" that that ties in with a full sample application (which is partially written already). Also the book needs to spend a lot more time on concepts - relational databases, SQL, approach to application design - since that's what the "book crowd" is really looking for.

edit: "we" here has been a moving target :|

Re: zzzeek : SQLAlchemy - an Architectural Retrospective

codeape — Thu, 24 Nov 2011 10:38:02 -0000

I think the content on www.sqlalchemy.org/docs/ is quite good. The pdf "feels" like a book. Why not let the docs be "the book"? I'm sure people can help out if there are parts that need restructuring etc.

Re: zzzeek : SQLAlchemy - an Architectural Retrospective

zzzeek — Thu, 24 Nov 2011 10:23:16 -0000

yes there's been book plans for several years now with a handful of false starts. it's not a great situation and I'm still trying to figure it out.

Re: zzzeek : SQLAlchemy - an Architectural Retrospective

codeape — Thu, 24 Nov 2011 04:34:05 -0000

Any plans of a new/updated SQLAlchemy book?

Great library, by the way. Part of my standard setup, wouldn't dream of talking to a database without it.

Re: zzzeek : Alembic Documentation Ready for Review

Kamil Kisiel — Mon, 21 Nov 2011 19:23:17 -0000

Yeah and that breaks a lot of things they didn't take in to account such as foreign keys...

Re: zzzeek : Alembic Documentation Ready for Review

zzzeek — Wed, 16 Nov 2011 20:09:34 -0000

migrate's way of doing "migrations" with SQLite is IMHO a huge hack, and can only have a superficial level of compatibility with that of other kinds of databases. If you use SQLite as your dev DB, your build process should simply create a new database on that backend and re-install the bootstrap/test data it uses. Migrations are used for production databases which have data that can't be dropped. It's also a good idea to have the migrations run under continuous integration, but that environment also would have a database that resembles production, AKA your Postgresql DB.

In the bigger scheme of things, I think SQLite is too incompatible with PG, not just with migrations but also its absolutely nasty non-support for dates, timestamps and precision numerics for it to be realistic as a "development" version of PG. PG is free and runs on every platform, the devs should just be using it directly.

Re: zzzeek : Alembic Documentation Ready for Review

delijati — Wed, 16 Nov 2011 06:02:21 -0000

I think the major difference is that sqlalchemy-migrate support operations on sqlite by doing some workarounds aka "alter table = rename old; create new; move data to new; drop old"

http://readthedocs.org/docs/sq...

Atm we use sqlalchemy-migrate because we work on sqlite in dev and on postgres live.

Re: zzzeek : Alembic Documentation Ready for Review

zzzeek — Fri, 11 Nov 2011 01:33:39 -0000

ha, funny. too bad they didn't get the name on the Python cheese shop ! :)

that said, if Lucasfilm would like to "come out of the closet", make it public they use SQLAlchemy internally (something I've heard) and give me a nice case study to put on my site, I'll change the name here.

Re: zzzeek : Alembic Documentation Ready for Review

Fudge — Fri, 11 Nov 2011 00:50:27 -0000

Did you know about this ? http://alembic.io/

Re: zzzeek : Alembic Documentation Ready for Review

David Cramer — Thu, 10 Nov 2011 17:41:12 -0000

I would love to see South adopt some of this behavior. For us, things like the ability to dump raw SQL (via --sql) and pruning old migrations (simply by setting a new base) are awesome.

We've managed to hack in a SQL logger to intercept a *majority* of what South does, but rebasing migrations is always painful.

Re: zzzeek : Alembic Documentation Ready for Review

Carl Meyer — Thu, 10 Nov 2011 17:36:29 -0000

At the moment South doesn't try to auto-detect renames at all, it just assumes add/drop and you have to manually edit the migration if you want a rename. I've heard that rename-detection is on the roadmap, but I don't know specifics of implementation plans. I can't really see rename autodetection being reliable enough to do automatically without a user prompt, in any case.

Re: zzzeek : Alembic Documentation Ready for Review

bloodearnest — Thu, 10 Nov 2011 10:14:05 -0000

Good stuff!

FWIW, I commented on the reddit thread: http://www.reddit.com/r/Python...

Re: zzzeek : Alembic Documentation Ready for Review

Tobu — Thu, 10 Nov 2011 09:03:10 -0000

My take on auto migrations and name changes is that if Alembic detects an added column matches a deleted column, it should prompt the user to confirm that this is a rename. South does a lot of prompting (since it generates forward and backward migrations, it needs default values for additions and deletions), and I find it user-friendly.

More complex operations can be handled by breaking them down: rename the column and autogenerate a migration, change the type and autogenerate immediately again. Support for squashing migrations together would be convenient; it would make rename+typechange simpler to apply, and would be useful when a lot of modifications were made in a private repo / local clone, to remove irrelevant detail before wider distribution.

Re: zzzeek : Hybrids and Value Agnostic Types

Scott Torborg — Wed, 09 Nov 2011 17:04:28 -0000

Thanks, that is really sweet.

Re: zzzeek : Alembic Documentation Ready for Review

Georges Dubus — Wed, 09 Nov 2011 08:41:25 -0000

I don't know if it's the main opinion, but I personally believe that automatic migration should be the norm and the manual way only a fallback option. In the same way, maybe the down_version should be somewhat automatically filled.

Anyway, keep up the good work !