Django 1.7 - data migration which needs content types populated
Hi,
I'm migrating an app from Django 1.6 to 1.7 and I need to create a data
migration to load some initial data.
Some of the migrations requires that Content Types are populated in order
to create some objects with Generic Relations.
# models.py
class TincHost(models.Model):
name = models.CharField(max_length=32, unique=True)
content_type = models.ForeignKey(ContentType)
object_id = models.PositiveIntegerField()
content_object = generic.GenericForeignKey()
class Server(models.Model):
name = models.CharField(max_length=256, unique=True)
tinc = generic.GenericRelation(TincHost)
# migrations/0002_initial_data.py
def create_tinc_server(apps, schema_editor):
# ...
TincHost.objects.create(content_type=ctype, object_id=1, name='server')
class Migration(migrations.Migration):
dependencies = [
('contenttypes', '0001_initial'),
('myapp', '0001_initial'),
]
operations = [
migrations.RunPython(create_tinc_server)
]
This page[1] suggests adding this code to the migration:
from django.contrib.contenttypes.management import update_all_contenttypes
update_all_contenttypes()
It works, but there is a better or standar way to achieve that?
[1] http://stackoverflow.com/q/26464838/1538221
Thanks!
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/5b2d48da-41b3-404d-abff-6c17c017aa10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
possible bug - CharField accepts string as max_length
Hi, I think that I have found a bug on the system check: it accepts a string as value for CharField.max_length argument. It happens only if the string can be converted to int (e.g. max_length='16'). Otherwise shows fields.E121 error (e.g. max_length='foo'). from django.db import models class Foo(models.Model): bar = models.CharField(max_length='16') # following code raises an Exception obj = Foo(bar='lorem ipsum') obj.clean_fields() Traceback: >>> obj = Foo(bar='lorem ipsum') >>> obj.clean_fields() Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.4/dist-packages/django/db/models/base.py", line 1167, in clean_fields setattr(self, f.attname, f.clean(raw_value, self)) File "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", line 589, in clean self.run_validators(value) File "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", line 541, in run_validators v(value) File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", line 280, in __call__ if self.compare(cleaned, self.limit_value): File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", line 319, in compare = lambda self, a, b: a > b TypeError: unorderable types: int() > str() Best regards, Santiago -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7f920d86-1657-4922-a6a6-603ab0f846a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: possible bug - CharField accepts string as max_length
Yes, it is.
user=> \d+table django_foo;
Table "public.grd_device"
Column | Type | Modifiers | Storage | Stats target |
Description
++---+--+--+-
id | integer| not null default
nextval('django_foo_id_seq'::regclass) | plain | |
bar| character varying(16) | not null | extended | |
El lunes, 18 de mayo de 2015, 9:37:31 (UTC+2), aRkadeFR escribió:
>
> Hey,
>
> And is the CharField is really 16 char max_length in DB if
> you specifiy a string '16'?
>
> On 05/15/2015 10:53 AM, Santiago L wrote:
>
> Hi,
>
> I think that I have found a bug on the system check: it accepts a string
> as value for CharField.max_length argument.
>
> It happens only if the string can be converted to int (e.g.
> max_length='16'). Otherwise shows fields.E121 error (e.g. max_length='foo').
>
> from django.db import models
>
> class Foo(models.Model):
> bar = models.CharField(max_length='16')
>
>
> # following code raises an Exception
> obj = Foo(bar='lorem ipsum')
> obj.clean_fields()
>
>
> Traceback:
> >>> obj = Foo(bar='lorem ipsum')
> >>> obj.clean_fields()
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/local/lib/python3.4/dist-packages/django/db/models/base.py",
> line 1167, in clean_fields
> setattr(self, f.attname, f.clean(raw_value, self))
> File
> "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py",
> line 589, in clean
> self.run_validators(value)
> File
> "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py",
> line 541, in run_validators
> v(value)
> File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py",
> line 280, in __call__
> if self.compare(cleaned, self.limit_value):
> File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py",
> line 319, in
> compare = lambda self, a, b: a > b
> TypeError: unorderable types: int() > str()
>
> Best regards,
>
> Santiago
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com .
> To post to this group, send email to django...@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/7f920d86-1657-4922-a6a6-603ab0f846a3%40googlegroups.com
>
> <https://groups.google.com/d/msgid/django-users/7f920d86-1657-4922-a6a6-603ab0f846a3%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> aRkadeFR
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/cf3c4d3e-e1be-4ed8-88e9-8bd2851676e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: possible bug - CharField accepts string as max_length
El lunes, 18 de mayo de 2015, 12:33:21 (UTC+2), James Schneider escribió:
>
> I'd post a bug report. Based on the behavior you've outlined (haven't
> looked at the Django source), there may have been some oversight on the
> duck typing that python performs. It sounds like the migration package is
> taking advantage of duck typing (since 16 == int('16')), but the validation
> functions are making comparisons on the assumption that 16 is an int, not a
> str.
>
FYI, bug report https://code.djangoproject.com/ticket/24818
Thanks all for your replies!
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/81126070-faaa-479f-8069-7e13e3f6b9ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Alternative to django-registration (unmaintaned since September 2013)
Hi, Some weeks ago I noticed that django-registration is not longer maintained by its creator: quoting https://bitbucket.org/ubernostrum/django-registration/wiki/Home > django-registration > I stepped down as maintainer of this application in September 2013. Pull > requests, issues and comments sent to this repository will be ignored. As I'm currently using this app in my project, I wonder if there is any alternative for django-registration? Maybe someone knows about a fork. Besides that, I found a related issue report (rejected because is not the good place to ask this question, but relevant anyway)[2] [2] https://code.djangoproject.com/ticket/13164 Thanks! Best regards, Santiago -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/bdba6d6b-b20d-4de1-836e-3bcb4bf4c808%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Alternative to django-registration (unmaintaned since September 2013)
El sábado, 19 de julio de 2014 02:17:24 UTC+2, Russell Keith-Magee escribió: > > > On Fri, Jul 18, 2014 at 8:31 PM, Santiago L > wrote: > >> Hi, >> >> Some weeks ago I noticed that django-registration is not longer >> maintained by >> its creator: >> >> quoting https://bitbucket.org/ubernostrum/django-registration/wiki/Home >> > django-registration >> > I stepped down as maintainer of this application in September 2013. Pull >> > requests, issues and comments sent to this repository will be ignored. >> >> >> As I'm currently using this app in my project, I wonder if there is any >> alternative for django-registration? Maybe someone knows about a fork. >> > > I'm not aware of an active fork. If you're looking to step into open > source contribution, this would be a good project to adopt - the code base > is stable, so the management overhead should be relatively low. > I like the idea about contributing and get in charge of a fork, but I'm not sure about my availability... > > >> Besides that, I found a related issue report (rejected because is not the >> good >> place to ask this question, but relevant anyway)[2] >> >> [2] https://code.djangoproject.com/ticket/13164 >> >> Because there's no single answer to the question. > > Authentication is a topic that is hard to get right, and there's a very > limited number of "right" answers. Passwords *must* be done well, or you > risk vulnerability, and what constitutes "well" requires considerable > expertise. > > However, the requirements for registration and signup will vary between > projects, and will depend on project requirements. Some projects will need > a fully verified personal profile before you can continue; some only > require a verified email address; some will allow an email address, but > allow later verification, and some will require completely anonymous > profiles that are filled in at a critical point in workflow (e.g., at > checkout in an e-commerce site). > > There's also nothing especially technically complex about these workflows > - unlike Authentication, there aren't any real land mines that could lead > to vulnerabilities (beyond those that are inherent in building *any* web > page). > > So, the Django project has made the decision to keep Authentication as a > core piece of functionality, but keep registration as a third-party thing. > This means that the wider community can contribute alternate approaches. It > also means that the core team isn't a bottleneck on progress - > django-regsistration has it's own release cycles, bug tracking processes, > and so on. > > This arrangement has worked well for 8 years; it's only because James has > stepped down and nobody has volunteered to take over that a problem now > exists. > > Thanks for your explanation!! -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a8450ee8-96a0-4a1e-9071-2740544e5533%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
