Ticket #7220: Last_login in django.contrib.auth should have null=True

[Chris Wilson]

Hi all,

Regarding ticket #7220 , this 
is bugging me at the moment. I share a database with a non-django app, and 
need to insert test data, and having to set last_login to something is 
annoying.


I understand @SmileyChris' point that there are no migrations (yet) in 
core, so this is a bit difficult to fix. However I have a proposal:


I tried to fix this myself by overriding last_login in our custom user 
class, and got this error:


FieldError: Local field 'last_login' in class 'IschoolUser' clashes
with field of similar name from base class 'AbstractUser'

I propose that we allow overriding fields, with a safety mechanism: 
it's required to add an "override=True" attribute to the field. Users who 
want to change an existing field must add this attribute to the new 
field in their subclass, and manage any migrations or database 
changes themselves. That removes the responsibility from Django to manage 
it, which currently it can't.


What do you say? If this sounds like a good idea I can work up a patch. 
That would enable a sensible workaround for ticket #7220 (override the 
field and add south to your project) which isn't currently possible.


Cheers, Chris.
--
Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK

Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Ticket #7220: Last_login in django.contrib.auth should have null=True

[Marc Tamlyn]

There's actually quite a good reason why you can't override model field in
Subclasses in the general case - the parent model actually creates a table
of its own. In the case of abstract parents this should be possible, even
without an override flag. I'm not sure if there are some difficulties in
tracking whether the field was defined in an abstract model or not, which
may explain why it is currently not possible, but I think this would be the
correct flavour of patch to allow you to do what you think you should be
able to.

In the mean time, I can only suggest copying and pasting the AbstractUser
class...
On 1 Jun 2013 09:13, "Chris Wilson"  wrote:

> Hi all,
>
> Regarding ticket #7220 
> >,
> this is bugging me at the moment. I share a database with a non-django app,
> and need to insert test data, and having to set last_login to something is
> annoying.
>
> I understand @SmileyChris' point that there are no migrations (yet) in
> core, so this is a bit difficult to fix. However I have a proposal:
>
> I tried to fix this myself by overriding last_login in our custom user
> class, and got this error:
>
> FieldError: Local field 'last_login' in class 'IschoolUser' clashes
> with field of similar name from base class 'AbstractUser'
>
> I propose that we allow overriding fields, with a safety mechanism: it's
> required to add an "override=True" attribute to the field. Users who want
> to change an existing field must add this attribute to the new field in
> their subclass, and manage any migrations or database changes themselves.
> That removes the responsibility from Django to manage it, which currently
> it can't.
>
> What do you say? If this sounds like a good idea I can work up a patch.
> That would enable a sensible workaround for ticket #7220 (override the
> field and add south to your project) which isn't currently possible.
>
> Cheers, Chris.
> --
> Aptivate | http://www.aptivate.org | Phone: +44 1223 967 838
> Future Business, Cam City FC, Milton Rd, Cambridge, CB4 1UY, UK
>
> Aptivate is a not-for-profit company registered in England and Wales
> with company number 04980791.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 
> django-developers+unsubscribe@**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?hl=en
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

SQL from Models

[Josueh Machado]

hi!

is possible generate the SQL ("create table/index/ ") in hardcode?

example:

class Book(models.Model):
title = models.CharField(...)
price = models.DecimalField(...)

print django_generate_sql_model( Book ) # <---here ?? anyway? idea? exists?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: SQL from Models

[Florian Apolloner]

Hi,

this list is about the development of Django itself, please take your 
question to django-users.

Thanks,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: SQL from Models

[Josueh Machado]

ok

thk!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing generated SQL under different backends

[Shai Berger]

Hi again,

On Wednesday 29 May 2013, Anssi Kääriäinen wrote:
> 
> An example of what I think would be the ultimate solution:
> 
> class TestWeirdJoinConditions(TestCase):
> def test_something(self):
> ...
> If it turns out MySQL is having problems with this test, you could
> then have a class somewhere in the backend:
> 
> from queries.tests import TestWeirdJoinConditions
> 
> class TestWeirdJoinConditionsMySQL(TestWeirdJoinConditions):
>@skip
>def test_something(self):
>...
> 

I think this can be done along the following lines: In the backend, include a 
module for overriding tests (it could be a special module for overrides, or 
just a regular test module) with:

from queries import tests as queries_tests

@override_parent(queries_tests)
class TestWeirdJoinConditions(queries_tests.TestWeirdJoinConditions):
@skip
def test_something(self):
...

With override_parent being something like 

def override_parent(module):
def override(cls):
parent = cls.__bases__[0]
setattr(module, parent.__name__, cls)
return cls
   return override

[perhaps the module argument can be removed, but the __module__ property on 
classes is just the module name, and I'm not sure it's unique enough].

Then, we just need to make sure that the test runner imports these modules 
before it collects test cases.

> Assuming this could technically work (that is, there is a way to use
> only the MySQL version of the class) it should be possible for a
> backend to alter everything about the test class if need be, and the
> test class doesn't need to know anything about the backend. So, no
> dependency from queries tests to possible 3rd party backends. OTOH
> this adds a dependency from backend to arbitrary test classes...
> 

Just from backend tests to general tests. I don't see a problem there.

