Re: Keeping apps without migrations?

On Thu, Aug 27, 2015 at 10:25 PM, Anssi Kääriäinen wrote: > Could we allow applications to have fake migration files? I'm thinking > of something like operations.AllModelsUpdated(). After this operation > is ran, Django will use the present models for that app. You could > place this as your last

Re: CHECK Constraints and migrations

> making lookups and transforms work on Python side, too. Then, when you supply a check "ends_after_starts", we could both add it as a database level constraint, and also validate the constraint on Python side when altering data. Yep, that's my plan. Just have to figure out the migration stuff fi

Re: CHECK Constraints and migrations

I recall another idea that would work very well with model level Q-object based checks: making lookups and transforms work on Python side, too. Then, when you supply a check "ends_after_starts", we could both add it as a database level constraint, and also validate the constraint on Python side wh

Re: Django SQL templates

The django-refsql package implements a limited subset of this. You can reference to columns in an existing ORM query using {{field}} syntax. For example: User.objects.annotate(ref=RefSQL("case when {{best_friend__age}} > {{age}} then 'older' else 'younger' end")) This would also set up a join to Us

Re: Keeping apps without migrations?

Could we allow applications to have fake migration files? I'm thinking of something like operations.AllModelsUpdated(). After this operation is ran, Django will use the present models for that app. You could place this as your last migration, and run direct SQL in previous migrations (or use some c

Re: CHECK Constraints and migrations

No, fields can't really specify any of the SQL used to make/update/delete them (partially as the SQL is heavily dependent on the database backend, and Django traditionally has the fields as the database-agnostic bit and the backends as the specific bit). All they can do is supply a db_type, which h

Re: CHECK Constraints and migrations

That's too bad. I don't think it's really worth it unless the experience works seamlessly, because if I'm going to write a migration manually I might as well just use a RunSQL. I did have another slightly hacky idea that might work. Can custom Fields specify the operations used to create and dr

Re: CHECK Constraints and migrations

That's the approach I've used: either have a migration operation that you can run (included in a 3rd party or local app), or a management command that generates a migration file with the relevant custom operations. Matt. On Friday, August 28, 2015 at 11:37:55 AM UTC+9:30, Andrew Godwin wrote: >

Re: CHECK Constraints and migrations

Hi Gavin, Hooking into the migration autodetector is currently not really possible - it's quite inextensible, which is something I'd love to get ironed out in the long term but isn't really possible right now to modify it from third-party code. You can, however, supply custom migration Operation

CHECK Constraints and migrations

I'm interested in writing a third-party app that allows users to declaratively write check constraints and have them automatically be added and removed by migrations. I'm envisioning being able to attach a list of Q objects to your model, something like: class Meta: checks = [

Re: Django SQL templates

Marcin is correct. The plan is to extend the concept of expressions so that you have more control over crafting your own queries. What we have: - select expressions - aggregation expressions - case/when - order by - where expressions (lookups/transforms) - column expressions (representing model

Re: Adding more __repr__() methods

Generally, I'm a fan of adding repr methods. I don't think we should run around finding all the places they might be useful and adding them, but if someone is to put forward patches where they've noticed a benefit, we should encourage that. I'm not sure I fully understand your concerns though.

Re: Keeping apps without migrations?

I think I agree with Markus that we do not yet have a good enough performance story to make migrations mandatory. If you want to ditch them and do your own database management, we should let you - which we could do with some kind of MIGRATIONS_MODULES opt-out that basically sets everything to pseud

Re: Keeping apps without migrations?

The general benefit of *not* having migrations is the incredible better performance to setup the tables. Especially for larger projects this is something we should at least keep in mind (see https://code.djangoproject.com/ticket/24743). I spent a fair bit of time on the issue and have not yet f

Re: Django SQL templates

On Thursday, August 27, 2015 at 9:43:40 PM UTC+2, Alexey Zankevich wrote: > > For such cases it's great to have DSL to build SQL queries, but it's a big > question how low- or high-level language should be. > Take a look at SQLAlchemy`s expressions API. The ORM is built top of it. I think that

Django SQL templates

Hi all, After reading future of QuerySet.extra() discussion, I was thinking about the current custom ways to tweak SQL queries in Django. Firstly, it was the current .extra method, which everyone likely wants to get rid o

Re: Django Admin New Look

Carl pinged me in #django-dev to say that the technical board says it's ok to go ahead with dropping IE8 support in admin for 1.9. Three +1s and two +0s. The +0s were due to feeling that: a) IE isn't as dead as in some places as it is in the Valley b) the advantages gained by dropping support are

Re: Keeping apps without migrations?

It would be great if we could decide this by next Friday (September 4) or so, so that we have some time to do the necessary implementations and testing before alpha. (For example, running manage.py test without migrations currently gives "no such table ...". It would be nice to give a friendlie

Re: How to disable system check framework?

On Thursday, August 27, 2015 at 3:09:06 PM UTC+2, Tim Graham wrote: > > I created a ticket and pull request for the silencing of error/critical > messages: > https://code.djangoproject.com/ticket/25318#ticket > https://github.com/django/django/pull/5197 > >> >> Thanks, Tim! Marcin. -- You r

Adding more __repr__() methods

I'd like to ask for other opinions on this pull request which adds more __repr__() methods: https://github.com/django/django/pull/5059 Some concerns: * Adding things that aren't part of the class (e.g. settings) seems questionable to me. * There is a chance to leak sensitive data in __repr__ a

Re: How to disable system check framework?

I created a ticket and pull request for the silencing of error/critical messages: https://code.djangoproject.com/ticket/25318#ticket https://github.com/django/django/pull/5197 On Tuesday, August 25, 2015 at 11:03:18 AM UTC-4, Carl Meyer wrote: > > On 08/25/2015 08:57 AM, Marcin Nowak wrote: > >