#django

mattmcc: ah, looks I will have to manually in all envs - pip doesn't do uninstall

Sure it does.

uninstall*

really? that would be nice, but how?

Although it can't uninstall something that wasn't installed as a package. Are you sure you don't have PIL as a distro package?

pip uninstall foo

mattmcc: haha thanks, i mean via requirements file

Oh, yeah, requiring a package to not be present would be kinda odd.

ugh

how can i replace the ORM, template engine and URL dispatcher?

by not using django :)

it doesn't really make sense to use django, if you are going to replace it all anyway

but... replace the orm by not using it - just use sqlalchemy models or whatever - replace the templating engine by doing your own calls to jinja2 (or something else)

the last is not really possible, i think

i like its stuff like Admin, Auth and ecosystem

oh, the least is the ugliest one

onr: The admin and auth both depend on the template language and ORM.

onr: That doesn't mean _your_ apps have to use it, however.

Nothing stops you from writing Django apps that use SQLAlchemy and Jinja2.

ah, that's horrifying

Of course if you wanted to access anything that the admin was managing from your apps, you'd have to do a lot of duplicate effort.

What's your motivation for avoiding the ORM?

I don't see why theres anything wrong with the ORM..

i like SQLAlchemy more, mattmcc

i just can;t get used to django orm

onr: well you can use it, if you want..

Well, write your own admin using SQLAlchemy, and you're good (the auth app would be trivial to replace)

Although surely there's, like, a Flask admin or something out there.

hmm

I mean, the admin just isn't a good enough reason to use Django when you don't want to use the rest of it.

i think, if anyone want develop in django, for future working in team is not good idea replacing base libraries with others...

i actually like the ecosystem, solves too many things i'd struggle with Flask

Maybe the ORM isn't as bad as you think..

what's so good about sqlalchemy?

i've never used it

Heh.

It's a different philosophy.

is it an orm?

Not really. It's a nearly complete abstraction of SQL in Python.

so it makes using sql not suck

To the extent that that's possible..

i mean writing application with not orm layers is not so effective as with orm :)

Well, it all depends on what you're doing.

mattmcc: i wrote robust reservation system with django orm without any problems... with querysets only

There are plenty of things I handle in the DB and only expose to Django as DB views, or use raw( 0for

raw(), even

I also do a lot of PG-specific stuff that leverages djorm-expressions, djorm-pgarray, etc.

mattmcc: is it a bad idea to design a database schema, populate it, then try to make django work with that ? instead of designing the schema with djangos models.

i feel it would be

MrS1lentcz: Also, there's a difference between what querysets are capable of and what they're good at.

While they're certainly good at being careful about the SQL they generate being optimized, it's also not difficult to generate some pretty horrible queries if you aren't mindful of how queryset filters/annotations map to SQL.

airtonix: That totally depends on the schema you designed.

airtonix: If it's anywhere within driving distance of normalized, you probably wouldn't have a problem creating models for it after the fact.

There are gotchas, however, such as the requirement that all model tables have a single-field PK.

yeah i really mean in terms of long term planning . it kinda reaks of bandaid development

Well, that depends on your background.. :)

lets just say i walked away from that project

so many red flags

Also, a DB that's intended to be consumed by more applications than just Django may not want its schema dictated by Django's expectations.

I know plenty of DBAs that would laugh you out of the room if you suggested that one application gets to tell him how to design his schemas.

how would such a thing be testable ?

wouldn't there always be this unknown aspect to it?

Eh, inspectdb is a decent starting point, but it's far from comprehensive.

It's not good at detecting M2Ms, for example.

mattmcc: i believe you like sqlalchemy too :)

But if you didn't have an individual person who knew enough about SQL and Django to determine if they'd mesh well, then two people (one familiar with the schema and one with Django) would definitely be able to figure it out.

mattmcc: lets hope one of them doesn't get hit by a bus

onr: Honestly, I've never used it beyond a few tiny scripts, years ago.

airtonix: Eh. We only need 'em both long enough to make the determination. ;)

hah

"what do you mean you can't maintain this"?

(I'm saying this as a partner in a company that has a bus factor of 1 for almost all of its products)

"Also, a DB that's intended to be consumed by more applications than just Django may not want its schema dictated by Django's expectations.", major selling point of SQLA over Django ORM

onr: I disagree.

mattmcc: do explain

If you were reading the rest of what I was saying, the ORM can easily accomodate plenty of different schemas, provided they're anywhere near a normalized form.

Barring the single-field PK issue.

lets assume this schema was created in a vacum

ORM is only one part of SQLAlchemy, as you know

and i know lots DBAs recommending SQLA for existing schemas

Sure, because DBAs think in SQL terms, and SQLAlchemy is largely about letting you continue to think in SQL terms.

And Django's ORM is about thinking in object terms.

FWIW, there have been several efforts over the last few years to bridge the ORM to SQLAlchemy.

But it's been largely an academic exercise; there doesn't seem to be enough demand behind it for such a thing to produce a workable mechanism.