Re: Must a Django Database Support Migrations?

[Andrew Godwin]

Aha! Then, I would suggest redesigning MigrationRecorder to only make the
table when an actual recording operation is done, and have it swallow the
table not existing as "no migrations applied" the rest of the time, if
people think that seems sensible.

Andrew

On Thu, Jan 22, 2015 at 10:44 AM, Markus Holtermann <
i...@markusholtermann.eu> wrote:

> Hey,
>
> as soon as the MigrationRecorder is used there is a call to
> "ensure_schema" that forces the creation of the migration table. The
> runserver command (among others?) checks for unapplied migrations and thus
> creates the migration table.
>
> /Markus
>
> On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin wrote:
>>
>> Hi Ivan,
>>
>> I'm not sure what you're asking here - are you asking to have a way to
>> not have Django create the migrations recording table? I was under the
>> impression that it was only created when migrate was run (at least, that
>> was my original intention) so if you're managing your own schema just don't
>> run migrate. Is there something else that's not working right, or is that
>> being made too optimistically?
>>
>> Andrew
>>
>> On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel  wrote:
>>
>>> From Andrew: "The only extra thing it would achieve is not having Django
>>> record migrations in the django_migrations table"
>>>
>>> The Django Users thread on how to keep this table from being created
>>> seemed to result in the 'solution' being either to stay with 1.6 or comment
>>> the relevant lines in the Django code base. Is there really no other way?
>>>
>>> I love the new migrations facilities in Django 1.7 and was a contributor
>>> to the kickstarter but please keep in mind that many legacy DB projects are
>>> not avoiding migrations because they want to. IMO it's usually because they
>>> are forced to for some (usually political) reason where they don't have
>>> control over the schema. Forcing a perpetually empty django_migrations
>>> table pretty much locks out those users.
>>>
>>> I see that people are worried about encouraging the non-use of
>>> migrations but might I suggest following the Zen of Python and making
>>> migrations the "one obvious way to do it" and turning them off the not
>>> obvious way.
>>>
>>> Ivan
>>>
>>> On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin wrote:

 My thoughts in brief on this:

  - Database backends don't support migrations - they support schema
 alteration via SchemaEditor. This could be used separately from migrations
 if something wants it, and is meant to be an API on its own, so the backend
 is not the place to say if you want migrations or not.

  - There is some merit to the ability to turn off migrations on a
 per-backend basis, via a DATABASES setting, but bear in mind that routers
 already let you do this (with the allow_migrate method). The only extra
 thing it would achieve is not having Django record migrations in the
 django_migrations table, but it also looks like it would be useful for
 tests if you hadn't written that part yet.

  - I feel like a DB backend should at least implement SchemaEditor even
 if it returns NotImplementedError for most of the endpoints; even in the
 weirdest relational system, you can still manage create/delete model
 without too much difficulty.

  - Bear in mind that the plan is to remove DatabaseCreation entirely in
 favour of SchemaEditor in a few releases' time (and backends are more than
 welcome to make DatabaseCreation use SchemaEditor behind the scenes if they
 want), so at that point if you don't implement it the backend is only ever
 good for querying, which to me feels like an incomplete backend.

  - I'm not sure what the future of ./manage.py sqlall is, but it's
 going to have to be ported to SchemaEditor in future anyway, so it's only
 useful in the transition.

 Looking at the discussion, I think the best thing to do is:

  - Make the schema and migrations test skip if
 connection.schema_editor() raises a NotImplementedError (not too hard, we
 can implement connection.has_schema_editor as a boolean to switch on)
  - Provide some way to skip the "creating models" part of test setup,
 so SchemaEditor is never needed during it

 I still think all the current third-party backends should be able to
 provide a partial SchemaEditor implementation though, as at minimum they
 all have the DatabaseCreation code in place to make new models. Bear in
 mind that the ./manage.py sqlmigrate command lets you turn migrations into
 SQL scripts to send to your DBA (and many DBAs appreciate having some SQL
 they can work from - I know ours do), so having the ability to make that
 SQL is useful even if Django never runs it.

 Andrew


 On Wed, Jan 22, 2014 at 10:10 AM, Shai Berger 
 

Re: Must a Django Database Support Migrations?

[Markus Holtermann]

Hey,

as soon as the MigrationRecorder is used there is a call to "ensure_schema" 
that forces the creation of the migration table. The runserver command 
(among others?) checks for unapplied migrations and thus creates the 
migration table.

/Markus