> Just moving some tests to backends is a possibility. The problem is
> that if some third party backend has problems with a test we will need
> to move that test to backends without having anything in core
> requiring that. This creates a weird dependency between Django and 3rd
> party backends. Of course, we have that dependency already. For
> example some tests use IntegerField(primary_key=True) instead of
> AutoField, the reason is that SQL Server doesn't like manually setting
> AutoField values.
> 

The point this raises is, that sometimes modifying the test class is not 
enough, and we'd need to modify the test app. I'm not sure if this can be done 
along the same lines.

> > > For 3rd party backend support in general: My opinion is that we should
> > 
> > > include them all in core. The rules would be:
> > By "them", do you mean 3rd party backend tests or the entire 3rd party
> > backend?
> 
> Whole backend. This could work if the idea is that core doesn't
> guarantee that all backends are working all the time. The only
> guarantee is that core tries to find a maintainers for backends. If
> nobody is found, then the backend simply doesn't work.
> 

This sounds like a very good plan if you think mostly on django-mssql or the 
core Oracle backend. It sounds a little less attractive if you add the two 
active forks of django-pyodbc, the fledgling Firebird backend, or the wholly-
IBM-owned DB2 backend -- of which, as far as I'm aware, none of the developers 
are very active on this mailing list.
(For the record: I have been contributing significantly to the MSSQL backend of 
South, and am interested in having an MSSQL backend in core).

> This is the way device driver development is done in Linux. Basically,
> if nobody cares enough to fix a broken driver, then it isn't a
> problem. This turns out to work really, really well.
> 

There is a difference in the development organization -- Linux development is 
hierarchic, with "lieutenants" each responsible for their own area of the 
kernel; which makes it much easier to make someone responsible for a set of 
device drivers, but nothing more.

> Interestingly something like this has already happened to Oracle GIS.
> It was broken for a long time in 1.4 release (you couldn't save
> anything IIRC). Then Jani Tiainen needed the GIS functionality, wrote
> a patch and now GIS is in mostly working state. It still doesn't pass
> the GIS tests, but that doesn't seem to be a problem in practice.
> 

(I am probably one of the obvious candidates to take care of this; alas, I am 
not too well versed in GIS, and find other improvements in the Oracle backend 
of higher priority. If anyone wants to work on it, I will collaborate as best 
I can).

> Based on how things work in Linux I think similar arrangement should
> work in Django, too. The crucial point is that adding a new backend to
> Django's code base must not add any significant amount of work to core
> committers. If the idea is to add backends to Django's code base and
> have any sort of core-committer guarantee that all backends work all
> the time (that is, you need to run tests ag

Re: Proposal: OpenLayers.js and shipping it in django.contrib.gis statics

[Kamil Gałuszka]

Hi,

Thanks for explanation. I think your reasoning make sense. 

Cheers
Kamil Gałuszka

On Monday, May 27, 2013 10:48:35 AM UTC+2, Claude Paroz wrote:
>
>
>
> Le lundi 27 mai 2013 07:38:54 UTC+2, Carl Meyer a écrit :
>>
>> Hi Kamil, 
>>
>> On 05/26/2013 05:39 PM, Kamil Gałuszka wrote: 
>> > Hi Django developers! 
>> >   
>> > This is my first time here posting, so if I'm wrong please forgive me 
>> :) 
>> > I wanna learn as much as possible about django development process from 
>> > you guys! 
>> > Thank you all for inspiring time on DjangoCon.eu sprints ! 
>> > 
>> > I'm writing because I'm concerned about OpenLayers that are used in 
>> > django.contrib.gis.admin. For now JS of OpenLayers is shipped with 
>> > external url from openlayers hosting. 
>> > 
>> > There are some drawback of this situation and it's causing bugs in 
>> > specific circumstances. For example if you are using Chrome browser and 
>> > your website is using https all non https javascript are blocked by 
>> > default. So widget in django admin isn't rendering and it's broken (I 
>> > think that should be considered as a bug and possibility of security 
>> > problems if someone switch openlayer.js on external hosting). 
>> > 
>> > I think the best approach to that problem is that we should ship 
>> > OpenLayer.js in Django statics. OpenLayers documentation is encouraging 
>> > to ship in applications own builds of this library. To read more: 
>> > http://docs.openlayers.org/library/deploying.html 
>> > 
>> > I have question is this approach good for Django (to actually compile 
>> > own build of OpenLayer and ship it in statics) and is this change can 
>> be 
>> > possible place of breaking something with backward compatibility. 
>> > 
>> > Things in my mind to consider: 
>> > 1) With every next Django release I think there should be building of 
>> > most actual OL. 
>> > 2) Shipping OL actually should be optional and documented in docs. 
>> > 
>> > If there isn't any problem with that approach I'm ready to implement 
>> this. 
>>
>> I'm not familiar with any history in this area (so I'll defer to anyone 
>> who knows a good reason why we do it the way we do), but it makes sense 
>> to me that it would be better to ship an OpenLayers.js build than link 
>> to it externally, for security and reliability reasons. 
>>
>
> I was not there at the time of this design decision either, however I can 
> imagine that including a lib weighing more than 700 Ko in every Django 
> release just for a contrib app is not something to be taken lightly.
>
> Note that Django 1.6 will introduce some new template-based widgets for 
> GeoDjango, so changing the OpenLayers source is as simple as subclassing 
> the new BaseGeometryWidget and redefining its Media class.
>
> Claude
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.