Re: Must a Django Database Support Migrations?

[Andrew Godwin]

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 use for
>>> > > testing, and whether or not you want it created. If this is made more
>>> > > general, then testing can be made to not depend on migrations;  with
>>> no
>>> > > migrations, you will need to take care of the test database yourself
>>> --
>>> > > just like you take care of the production database.
>>> > >
>>> > > For Django's own test-suite, tests which need migrations can even be
>>> > > automatically skipped if getting a schema_editor raises a
>>> > > 

Re: Must a Django Database Support Migrations?

[Ivan VenOsdel]

>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 use for
>> > > testing, and whether or not you want it created. If this is made more
>> > > general, then testing can be made to not depend on migrations;  with 
>> no
>> > > migrations, you will need to take care of the test database yourself 
>> --
>> > > just like you take care of the production database.
>> > >
>> > > For Django's own test-suite, tests which need migrations can even be
>> > > automatically skipped if getting a schema_editor raises a
>> > > NotImplementedError; allowing a backend to easily (well, relatively
>> > > easily) pass the suite without implementing migrations.
>> >
>> > This last bit is the critical part. At present, we don't have any
>> > infrastructure to allow tests to be skipped because of a lack of 
>> migration
>> > support. All Django's officially supported backends support migrations, 
>> so
>> > there hasn't been any need to skip any tests.
>> >
>> > The question is whether we should allow for this for third party 
>> backends.
>> >
>> > Historically, the test for a 

Re: Settings: lists or tuples?

[Tom Christie]

Hi Andreas,

  I'm completely in agreement with you that *in theory* using tuples would 
be a (very marginal) improvement. I also happen think that the idea that 
tuples are semantically different from simply being  immutable lists is a 
nonsense - regardless of what a particular section of documentation may or 
may not say, language features are defined solely in terms of their 
behavior, they do not have dreams, hopes and grand philosophical outlooks 
on how they should be used.

  However, the simple case that tuples have a far poorer syntax in python 
than lists, and are *very* easy for beginners to get wrong is a good enough 
reason to prefer the usage of lists consistently.

  ("a string")

  ("a tuple",)

Beginners will not be following your "I notate every (globally available) 
constant sequence in the pattern" advice, and no amount of documentation is 
sufficient to prevent it being a very simple and easy error, that might be 
difficult for a beginner to track down. I think that's a bigger and easier 
trap than intentional assignment.

> accidental assignment to the settings object itself could be easily 
prevented with a __setattr__ method on its class

I'd suggest treating that as a separate issue - perhaps if you or someone 
else came up with a pull request that enforced immutability of the settings 
object that'd be considered on it's own merits. (Note that you could 
perfectly well also deal with making translating list and dict objects into 
immutable objects at *that* point of API, even if they're not in the 
settings module.) I haven't given that any great thought, so expect it 
would have it's own set of obstacles to overcome, but I think it's a 
different issue to the topic at hand here, which is really just about 
settling on an acceptable and consistent style.

> maybe a compromise would be to explicitly note in the docs

I'd be against that as unnecessary fluff - doing one thing in the code and 
recommending another in the docs just introduces noise and uncertainty.

The topic's been discussed more that it really deserves, but I understand 
that it can be frustrating if it feels like your reasoned arguments are 
being brickwalled. I wanted to at least contribute and note that I do agree 
with you in theory, even if practically I'd say that lists throughout is 
consistent, clear, and slightly less likely for developers to get wrong.

Cheers,

  Tom


On Tuesday, 20 January 2015 17:52:51 UTC, Andreas Kahnert wrote:
>
> Just for completness: accidential assignment to the settings object itself 
> could be easily prevented with a __setattr__ method on its class, since 
> django yields on various other places about configuration problems it could 
> not be wrong if the programmer gets noted about an illegal assignment. If 
> everything works fine the method will only get called during startup, so 
> there is no runtime overhead. Simplified example:
> def __setattr__(self, key, val):
> if self.configured:
> raise Exception('settings can not be changed after server startup')
> super(LazySettings, self).__setattr__(key, val)
>
> @Carl Meyer: At the first hand you're right, a thing all programmers 
> should know about (if they call themself so), but he assumed there existed 
> some kind of copy-on-read semantic for the settings, because you get 
> something different when imported from django.conf instead directly and 
> because it's a "magical" lazy object.
>
>
> But since you all seem to like lists that much, maybe a compromise would 
> be to explicitly note in the docs that there is a danger in using lists 
> which can be prevented by tuple usage.
>