On Wednesday, January 21, 2015 at 12:36:47 AM UTC+1, Andrew Godwin wrote:
>
> Hi Ivan,
>
> I'm not sure what you're asking here - are you asking to have a way to not 
> have Django create the migrations recording table? I was under the 
> impression that it was only created when migrate was run (at least, that 
> was my original intention) so if you're managing your own schema just don't 
> run migrate. Is there something else that's not working right, or is that 
> being made too optimistically?
>
> Andrew
>
> On Tue, Jan 20, 2015 at 2:44 PM, Ivan VenOsdel  > wrote:
>
>> From Andrew: "The only extra thing it would achieve is not having Django 
>> record migrations in the django_migrations table"
>>
>> The Django Users thread on how to keep this table from being created 
>> seemed to result in the 'solution' being either to stay with 1.6 or comment 
>> the relevant lines in the Django code base. Is there really no other way?
>>
>> I love the new migrations facilities in Django 1.7 and was a contributor 
>> to the kickstarter but please keep in mind that many legacy DB projects are 
>> not avoiding migrations because they want to. IMO it's usually because they 
>> are forced to for some (usually political) reason where they don't have 
>> control over the schema. Forcing a perpetually empty django_migrations 
>> table pretty much locks out those users.
>>
>> I see that people are worried about encouraging the non-use of migrations 
>> but might I suggest following the Zen of Python and making migrations the 
>> "one obvious way to do it" and turning them off the not obvious way.
>>
>> Ivan
>>
>> On Wednesday, January 22, 2014 at 5:40:35 AM UTC-6, Andrew Godwin wrote:
>>>
>>> My thoughts in brief on this:
>>>
>>>  - Database backends don't support migrations - they support schema 
>>> alteration via SchemaEditor. This could be used separately from migrations 
>>> if something wants it, and is meant to be an API on its own, so the backend 
>>> is not the place to say if you want migrations or not.
>>>
>>>  - There is some merit to the ability to turn off migrations on a 
>>> per-backend basis, via a DATABASES setting, but bear in mind that routers 
>>> already let you do this (with the allow_migrate method). The only extra 
>>> thing it would achieve is not having Django record migrations in the 
>>> django_migrations table, but it also looks like it would be useful for 
>>> tests if you hadn't written that part yet.
>>>
>>>  - I feel like a DB backend should at least implement SchemaEditor even 
>>> if it returns NotImplementedError for most of the endpoints; even in the 
>>> weirdest relational system, you can still manage create/delete model 
>>> without too much difficulty.
>>>
>>>  - Bear in mind that the plan is to remove DatabaseCreation entirely in 
>>> favour of SchemaEditor in a few releases' time (and backends are more than 
>>> welcome to make DatabaseCreation use SchemaEditor behind the scenes if they 
>>> want), so at that point if you don't implement it the backend is only ever 
>>> good for querying, which to me feels like an incomplete backend.
>>>
>>>  - I'm not sure what the future of ./manage.py sqlall is, but it's going 
>>> to have to be ported to SchemaEditor in future anyway, so it's only useful 
>>> in the transition.
>>>
>>> Looking at the discussion, I think the best thing to do is:
>>>
>>>  - Make the schema and migrations test skip if 
>>> connection.schema_editor() raises a NotImplementedError (not too hard, we 
>>> can implement connection.has_schema_editor as a boolean to switch on)
>>>  - Provide some way to skip the "creating models" part of test setup, so 
>>> SchemaEditor is never needed during it
>>>
>>> I still think all the current third-party backends should be able to 
>>> provide a partial SchemaEditor implementation though, as at minimum they 
>>> all have the DatabaseCreation code in place to make new models. Bear in 
>>> mind that the ./manage.py sqlmigrate command lets you turn migrations into 
>>> SQL scripts to send to your DBA (and many DBAs appreciate having some SQL 
>>> they can work from - I know ours do), so having the ability to make that 
>>> SQL is useful even if Django never runs it.
>>>
>>> Andrew
>>>
>>>
>>> On Wed, Jan 22, 2014 at 10:10 AM, Shai Berger  
>>> wrote:
>>>
 On Wednesday 22 January 2014 16:26:50 Russell Keith-Magee wrote:
 > On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger  
 wrote:
 > >
 > > B) Allow the test suite to run on an existing schema. The Oracle 
 backend
 > > already does this (badly) -- its six specific TEST_* parameters are
 > > awkwardly named, but allow you to say exactly which schema to 

Re: Settings: lists or tuples?

[Andreas Kahnert]

Hi again,
Well, I can acknoledge that your reasons for list (beginner friendly) are 
as good as my reasons for tuples (seems to be more logical choice for 
things that are static). To say it in other words, my idea was simply: Use 
tuples and the programmer will know that these arn't ment to be altered at 
runtime.
But this reformulation made me thought of the docs comment I suggested. And 
probably the docs should clearly state (in 
https://docs.djangoproject.com/en/1.6/topics/settings/#creating-your-own-settings):
The settings are solely for configuration of django and its components / 
extensions, but not for initial/default values of your application, because 
the settings have to be imported in a special way (through django.conf; 
sidenote - it states there: "For settings that are sequences, Django itself 
uses tuples, rather than lists, but this is only a convention")
At the end, this was what the confusion between my colleages caused and 
what his true programming-theoretical mistake was. (nowadays all of our 
apps have a definitions.py module)

I hope this is something all could agree with and ends the discussion I 
caused.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b243c053-667d-443a-8ec4-c586ed102d63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.