-- 
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/063919e0-8d5e-4bfc-b6dc-429885fcfbc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Aymeric Augustin]

On 20 janv. 2015, at 18:52, Andreas Kahnert  wrote:

> But since you all seem to like lists that much, maybe a compromise would be 
> to explicitly note in the docs that there is a danger in using lists which 
> can be prevented by tuple usage.

As explained in my previous email, tuples don’t help much. I’m against stating 
that using tuples is somehow safer.

-- 
Aymeric.




-- 
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/9CD27339-A216-498A-8CCA-65974B4B1737%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Settings: lists or tuples?

[Andreas Kahnert]

Just for completness: accidential assignment to the settings object itself 
could be easily prevented with a __setattr__ method on its class, since 
django yields on various other places about configuration problems it could 
not be wrong if the programmer gets noted about an illegal assignment. If 
everything works fine the method will only get called during startup, so 
there is no runtime overhead. Simplified example:
def __setattr__(self, key, val):
if self.configured:
raise Exception('settings can not be changed after server startup')
super(LazySettings, self).__setattr__(key, val)

@Carl Meyer: At the first hand you're right, a thing all programmers should 
know about (if they call themself so), but he assumed there existed some 
kind of copy-on-read semantic for the settings, because you get something 
different when imported from django.conf instead directly and because it's 
a "magical" lazy object.


But since you all seem to like lists that much, maybe a compromise would be 
to explicitly note in the docs that there is a danger in using lists which 
can be prevented by tuple usage.

-- 
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/ecb152a6-5478-45f1-89b9-3cfc0db27f30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fellow Report - January 16, 2015

[Josh Smeaton]

Definitely. I don't think any of the patches I've written have sat without 
review for longer than a day or two. The turn around on feedback has been 
amazing. I really hope this program is picked up again. Thanks Tim and 
Berker.

- Josh

On Tuesday, 20 January 2015 17:16:39 UTC+11, Anssi Kääriäinen wrote:
>
> You can of course include what I wrote.
>
> A little known fact is that since DuTH I have committed two patches 
> myself, yet authored several patches my self. I have essentially stopped 
> using my commit bit. I did this mostly to test how a workflow where Django 
> contributors do not commit their patches themselves would work. I have to 
> say this has worked extremely well for me. My patches have been reviewed 
> and committed in timely manner. I hope the same is true for other 
> contributors, too.
>
>  - Anssi
>
> On Monday, January 19, 2015 at 7:21:17 PM UTC+2, Tim Graham wrote:
>>
>> Thanks, Anssi. By the way, we are compiling testimonials to help in the 
>> fundraising efforts. Do you mind if we include those two sentences from 
>> you? (feel free to add a couple more sentences if you like). If anyone else 
>> would like to share one, please send them my way. I am especially 
>> interested in non-core team members perspective on the program. Also, feel 
>> free to share any general feedback (positive or negative) -- even if you 
>> don't want it posted as a testimonial on the fundraising page. Thank you!
>>
>> On Monday, January 19, 2015 at 5:20:49 AM UTC-5, Anssi Kääriäinen wrote:
>>>
>>> On Friday, January 16, 2015 at 10:19:15 PM UTC+2, Tim Graham wrote:

 Here’s my final report for the 3 month fellowship pilot. I hope the 
 DSF’s fundraising efforts will be successful and I’ll have an opportunity 
 to "be back" soon. :-)

>>>
>>> From my point of view the fellowship pilot has been a huge success. The 
>>> amount of tickets and patches worked on during the pilot is astounding.
>>>
>>> A very big thank you, and lets hope the fundraising program is 
>>> successful.
>>>
>>>  - Anssi
>>>
>>

-- 
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/e1fca5db-f1d2-48dc-9905-391723803cb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.