Re: Support of django 3.2

[Markus Holtermann]

Yes, until April 2024: https://www.djangoproject.com/download/

On Tue, Nov 1, 2022, at 3:54 PM, Lakshyaraj Dash wrote:
> Is django 3.2 still supported?
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/CAF7qQgB-d2%3DjpzQnNWZOgG718ZXX6ow%3D-2HaXayabhDQf6Arog%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d6595833-9dd5-48b9-8c00-62e74f05f4e7%40betaapp.fastmail.com.

Re: migrations not created for foreign key when primary key type is changed

[Markus Holtermann]

This is expected and by design. Because in the model where you define the 
foreign key, you also don't define its type. The type is automatically resolved 
through the column type from the target model.

Cheers
Markus 

On Fri, Sep 2, 2022, at 10:39 AM, Manasvi Dobariya wrote:
> I have default primary key in the model which is being referenced as foreign 
> key in another model. Now, when I change this primary key type from AutoField 
> to BigAutoField, migrations for only primary keys are being generated no 
> migration for foreign key is generated. However, when I apply the migration 
> generated for primary key, foreign key type also gets changed from int to 
> bigint in postgres database. Is it expected that migrations for foreign key 
> will not get generated? 
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/a4cbdf90-bd62-46a7-9657-1c7ba39509c2n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-users/a4cbdf90-bd62-46a7-9657-1c7ba39509c2n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e7f4affd-a1e2-4c71-bcf0-175d0f700303%40beta.fastmail.com.

Re: Django backend for Psycopg 3

[Markus Holtermann]

Hi Daniele,

wow, these are wonderful news! Thank you for all your time on psycopg2 and now 
3!

>From where I'm standing, I agree, having the psycopg3 Django backend as an 
>external package for now sounds good. It's much easier to keep updated and 
>maintained, without having to go through all of Django's hoops.

As for the changes to Django, I guess we should at least merge those changes 
that remove the requirement of having psycopg2 installed, even though it's 
unused. So, namely in the contrib.postgres area. Instead, we should try to use 
either psycopg2 or psycopg3.

Cheers,

Markus

On Tue, Aug 3, 2021, at 2:01 PM, Daniele Varrazzo wrote:
> 
> Hello,
> 
> I have maintained psycopg2 in the last >10 years and in the last year I 
> have been developing a new adapter, Psycopg 3, using the experience 
> made so far in the area of connecting Python to PostgreSQL.
> 
> https://www.psycopg.org/psycopg3/
> https://www.psycopg.org/psycopg3/docs/
> 
> One of the goals of the project is to make upgrading from psycopg2 
> easy, so the project retains the familiar DBAPI 2.0 interface. However, 
> in order to use more advanced PostgreSQL features (prepared statements, 
> binary parameters...) it makes use of server-side parameters binding, 
> which here and there have slightly different behaviour from the 
> client-side binding used in psycopg2.
> 
> I have written a first cut of a Django backend for PostgreSQL based on 
> Psycopg 3, which is available as an external module at 
> <https://github.com/dvarrazzo/django-psycopg3-backend>. Using the 
> Django test suite was immensely helpful to find the missing features 
> and the different behaviour: thank you very much! As much as I could, I 
> have changed the adapter to make default choices to reproduce the 
> behaviour of psycopg2. However there are a few cases where the 
> PostgreSQL-related code requires some changes, which makes it 
> compatible with both psycopg2 and > 2.
> 
> I have a set of changesets, based on the stable/3.2.x branch, which 
> make the test suite pass with both psycopg 2 and 3; they can be 
> previewed at 
> <https://github.com/django/django/compare/stable/3.2.x...dvarrazzo:psycopg3-support>.
>  Most of the changes are import-related, breaking the assumption that using 
> Postgres implies psycopg2 installed (bopth in the Django code and in its 
> tests). A few changes are needed to accommodate differences in the behaviour 
> of PostgreSQL when using server-side binding. A writeup with the description 
> of these changes is available at 
> <https://www.psycopg.org/articles/2021/08/02/psycopg3-django-driver/>.
> 
> I would like to propose these changes for inclusion in Django. I would 
> say that the Psycopg 3 backend module should remain an external package 
> until the adapter becomes more stable and the go-to choice for 
> PostgreSQL. Some of the changes proposed for Django can be implemented 
> in different ways: for instance, instead of importing the Range object 
> from psycopg2 (and now 3, with imports that in my changeset are 
> conditional), Django could have its own Range object implementation and 
> the two backends can be configured to use it instead of the 
> driver-provided ones. Yesterday someone made me aware that the GROUP BY 
> problem was found in the Oracle backend too and solved in a different 
> way (https://code.djangoproject.com/ticket/27632).
> 
> So, I would like to know, first, if the Django project has interest in 
> accepting changes with the goal of supporting Psycopg > 2 and 
> server-side parameters binding for PostgreSQL (which would also help 
> other potential backends for drivers using the same parameters passing 
> mechanism, such as asyncpg) and if so what is the best way to propose 
> them. I can propose a set of stand-alone merge requests, where the code 
> and the single alternative implementations can be reviewed.
> 
> Thank you very much!
> 
> -- Daniele
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/f82d221e-fc12-4131-9c81-c38b77746c1an%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-users/f82d221e-fc12-4131-9c81-c38b77746c1an%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7584e71f-d4de-42ad-8297-28eac17a3ec7%40www.fastmail.com.

Re: Is there a quick and easy way to copy a model instance

[Markus Holtermann]

Hi Mike,

Last time I checked, when you set `instance.pk = None` and then do 
`instance.save()`, Django will create a new instance.

Cheers

Markus

On Mon, Jul 26, 2021, at 9:13 AM, Mike Dewhirst wrote:
> I'm archiving a particular child record every time it is saved but 
> connecting it to another parent.
> 
> Each year I create a new parent and the saving process keeps going but 
> the copied child gets connected to the new parent.
> 
> That will give me an annual snapshot of the child record.
> 
> At the moment I'm just copying it one field at a time.
> 
> Thanks for any hints
> 
> Cheers
> 
> Mike
> 
> 
> -- 
> Signed email is an absolute defence against phishing. This email has
> been signed with my private key. If you import my public key you can
> automatically decrypt my signature and be sure it came from me. Just
> ask and I'll send it to you. Your email software can handle signing.
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/8db31592-8835-2095-22be-5ce4e6989ed2%40dewhirst.com.au.
> 
> Attachments:
> * OpenPGP_signature

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e624b395-5b19-4c11-9f1a-aa952da220fc%40www.fastmail.com.

Re: [django-announce] Django security releases issued: 3.2.1, 3.1.9 and 2.2.21

[Markus Holtermann]

Hi all,

We took an defense-in-depth approach which seemed fined with our test suite. 
But it turns out, there are cases that weren't covered by tests which caused a 
regression in a few specific cases. This is tracked in 
https://code.djangoproject.com/ticket/32718

Cheers,

Markus

On Fri, May 7, 2021, at 1:22 PM, Ned Batchelder wrote:
> It seems to me that the release note for 2.2.21 is incomplete.  It 
> says, "Specifically, empty file names and paths with dot segments will 
> be
> rejected."  
> 
> But it's stricter than that: any path component causes the path to be 
> rejected:
> 
> > if name != os.path.basename(name):
> > raise SuspiciousFileOperation("File name '%s' includes path 
> > elements" % name)
> 
> Is this level of strictness necessary?
> 
> --Ned.
> 
> On 5/4/21 4:54 AM, Carlton Gibson wrote:
> > Details are available on the Django project weblog:
> > 
> > https://www.djangoproject.com/weblog/2021/may/04/security-releases/
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "django-announce" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to django-announce+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-announce/2B8F47F5-20C4-477B-81F4-DEA23A178294%40gmail.com
> >  
> > <https://groups.google.com/d/msgid/django-announce/2B8F47F5-20C4-477B-81F4-DEA23A178294%40gmail.com?utm_medium=email&utm_source=footer>.
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/1a9cca6d-de29-f0f6-f787-82f3894a63fe%40nedbatchelder.com
>  
> <https://groups.google.com/d/msgid/django-users/1a9cca6d-de29-f0f6-f787-82f3894a63fe%40nedbatchelder.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/83a199e1-c67f-44b1-abc0-4b323e229ac4%40www.fastmail.com.

Primary Git branch renamed

[Markus Holtermann]

Hello all,

following a very long discussion on the django-developers[1] mailing list, 
we've renamed the primary branch of the Django git repository from "master" to 
"main".

Cheers,

Markus

[1] https://groups.google.com/g/django-developers/c/tctDuKUGosc/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1e53534e-da27-49a3-835b-0d093fd533cc%40www.fastmail.com.

Re: Tutorial "Writing your first Django App": NoReverseMatch at /polls/ - down at the end of part 3

[Markus Grossniklaus]

Thanks a lot Chucky!
No error message
displays at least one dot! fine

http://127.0.0.1:8000/admin/
shows ERR_CONNECTION_REFUSED 
even with no Proxy active and iptables shows no restrictions e.g. 
everything is allowed
How could I debug this?


On Wednesday, April 15, 2020 at 12:27:21 AM UTC+2, Markus Grossniklaus 
wrote:
>
> a) I worked the whole tutorial down to the bottom of part 3
> b) I connect with the browser to http://127.0.0.1:8000/polls/
> c) the result is: NoReverseMatch at /polls/
> d) all project data are attached to this POST in mysite.zip
> e) I think it cannot be a difficult problem -> does anybody see it?
> Thanx for any help!
>
> [image: NoReverseMatch.PNG]
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f3ecb032-80c9-49bf-89da-e1656752fe89%40googlegroups.com.

Re: Running pending migrations in Middleware

[Markus Holtermann]

Yes, I do see several problems. Some of them:

- All middleware are run for every request
- What you're doing can slow down your request response time to minutes, 
depending on home many migrations you have
- Depending on your database, migrations might not be atomic thus causing 
conflicts
- You have no way to intervene when something goes south
- ...

I can elaborate in more detail when you want. But please, don't run migrations 
as part of the request-response cycle.

/Markus

On Sun, Jul 28, 2019, at 3:48 PM, David Grant wrote:
> Anyone see any problems with running migrations in Middleware?
> 
> import logging
> import os
> import time
> 
> from django.core.management import call_command
> from django.http import HttpResponse
> 
> from products.models.models import AppVersion
> 
> LOG = logging.getLogger(__name__)
> 
> 
> # Used for testing locally when the GAE_VERSION environment is not set
> FAKE_VERSION_TESTING = 8
> 
> 
> class MigrateMiddleware:
> 
> def __init__(self, get_response):
> self.get_response = get_response
> 
> def __call__(self, request):
> start_time = time.time()
> try:
> LOG.info("Running migrate middleware")
> # Figure out what version of our app is now deployed
> app_version, created = 
> AppVersion.objects.get_or_create(version=os.getenv('GAE_VERSION', 
> FAKE_VERSION_TESTING))
> if not app_version.migrations_succeeded or created: 
># Previous attempt at this deployed version failed, or this was 
> a new deployment.
> try:
> call_command('migrate')
> except:
> return HttpResponse("Running a Django migration 
> failed! Investigate.", status=500)
> app_version.migrations_succeeded = True
> app_version.save()
> finally:
> LOG.info("Took: %ss", time.time() - start_time)
> return self.get_response(request)
> 
> 
> It seems to work just fine in a quick test.
> 
>  -- 
>  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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/bdfd6393-6d68-4285-b5a6-eb1be98ef467%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-users/bdfd6393-6d68-4285-b5a6-eb1be98ef467%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3d2c95c8-3fe6-4890-8c06-2206ad72c7b0%40www.fastmail.com.

Re: Google Plus going away - is Groups staying ?

[Markus Berndner]

markus-bernd...@t-online.de
markus-bernd...@web.de
markus.bernd...@gmail.com
markusbernd...@gmail.com

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/de2d0f16-ad73-4fd5-b210-63946ab7ca9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Zero Downtime Field Type Changes

[Markus Holtermann]

Hey Kyle, that sounds about right. It's a variation of the "Migration Recipe" I 
came up with a while ago: 
https://markusholtermann.eu/2016/04/django-migrations-recipe-2/ . My question 
would be if you really need the field of the new type to have the exact same 
name as the old one. If you can live or deal with the new type using a 
different name it's much easier as you don't need to migrate data twice.

/Markus

On Wed, Mar 13, 2019, at 4:41 AM, 'Kyle Mulka' via Django users wrote:
> Hi there,
> 
> Wondering if there's any tool out there to make a zero downtime field 
> type change easier. I want to change a django model field from one type 
> to another, and the format of the field in the database is slightly 
> different.
> 
> I've come up with a process I think will work, but it will be rather 
> tedious if done manually. Wondering if there's a more automated 
> approach or other tools out there already. I'd like to come up with a 
> general solution for use in the future, but right now trying to tackle 
> converting UUIDField from django-extensions to the built in django 
> version.
> https://github.com/django-extensions/django-extensions/issues/647
> 
> I was thinking about maybe using a custom field that supports both 
> types, but not exactly sure how to write a custom field that would do 
> that.
> 
> If it helps, the manual process I'm thinking about kind of goes as follows:
> 
> # existing model:
> class Model:
> field = OldField()
> 
> # add field_old with OldField type
> # when updating or adding rows start writing to both fields
> # copy data from field to field_old
> class Model:
> field = OldField()
> field_old = OldField()
> 
> # stop using field, only use field_old
> # remove field
> class Model:
> field_old = OldField()
> 
> # create field with new type
> # when updating or adding rows start writing to both fields in their 
> respective formats
> # copy data from field_old in old format to field in new format
> class Model:
> field = NewField()
> field_old = OldField()
> 
> # stop using field_old
> # remove field_old
> class Model:
> field = NewField()
> 
> Thanks for your help!
> 
> --
> Kyle Mulka
> http://www.kylemulka.com
> 
>  -- 
>  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 https://groups.google.com/group/django-users.
>  To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/b16ffdee-74d6-4ba2-ac1f-b5bd9cf1e40b%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-users/b16ffdee-74d6-4ba2-ac1f-b5bd9cf1e40b%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  For more options, visit https://groups.google.com/d/optout.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d75dee2f-d273-4d47-9d3f-859aac0e6d96%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: Composite Primary / Foreign Key support

[Markus Holtermann]

There's general interest in having support for composite keys and composite 
foreign key. It's just that nobody has implemented it. 

There are proposals among the DEPs that layout ideas how they could be 
implemented:

- https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst
- 
https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst

On Mon, Feb 18, 2019, at 9:28 AM, 'Ellinghaus, Lance J' via Django users wrote:
> NONCONFIDENTIAL // EXTERNAL
> So, basically, Django will not be supporting Composite Primary Keys in 
> the future?
> 
> Lance
> 
> -Original Message-
> From: django-users@googlegroups.com  On 
> Behalf Of Michal Petrucha
> Sent: Monday, February 11, 2019 8:34 AM
> To: Django users 
> Subject: [External] Re: Composite Primary / Foreign Key support
> 
> NONCONFIDENTIAL // EXTERNAL
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Mon, Feb 11, 2019 at 01:08:41AM -0800, 'Lance Ellinghaus' via Django 
> users wrote:
> > I have seen references to people adding the support of composite 
> > primary keys to Django for years, but it does not look like it has been 
> > added.
> >
> > I have a number of legacy databases that I cannot add fields to but 
> > need to be able to be queried through Django. They are read-only tables.
> > A number of the tables are also related through Composite Foreign Keys 
> > and I have seen some addons but not sure what is fully supported.
> >
> > I am trying to use Django 2.1.5.
> >
> > Any help or ideas would be appreciated, and saying  "Add a field to 
> > your tables" is not an option.
> >
> > Thank you.
> 
> Hi Lance,
> 
> I haven't been on top of this in recent years, but let me try.
> 
> When it comes to just composite primary keys, as long as you only need 
> read access, you might be able to get away with marking an arbitrary 
> field as the primary key. Using a non-unique field as the primary key 
> would make any writes to the database dangerous, but that's not your 
> case here. However, you also lose the invariant that filtering on the 
> “pk” field alias will match at most one row, which means the admin 
> would probably be off the table, too – since that assumes the “pk” is, 
> in fact, unique, and the same holds for any other package that makes 
> use of “pk”. You should still be okay in your own code, though.
> 
> For composite foreign keys, there is nowadays a private, undocumented 
> API, ForeignObject, which is what ForeignKey builds on. The general 
> ForeignObject lets you specify multiple fields that make up the 
> relation, you should be able to find some examples in the test suite 
> (there is a foreign_object package in there). Keep in mind that this is 
> an internal API, so it might change without warning.
> 
> Good luck,
> 
> Michal
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBCgAGBQJcYXniAAoJEHA7T/IPM/kl8EAP/Rzaxqe0bDO6vkxb4/Mmmj5S
> 62t6Cfm3VqqK6NxYjRXG904jKwDI4HMH1SAs5fdVMh9vf+VBj/S5bcIpQbesqXbh
> wbkcIn+mmnfhLDaHOGunYqp76tscBJv/rtxJZaX5NRLp7OraCWtbjRBtiw1fJ/tl
> iJD0HRIk9zn0pqyX8GjeAyM0UR+uL1wwrvz8Ur85ASsc8pFThTP6ZMQoaEIgo9D+
> HB3XfrhiOMd5Nb2SbjG4KCRe7alpFx83nuY53YVsv+8X+Nqp4Ndi7ch2Ni3jxxHf
> R7qVJYsMp/l72CNb6KiT85sb6PwQyeVdvU78cXKjkIKDirskGgQIEW2OvK+ZXC3B
> Aj4I+AMFXEKje8ITfW3/s/v+UNvVTNZHYC5NPZ6o50+YJFDoiwb0mpQMdUredWZk
> nT2cYMgyPQA/XKN9w5vUCNbTebPG/AA7yCthXbOrHn9Xl+kICkXRjjl9fHRUs55Q
> wgPqz0CFXPKaE+JFt/NABJzdSrki1y587GHsOb7hKFiQwS8DHU8WOMXkR3BGKEtN
> q0gebcqKvVnjRwLLsBvB0h3uI/yifgBTp8G8/+tZ0WuNdongTe+yPzchxuRjgx10
> e70xtBjgsyCQGRB3CPsgR2UelQOtAEt8ZyYwyPF5sQYOvQg1xjcYp87FqfqflSTE
> 6aQIMkXhKjKazmc/ew9F
> =Ji5Z
> -END PGP SIGNATURE-
> 
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/20190211133426.GV10973%40konk.org.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/5c6a6c98.1c69fb81.eb4fb.5c2cSMTPIN_ADDED_MISSING%40gmr-mx.google.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving em

Re: SPAM sent via this list?

[Markus Holtermann]

Hi, if the response you got is related to https://bitbounce.com/ , we're in 
touch with them so that they can fix their system. Unfortunately, Google 
Groups makes it really hard to find individual members and kick them, for 
lists of the size of django-developers and django-users.

Cheers,

Markus

On Thursday, January 10, 2019 at 5:22:07 AM UTC+1, Lachlan Musicman wrote:
>
> I just got a spam email from the account
>
> aphi...@gmail.com 
>
> That is threaded to my previous response to Alejandro Reyes's email
>
> Here's the raw header
>
>
> Delivered-To: dat...@gmail.com 
> Received: by 2002:ab0:59f2:0:0:0:0:0 with SMTP id k47csp1496731uad;
> Wed, 9 Jan 2019 20:15:11 -0800 (PST)
> X-Received: by 2002:a17:906:e2c9:: with SMTP id 
> gr9-v6mr7444893ejb.108.1547093711410;
> Wed, 09 Jan 2019 20:15:11 -0800 (PST)
> ARC-Seal: i=1; a=rsa-sha256; t=1547093711; cv=none;
> d=google.com; s=arc-20160816;
> b=Uk1KEWZpXj57NrLSw/NrkYofbu7/WAxFBbuzEY7jMIpScKUGzLMh6hxFd89RhPMo7/
>  7eMRsfWxvPeVAknN7Ghc+A+jK+ZidGjRsv/DsKiCJYWLE4m/B2w2i5PpL0jPCTD/cJ7Q
>  /A3FbBDkoaegCbDZzBHwy1RF2lejE8joiT7VaIUKxINQ1Tq4Z0IGyCPdPjI/ThKWU+FU
>  xn+laGAltdoUG3WbvIueNXA8jChxUagFoMlns0yDr1FETv1ymUgcLefeqi7F5F65r9vo
>  9Rz6kyp33FSo5tqGRf1ZBmcSd4cXiIUwcEPTFMisEPxBLUTpspNcedop625YpWljG8sb
>  PRvw==
> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
> s=arc-20160816;
> h=to:subject:message-id:date:references:in-reply-to:mime-version:from
>  :dkim-signature;
> bh=Azuv04E2o8dshX5o1BJ8WGQr6D9cswM1D1HqW5tXEoo=;
> b=UCngM/tm+Rg242qMf/EbLYW8Cw+DpPvskZ1KVvBfqS7xDOqGg6vNHwKh+eJ/BZAjvS
>  gaLZFT2Z4uCt5BSeuQTclwi5Uw0NkZ3OrEwXSbm9dAe7k5dJ5vGv9XQFNncxd3BAx5AS
>  SE26fuct4nn3chaXCKmzZlaIYIlO0jfZ5uBgnpQFEGWAyAVYo6sUnhswLw5dPpKuckh/
>  dCGq1TIvd0hRrcqNw4jAIh4L6qyB96TlKbJSO/7nTbb7dN5/a5VxKXM/tT4/qkqfNW/D
>  bnmXoa7nHxKFFe9/WlY4ktFRo1ovndNqE2D/xZtptOEEneY46CaFvzI6ODFYbjMR5io/
>  SS8w==
> ARC-Authentication-Results: i=1; mx.google.com;
>dkim=pass header.i=@gmail.com header.s=20161025 header.b=dd8veXeU;
>spf=pass (google.com: domain of aphi...@gmail.com  
> designates 209.85.220.41 as permitted sender) smtp.mailfrom=aphi...@gmail.com 
> ;
>dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
> Return-Path: >
> Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. 
> [209.85.220.41])
> by mx.google.com with SMTPS id e44sor3343283ede.13.2019.01.09.20.15.11
> for >
> (Google Transport Security);
> Wed, 09 Jan 2019 20:15:11 -0800 (PST)
> Received-SPF: pass (google.com: domain of aphi...@gmail.com  
> designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41;
> Authentication-Results: mx.google.com;
>dkim=pass header.i=@gmail.com header.s=20161025 header.b=dd8veXeU;
>spf=pass (google.com: domain of aphi...@gmail.com  
> designates 209.85.220.41 as permitted sender) smtp.mailfrom=aphi...@gmail.com 
> ;
>dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=gmail.com; s=20161025;
> h=from:mime-version:in-reply-to:references:date:message-id:subject:to;
> bh=Azuv04E2o8dshX5o1BJ8WGQr6D9cswM1D1HqW5tXEoo=;
> b=dd8veXeUlee7ACSL3xnZk1RzWT44ZXlifjzUuqnUVlxZu5S0dkUgoVSsT8MaevKOGe
>  WorIqWc4/K6XFuz6caxwn+U+sWrYiESrusvkXsNAZAXzQ1G0e4tAc8uvh77AnoYUPstk
>  K2ZQyTRB42EuREJN94GArD6E0D+3cYk86eYF2BdXD1s59r7z97+LHNUJLE/EErHTiQ9B
>  TE3+AzAKpSgJF5a49sSIeFDGzF5O64qFqIr2wHL3ZuYYk0+LDP3mLIOtCEU1kmcpfRxS
>  mxyFqQ5t1XjkcZRuMVc0jvxsMTBeTSMs73i5PVmmWkmeXykc9YOPNFSXEg9+QeCduOEC
>  /yIA==
> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=1e100.net; s=20161025;
> h=x-gm-message-state:from:mime-version:in-reply-to:references:date
>  :message-id:subject:to;
> bh=Azuv04E2o8dshX5o1BJ8WGQr6D9cswM1D1HqW5tXEoo=;
> b=cFU5b8+MRXUtvTznVlGZLohfDDKdWCWXLdsPcP8TSYKGINSy+80JnJI5GL9Ogh6vQk
>  VDJyuuXsarPxBhew98u5kpThsAAQ6L92S2vA6b5I08S9KR4xIL6W+CsTa4bS3RZo17Ev
>  C4fP8wHwpCmylgqOVO2Kwp39HXgXg3mySVv9HyZ2JzzwgXF9bhqFeOWVXdWzHK4WdF1v
>  5S0/1Cr/8vIkjpOkD4NVtBp3frWUgDFIJN7wpukYdhcpc2FNpRJY15RKtBCv8MXOBGlA
>  FF/4uQXnGeyAiLd0yaGTROuR9cSzBzMlW+YWtXn4Xc3b8fYLZ9u4OwK2ty58NfAGMlPH
>  yJCQ==
> X-Gm-Message-State: AJcUukfvXzy9WecRe6/K4iC0iWtIxysbNXeBqUtF2Kd2ps8N/L8fOOHe 
> 40EtFgLtrpivvrGCWt4YnGRlV/Rdh2ioyee6AZX45w==
> X-Google-Smtp-Source: 
> ALg8bN40FdsN8UjLFM7ESJPXEvdSS/UpieqzzaYvx8rwlAn8+JpAg1Nnt5kHhcXV47odMIri/HcQiFHsBIykx26t1P0=
> X-Receive

Re: AnonymousUser.is_authenticated woes

[Markus Holtermann]

Hi Stefan,

You need to remove the parentheses `()` after `is_authenticated`.

Markus

On Thu, Oct 11, 2018, at 6:44 PM, Stefan Bethke wrote:
> First time poster here,
> 
> I'm currently working on some unit tests of my Django app, and I'm 
> running into a issue with is_authenticated.
> 
> I'm using Django 1.11.16 and Django CMS 3.5.2.
> 
> While trying to work with Django CMS menus, I get:
> 
>   File "/usr/local/lib/python3.6/site-packages/menus/menu_pool.py", line 
> 243, in get_renderer
> return MenuRenderer(pool=self, request=request)
>   File "/usr/local/lib/python3.6/site-packages/menus/menu_pool.py", line 
> 107,  in __init__
> self.draft_mode_active = use_draft(request)
>   File "/usr/local/lib/python3.6/site-packages/cms/utils/moderator.py", 
> line 5, in use_draft
> is_staff = (request.user.is_authenticated() and 
> request.user.is_staff)
> TypeError: 'property' object is not callable
> 
> Looking at the documentation, this should be fine. 
> https://docs.djangoproject.com/en/1.11/ref/contrib/auth/#attributes
> 
> Trying this in a shell:
> ./run.sh manage shell
> Python 3.6.6 (default, Sep 12 2018, 02:15:29) 
> [GCC 6.4.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> (InteractiveConsole)
> >>> from django.contrib.auth.models import AnonymousUser
> >>> AnonymousUser.is_authenticated
> 
> >>> bool(AnonymousUser.is_authenticated)
> True
> >>> AnonymousUser.is_authenticated()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: 'property' object is not callable
> 
> None of that seems right. Have I somehow managed to get something else 
> pulled in?
> 
> In the actual application, not-logged in users see the right stuff, so 
> apparently there it's working.
> 
> 
> Stefan
> 
> -- 
> Stefan BethkeFon +49 151 14070811
> 
> -- 
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/E0552D52-C644-43AD-8F57-0DEAEC757445%40lassitu.de.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1539284097.3153609.1538936288.7A7BC607%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: 2.1b1: Getting "unexpected keyword argument 'limit_choices_to'"

[Markus Holtermann]

Thanks for the report Axel. This seems to be the same issue as the one 
reported in https://code.djangoproject.com/ticket/29449 . A fix for this is 
coming with the next pre release (beta 2 or RC1).

/Markus

On Wednesday, July 4, 2018 at 1:46:54 PM UTC+2, axel...@chaos1.de wrote:
>
> Hi, 
>
> I tried 2.1b1 with my 2.0.6 project and at got this error on startup: 
> —- 
> (erdb_d2.1+p3.6) axels-imac:ERDB2 ajr$ django-admin check 
> /usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/psycopg2/__init__.py:144:
>  
> UserWarning: The psycopg2 wheel package will be renamed from release 2.8; 
> in order to keep installing from binary please use "pip install 
> psycopg2-binary" instead. For details see: <
> http://initd.org/psycopg/docs/install.html#binary-install-from-pypi>. 
>   """) 
> Traceback (most recent call last): 
>   File "/usr/local/py_env/erdb_d2.1+p3.6/bin/django-admin", line 11, in 
>  
> sys.exit(execute_from_command_line()) 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/core/management/__init__.py",
>  
> line 381, in execute_from_command_line 
> utility.execute() 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/core/management/__init__.py",
>  
> line 357, in execute 
> django.setup() 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/__init__.py",
>  
> line 24, in setup 
> apps.populate(settings.INSTALLED_APPS) 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/apps/registry.py",
>  
> line 120, in populate 
> app_config.ready() 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/contrib/admin/apps.py",
>  
> line 24, in ready 
> self.module.autodiscover() 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/contrib/admin/__init__.py",
>  
> line 26, in autodiscover 
> autodiscover_modules('admin', register_to=site) 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/utils/module_loading.py",
>  
> line 47, in autodiscover_modules 
> import_module('%s.%s' % (app_config.name, module_to_search)) 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/importlib/__init__.py", 
> line 126, in import_module 
> return _bootstrap._gcd_import(name[level:], package, level) 
>   File "", line 994, in _gcd_import 
>   File "", line 971, in _find_and_load 
>   File "", line 955, in 
> _find_and_load_unlocked 
>   File "", line 665, in _load_unlocked 
>   File "", line 678, in exec_module 
>   File "", line 219, in 
> _call_with_frames_removed 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/contrib/auth/admin.py",
>  
> line 6, in  
> from django.contrib.auth.forms import ( 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/contrib/auth/forms.py",
>  
> line 63, in  
> class UserCreationForm(forms.ModelForm): 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/forms/models.py",
>  
> line 256, in __new__ 
> apply_limit_choices_to=False, 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/forms/models.py",
>  
> line 172, in fields_for_model 
> formfield = f.formfield(**kwargs) 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/db/models/fields/related.py",
>  
> line 1016, in formfield 
> return super().formfield(**kwargs) 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/db/models/fields/related.py",
>  
> line 956, in formfield 
> **kwargs, 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/db/models/fields/related.py",
>  
> line 418, in formfield 
> return super().formfield(**defaults) 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/db/models/fields/__init__.py",
>  
> line 890, in formfield 
> return form_class(**defaults) 
>   File 
> "/usr/local/py_env/erdb_d2.1+p3.6/lib/python3.6/site-packages/django/forms/fields.py",
>  
> line 213, in __init__ 
> super().__init__(**kwargs) 
> TypeError: __init__() got an unexpected keyword argument 
> 'limit_choices_to' 
> (erdb_d2.1+p3.6) axels-imac:ERDB2 ajr$ findp imit_choices_to 
&g

Re: Migration for auth_user.username field

[Markus Holtermann]

Hi Graeme, the only solution that comes to mind is overriding the 
alter_field() or _alter_field() methods on the schema 
editor: 
https://github.com/django/django/blob/stable/1.11.x/django/db/backends/base/schema.py

/Markus

On Wednesday, July 19, 2017 at 12:19:09 AM UTC+10, Graeme Perrow wrote:
>
> I am responsible for the SQL Anywhere Django driver 
> <https://github.com/sqlanywhere/sqlany-django> and I'm trying to add 
> support for Django 1.10. When I create a project and run "python manage.py 
> migrate", it executes a bunch of SQL statements but then fails when 
> altering the auth_user table to extend the username field to 150 
> characters. The problem is that the username column has a unique index on 
> it, and SQL Anywhere does not allow a column to be altered if there's an 
> index on it. I was hoping there was a feature I could enable in the 
> BaseDatabaseFeatures subclass that tells Django this but I couldn't find 
> one. I seem to be stuck.
>
> Does anyone know of a way I can tell Django to drop the unique index, 
> alter the column, and then re-create the index? Is there some sort of hook 
> that I can use to detect this case and drop / recreate the index myself?
>
> 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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/805ba24c-1d9d-4f9a-97c9-7139038f2962%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Channels and Background Processes

[Markus Schaber]

Hi, Andrew,

We intended to implemen the pool in the "Background Processes" mentioned on 
https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django.
 
<https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django>

Apart from persistent information, it also contains non-persistent 
information (like which clients are currently connected, and when they last 
sent data), so I'm not sure whether a database is the right place to put 
that information.


Thanks,
Markus Schaber



Am Dienstag, 30. Mai 2017 19:17:35 UTC+2 schrieb Andrew Godwin:
>
> Hi Markus,
>
> There is no plan to roll Channels up to and including the 2.0 release so 
> far - it's persisting as an external project for now with its own release 
> cycle.
>
> Some of what you describe can be done with Channels - it gives you an 
> inter-process messaging framework for sending data between processes and 
> having background tasks acting on it - but it does not give the "pool with 
> state information", which should be done using a database, probably one 
> more designed for that kind of task like Redis. It also does not have 
> directly native timer support intermingled with other events - you have to 
> set up timer events and hook onto the client events (like sending a 
> message) and see if one happened recently enough to trigger what you want 
> to do.
>
> At the end of the day, Channels and ASGI (which powers it) are a low-level 
> framework for letting you design a more event-driven system on top of 
> Django. They will help you do what you want, but you will have to implement 
> your own layer of features and customisation, much like sites on top of 
> Django itself.
>
> Andrew
>
> On Tue, May 30, 2017 at 5:19 AM, Markus Schaber  > wrote:
>
>> Hi,
>>
>> We're currently working on a server application using Django as framework.
>>
>> Now, some advanced use cases appeared on the horizon, and we're 
>> evaluating how we'll be able to solve them in the future.
>>
>> We came across 
>> https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django
>>  
>> which advises to use "Django Channels" for that.
>>
>> The linked article claims that "The plan is to roll Channels into Django 
>> for the 1.10 release" - but as far as I can see, it's not in 1.10 nor 1.11. 
>> Can anyone confirm my findings?
>>
>> Additionally, the linked article shows "background processes", which 
>> could fit nicely into our concept, as we need functionalities like:
>>
>> - Some pool with state information about certain clients (whether they're 
>> currently connected via web socket, which messages they sent etc...)
>>
>> - Based on some timers (scheduled jobs, or clients were not connecting 
>> for some time, etc...) we need to get active on the server side (e. G. send 
>> emails, or send messages via web socket to other clients, etc...)
>>
>> Can those background processes be used to implement such functionality? 
>> We did not find any documentation about them apart from the image yet, so 
>> pointers are welcome. :-)
>>
>> The pool information mentioned above needs also be available for clients 
>> using http messages, so we'll need to access that data from the "view 
>> functions".
>>
>> Is it possible and feasible to implement those features using Django?
>>
>> Thanks in advance,
>> Markus Schaber
>>  
>>
>> -- 
>> 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 https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/3eb9e492-c7bf-472e-81dd-5957df8ed3bd%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/django-users/3eb9e492-c7bf-472e-81dd-5957df8ed3bd%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/75518b56-a6ff-43d9-b57a-0b188fe45fe5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django Channels and Background Processes

[Markus Schaber]

Hi,

We're currently working on a server application using Django as framework.

Now, some advanced use cases appeared on the horizon, and we're evaluating 
how we'll be able to solve them in the future.

We came across 
https://blog.heroku.com/in_deep_with_django_channels_the_future_of_real_time_apps_in_django
 
which advises to use "Django Channels" for that.

The linked article claims that "The plan is to roll Channels into Django 
for the 1.10 release" - but as far as I can see, it's not in 1.10 nor 1.11. 
Can anyone confirm my findings?

Additionally, the linked article shows "background processes", which could 
fit nicely into our concept, as we need functionalities like:

- Some pool with state information about certain clients (whether they're 
currently connected via web socket, which messages they sent etc...)

- Based on some timers (scheduled jobs, or clients were not connecting for 
some time, etc...) we need to get active on the server side (e. G. send 
emails, or send messages via web socket to other clients, etc...)

Can those background processes be used to implement such functionality? We 
did not find any documentation about them apart from the image yet, so 
pointers are welcome. :-)

The pool information mentioned above needs also be available for clients 
using http messages, so we'll need to access that data from the "view 
functions".

Is it possible and feasible to implement those features using Django?

Thanks in advance,
Markus Schaber
 

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3eb9e492-c7bf-472e-81dd-5957df8ed3bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: sqlmigrate does not quote default string values

[Markus Holtermann]

I gave it a quick look, but I can't reproduce this issue on the current 
master branch for SQLite3, PostgreSQL or MySQL. Can you give us more 
information when you report the issue please, such as Django version, 
database + version, database driver + version, and anything you think might 
be helpful. Thank you

/Markus

On Friday, February 3, 2017 at 7:27:31 PM UTC+1, Michael Grijalva wrote:
>
> Ok thank you. I will dig into it more.
>
> On Thursday, February 2, 2017 at 7:57:16 AM UTC-8, Tim Graham wrote:
>>
>> It looks like a bug at first glance. I encourage you to look at Django's 
>> source code and try to confirm and fix it.
>>
>> On Wednesday, February 1, 2017 at 8:11:21 PM UTC-5, Michael Grijalva 
>> wrote:
>>>
>>> Not sure if this is considered a bug, but the SQL output from sqlmigrate 
>>> contains a small syntax error with default string values:
>>>
>>> Add a new column as so:
>>> class City(models.Model):
>>> ...
>>> name = models.CharField(max_length=100, default='a b c d')
>>>
>>> Create migration, and run sqlmigrate command:
>>> BEGIN;
>>> --
>>> -- Add field name to city
>>> --
>>> ALTER TABLE `map_city` ADD COLUMN `name ` varchar(100) DEFAULT a b c d 
>>> NOT NULL;
>>> ALTER TABLE `map_city` ALTER COLUMN `name ` DROP DEFAULT;
>>> COMMIT;
>>>
>>> Notice 'a b c d' is missing quotes. When this migration is actually 
>>> applied it runs through cursor.execute, which properly quotes the value.
>>>
>>> I realize sqlmigrate is only for getting a preview of the SQL, but other 
>>> parts like the table name and columns are correctly quoted, so why not the 
>>> default?
>>>
>>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6938a3b7-3aca-4a88-bfec-2726fbe2d2d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations with multiple databases

[Markus Holtermann]

Hi Andrea,

If you have models that are entirely unrelated in different databases
you could use different values for INSTALLED_APPS to limit the apps
Django sees or by settings the values in the MIGRATION_MODULES dict to
None to tell Django that those apps don't have migrations.

Cheers,

/Markus

On Tue, Oct 25, 2016 at 08:05:46AM -0700, andrea crotti wrote:

We have a couple of databases with a tiny number of tables, but
django-migrations has still go through all the migrations anyway.
So even if the SQL itself is nothing it still takes a massive amount of
time and memory for the usual known issues with migrations on big projects.

I guess it works this way because it only knows at run time in the router
if something should be done, however it's a bit odd.

If we declared the models per database somehow statically, could we not
just skip everything else?

--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f5340bbf-2247-4068-bd37-9f3a0faf23d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20161025152909.GE2361%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: TypeError: 'class Meta' got invalid attribute(s): indexes

[Markus Holtermann]

Hi Dennis,

"indexes" is a new thing in the upcoming Django version. I'm fairly
certain that you accidentially used Django's development version at some
point while going through the tutorial.

Could you please paste your models.py and the migration files Django
created for you when you ran "manage.py makemigrations".

/Markus

On Sun, Aug 21, 2016 at 11:16:44PM -0700, Dennis Kornbluh wrote:

Going through the Django tutorial
<https://docs.djangoproject.com/en/1.10/intro/tutorial05/>, now at part 5,
section "Running tests". Followed the directions precisely, copy/pasted to
create polls/test.py, After running

$ python manage.py test polls


got a stacktrace (http://dpaste.com/2XP5QZ7) ending with TypeError: 'class 
Meta' got invalid attribute(s): indexes


Totally stumped. Everything has worked up to this point.



--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4725f223-8a5e-4177-b5d2-b92d0fd416db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160822150705.GA4206%40inel.local.
For more options, visit https://groups.google.com/d/optout.

Re: Django migrations taking all the memory on Django 1.9

[Markus Holtermann]

Thanks Andrea,

this is a known issue. Let me give you a bit of a history on this:

In 1.7 Django didn't do any caching. That was awfully slow for huge
projects like yours.

In 1.8 Django introduced heavy caching. Things improved speed wise but
failed horrifically when you were altering relations or related models

In 1.8.1 (I believe it was the .1 patch release, not sure right now)
Django reduced the caching and ensured that related models are
"reloaded" [1, 2]. At least that was the plan.

In 1.9 Django slightly changed the way it detected the migration plan
and dropped an undocumented and unimplemented feature [3, 4]. This
improved the forward migrations but remains slow for backwards
migrations.

My plan is to get rid of the "render()" method during schema
alterations. Only when using RunPython the requested models would need
to be rendered. I started implementing that in [5]. If you're looking
into contributing there, I'm happy to talk to you in more detail,
preferably on IRC in #django-dev.

Cheers,

/Markus

[1] 
https://github.com/django/django/commit/a1ba4627931591b80afa46e38e261f354151d91a
[2] https://code.djangoproject.com/ticket/24225
[3] 
https://github.com/django/django/commit/5aa55038ca9ac44b440b56d1fc4e79c876e51393
[4] https://code.djangoproject.com/ticket/24745
[5] https://github.com/MarkusH/django/commits/schemaeditor-modelstate

On Fri, Aug 05, 2016 at 03:07:56AM -0700, andrea crotti wrote:

We have a very big Django project with > 100 apps and > 300 models.
We had some massive issues with Django 1.8 and migrations, which would take
forever and just take all the computer memory after a while.

Now with Django 1.9 things improved, however we are again back with some
extremely bad performances and massive memory usages (up to 8GB of RAM for
example), sometimes just to run ONE single migration.

It's not even entirely deterministic though sometimes killing the process
and doing it again just works.

I'm attaching the profile graph (done wtith gprof2dot) from running
"./manage migrate" and one thing that clearly looks bad is that *render*
for example is called 44355 times, which is definitively not normal.

Any idea about about what we can do about this and what could be the
problem?
I have the impression that it's related with the amount of models and how
they are interconnected, and mabye some caching would avoid all this extra
computation.

Noone else has similar issues?
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5b67eccf-d48f-4926-86ec-4bd2a8427dcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160805115406.GD30863%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Possible Bug in RegexURLResolver

[Markus Holtermann]

Hey,

I did indeed not consider the multi-threading behavior on uwsgi when
writing that. Can you post this to django-develop...@googlegroups.com
and open a ticket for that. I'd love to get someone else's input.

Thanks

/Markus

On Sat, Jul 09, 2016 at 08:36:44AM -0700, a.bra...@rataran.com wrote:

Hello everyone.

I'm using django (1, 10, 0, u'beta', 1).

When I try to reverse url in shell everything goes fine.

When under nginx/uwsgi with many concurrent request I get

... /local/lib/python2.7/site-packages/django/urls/resolvers.py", line 241,
in reverse_dict
   return self._reverse_dict[language_code]
KeyError: 'it'

After a wile I figured out that RegexURLResolver is memoized by
get_resolver and so it acts like a singleton for a certain number of
requests.

Analyzing the code of  RegexURLResolver I found that the method _poupulate
will return directly if it has been called before and not yet finished.

   ...
   def _populate(self):
   if self._populating:
   return
   self._populating = True
   ...

if used for recursive call in a single thread this will not hurt, but in my
case in uwsgi multi thread mode I got the error.

here is my quick and dirty fix:

class RegexURLResolver(LocaleRegexProvider):
   def __init__(self, regex, urlconf_name, default_kwargs=None,
app_name=None, namespace=None):

   ...

   self._populating = False
   self.RLock = threading.RLock()

   ...

  def _populate(self):
   if self._populating:
   self.RLock.acquire()
   self.RLock.release()
   return
   self._populating = True
   self.RLock.acquire()

   ...

   self._populating = False
   self.RLock.release()


Does anyone know if there is a better solution?

Tank You


--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/147ab225-7ec9-4bf3-a5e1-61a945154c29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20160709162551.GC11144%40inel.local.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: proxy model inheritance generates a migration file in a third party app

[Markus Holtermann]

Hello Iliana,

this is due to the definition of app_label = 'actstream' on your proxy 
model. This tells Django that this model should belong to another app. 
Hence the migrations involving that model are added to the actstream app's 
migrations.

/Markus


On Friday, January 29, 2016 at 10:14:24 AM UTC+11, Iliana Toneva wrote:
>
>  
> Hello,
>
> I am using a third party app actstream 
> <https://github.com/justquick/django-activity-stream> (
> https://github.com/justquick/django-activity-stream) and am creating a 
> proxy for one of the original actstream models :
>
> # myapp/models.py
> from actstream.models import Action
>
> # Subclass Action model and apply my own manager 
> class MyAction(Action):
> objects = MyActionManager()
>
> class Meta:
> proxy = True
> app_label = 'actstream'
>
>
> The issue that I am having is that when I run './manage.py makemigrations', 
> that creates a migration file 0002_myaction.py and adds it to the third party 
> app migrations (instead of adding it to myapp/migrations):
>
>
> *Migrations for 'actstream':*
>
>   *0002_myaction.py*:
>
> - Create proxy model MyAction
>
>
> # actstream/migrations/0002_myaction.py
>
> # -*- coding: utf-8 -*-
> from __future__ import unicode_literals
>
> from django.db import migrations, models
>
>
> class Migration(migrations.Migration):
>
> dependencies = [
> ('actstream', '0001_initial'),
> ]
>
> operations = [
> migrations.CreateModel(
> name='MyAction',
> fields=[
> ],
> options={
> 'proxy': True,
> },
> bases=('actstream.action',),
> ),
> ]
>
> Is there a way to prevent this behavior and force './manage.py 
> makemigrations' to create a migration file in myapp/migrations/ instead? 
>
> Many thanks,
> Iliana
>
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4c72ac4c-34fb-433e-8d62-82c83855a8b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can you remove a model's last field of SQLite3 in Django 1.8?

[Markus Holtermann]

No, you can't because of two things:

1. SQLite doesn't allow an 'ALTER TABLE ... DROP COLUMN ...'
  
  We get away with that by creating a new table and copying the data

  over: https://www.sqlite.org/lang_altertable.html

2. SQLite doesn't allow a 'CREATE TABLE' statement without any columns:
  https://www.sqlite.org/lang_createtable.html

/Markus

On Sun, Nov 29, 2015 at 09:17:53AM -0800, KwangYoun Jung wrote:

Can you remove a model's last field of SQLite3 in Django 1.8?

I have a model that has only one column in SQLite3.
When I remove a last field of the model, I get an error like below



*django.db.utils.OperationalError: near ")": syntax error*Anyone knows
about this issue ?

--
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/951e9cbd-2540-43eb-a951-6a3722f3ee3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

--
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/20151129202807.GA10673%40pyler.local.
For more options, visit https://groups.google.com/d/optout.

Re: I have error like Type Error save() takes at least 2 arguments (1 given) in Django project.

[Markus Holtermann]

On Mon, Aug 31, 2015 at 03:10:09AM -0700, Remaze Vs wrote:

view.py file


class DealsForm(ModelForm):
   class Meta:
   model = Product
   fields = 
['title','description','category','price','sale_price','slug','active','update_defaults','user']
   exclude = ('user',)



model.py file



class Product(models.Model):
   title = models.CharField(max_length=120)
   description = models.TextField(null=True, blank=True,max_length=200)
   category = models.ManyToManyField(Category, null=True, blank=True)
   price = models.DecimalField(decimal_places=2, max_digits=100, default=29.99)
   sale_price = models.DecimalField(decimal_places=2, max_digits=100,\
   null=True, blank=True)
   slug = models.SlugField(unique=True)
   timestamp = models.DateTimeField(auto_now_add=True, auto_now=False)
   updated = models.DateTimeField(auto_now_add=False, auto_now=True)
   active = models.BooleanField(default=True)
   update_defaults = models.BooleanField(default=False)
   user = models.ForeignKey(User)

   def __unicode__(self):
   return self.title

   class Meta:
   unique_together = ('title', 'slug')

   def get_price(self):
   return self.price

   def get_absolute_url(self):
   return reverse("single_product", kwargs={"slug": self.slug})

   def save(self, request, *args, **kwargs):
   obj = super(DealsForm, self).save(commit=False, *args, **kwargs)


Why "DealsForm"??

Also: you might want to share the traceback in the full future.


   obj.user = request.user
   obj.save()


Can you solve this problems ?


/Markus



--
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/c82101d3-992c-4aaa-b932-787cd417009f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

--
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/20150831104151.GA519%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpSd_1Y9Lo2x.pgp
Description: PGP signature

Re: About the auto-increase PK

[Markus Holtermann]

Hi Hollandz,

You can't do that from within Django automatically. You'd need to write 
your own database migration to update the database as the assignment of the 
primary key value is part of the database and not Django. Have a look 
at 
https://docs.djangoproject.com/en/1.8/ref/migration-operations/#django.db.migrations.operations.RunSQL

/Markus

On Saturday, August 8, 2015 at 8:10:35 PM UTC+10, Holland_zwz wrote:
>
> Hi all,
>  I want to add one auto-increase PK which start from one given value(such 
> as start from 1000).
>
> I try to write the model as following:
>
> class MyModel(models.Model):
> mid = models.AutoField(verbose_name='My 
> ID',primary_key=True,default='1000')
>
>
> But only one record can be add when i add records in admin web site.
>
> Any ways to support this? thanks
>
> Regards,
> Hollandz
>
>
>

-- 
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/7e6ef24b-cff7-47a6-b6ac-a0d2c54be354%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: auto_created getting ignored by makemigrations

[Markus Holtermann]

Hey Joey,

not settings `auto_created=True` should do.

/Markus

On Thursday, August 6, 2015 at 1:17:09 PM UTC+10, JoeLinux wrote:
>
> Dear Anyone,
>
> I'm having an issue with a ManyToMany "through" table not being recognized 
> by the makemigrations command. Please consider the model definitions at the 
> following pastebin: http://pastebin.ubuntu.com/12011412/
>
> So, I have a Player model. Players are stored and updated in that model 
> (also for clarification, the Player model is in a separate app because it's 
> used for other purposes). The League model, when created, makes available 
> all of the Player objects in the DB for drafting to a LeagueTeam. That's 
> why there's a "through" table for LeaguePlayer, since I don't want to 
> affect the original Player object, and I want to add the additional 
> information as to what LeagueTeam the LeaguePlayer got drafted to (think 
> fantasy football).
>
> However, I'm getting errors in the console about the draft_leagueplayer 
> (the relevant app's name is "draft") table not existing, and I noticed it's 
> not getting created in the db. After a little digging, I realized that 
> ultimately the django.apps.config module's AppConfig.get_models() method is 
> set to ignore any apps with "auto_created = True" by default, thus ignoring 
> LeaguePlayer. If you look at the pastebin above, I am adding Player objects 
> to the League as soon as it's created, and the "auto_created = True" meta 
> attribute helps me do that easily.
>
> I'm wondering if there is a way around this. I need extra information in 
> this Many-to-Many relationship (the team the player is drafted to), and I'm 
> surprised the auto_created attribute exists and doesn't seem to work (since 
> the migration ignores the model). Is this a bug, or should I be manually 
> creating LeaguePlayer objects on-the-fly when adding to the League object 
> instead of using auto_created? Am I misusing auto_created?
>  
> Joey "JoeLinux" Espinosa
> about.me/joelinux
> [image: Joey "JoeLinux" Espinosa on about.me]
>   <http://about.me/joelinux>
>
>

-- 
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/16d13875-f720-4f32-9398-911b303a06f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Does imports of related models affect cascade deletion?

[Markus Amalthea Magnuson]

I will fetch the actual piece of code and build a small test case out of
it, will reply again in this thread when I have some more info.

On Thu, Jul 30, 2015 at 6:39 PM, Marc Aymerich  wrote:

> On Thu, Jul 30, 2015 at 3:38 PM, Markus Amalthea Magnuson
>  wrote:
> > Hey,
> >
> > I stumbled upon a piece of code and a comment that says this:
> >
> > Deleting a model object that has related objects will only cascade delete
> > those objects if their models have been imported.
> >
> > Is this true? I have not found it in the documentation and would like to
> add
> > a reference to the code comment so others won't be as confused as I am.
>
> Is this models module called models.py and does it live inside a
> Django application listed in INSTALLED_APPS?
>
>
> --
> Marc
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/wLiEuzqUVeQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CA%2BDCN_tKE56qJPJ339uL0Zo%2BvEDSsPdTnLMODHC_3H4hd856dw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAOXH8SXRVShSrLuPjZuPDPhbEEdc-Bi9v5JQm-xHf181iCzMKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Does imports of related models affect cascade deletion?

[Markus Amalthea Magnuson]

Hey,

I stumbled upon a piece of code and a comment that says this:

Deleting a model object that has related objects will only cascade delete 
those objects if their models have been imported.

Is this true? I have not found it in the documentation and would like to 
add a reference to the code comment so others won't be as confused as I am.

Here's an illustration (from memory, disregard if code is not valid python):

mymodel.py:

from django.db import models

class MyModel(models.Model):
foo = models.CharField()
bar = models.CharField()


my_other_model.py:

from django.db import models
from mymodel import MyModel

class MyOtherModel(models.Model):
baz = models.CharField()
bar = models.ForeignKey(MyModel)


some_source_file.py:

from mymodel import MyModel

# Without this line, deleting MyModel objects will not delete its related
# MyOtherModel objects (?):
from my_other_model import MyOtherModel

obj = MyModel.objects.get(pk=123)
obj.delete()

-- 
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/4991f097-ae07-4075-89c5-908df7b4ccf2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ValueError during migrations.RunPython to create OneToOne records in new model

[Markus Holtermann]

Hi Gergely,

You need to use apps.get_model() instead of get_user_model().  See 
https://docs.djangoproject.com/en/1.8/topics/migrations/#data-migrations

/Markus

On June 17, 2015 12:48:48 PM GMT+02:00, Gergely Polonkai  
wrote:
>Hello,
>
>I have created a new model called Settings, which has a
>OneToOneField(User,
>primary_key=True) field. After the automatically created
>migrations.CreateModel() invocation I added a RunPython line that runs
>this
>function:
>
>def create_user_settings(apps, schema_editor):
>User = get_user_model()
>Settings = apps.get_model('accounts', 'Settings')
>
>for user in User.objects.all():
>Settings.objects.get_or_create(user=user) # This is line 13
>
>When running this migration, I get the following error:
>
>Traceback (most recent call last):
>
>  File "manage.py", line 10, in 
>
>execute_from_command_line(sys.argv)
>
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/core/management/__init__.py",
>line 338, in execute_from_command_line
>utility.execute()
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/core/management/__init__.py",
>line 330, in execute
>self.fetch_command(subcommand).run_from_argv(self.argv)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/core/management/base.py",
>line 390, in run_from_argv
>self.execute(*args, **cmd_options)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/core/management/base.py",
>line 441, in execute
>output = self.handle(*args, **options)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
>line 221, in handle
>  executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/migrations/executor.py",
>line 110, in migrate
>self.apply_migration(states[migration], migration, fake=fake,
>fake_initial=fake_initial)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/migrations/executor.py",
>line 147, in apply_migration
>state = migration.apply(state, schema_editor)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/migrations/migration.py",
>line 115, in apply
>  operation.database_forwards(self.app_label, schema_editor, old_state,
>project_state)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/migrations/operations/special.py",
>line 183, in database_forwards
>self.code(from_state.apps, schema_editor)
> File "/home/polesz/Projects/dem/accounts/migrations/0003_settings.py",
>line 13, in create_user_settings
>Settings.objects.get_or_create(user=user)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/manager.py",
>line 127, in manager_method
>return getattr(self.get_queryset(), name)(*args, **kwargs)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/query.py",
>line 405, in get_or_create
>return self.get(**lookup), False
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/query.py",
>line 325, in get
>clone = self.filter(*args, **kwargs)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/query.py",
>line 679, in filter
>return self._filter_or_exclude(False, *args, **kwargs)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/query.py",
>line 697, in _filter_or_exclude
>clone.query.add_q(Q(*args, **kwargs))
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/sql/query.py",
>line 1306, in add_q
>clause, require_inner = self._add_q(where_part, self.used_aliases)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/sql/query.py",
>line 1333, in _add_q
>current_negated=current_negated, connector=connector,
>allow_joins=allow_joins)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/sql/query.py",
>line 1175, in build_filter
>self.check_related_objects(field, value, opts)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/django/db/models/sql/query.py",
>line 1070, in check_related_objects
>self.check_query_object_type(value, opts)
>  File
>"/home/polesz/Projects/dem/venv/lib/python2.7/site-packages/djang

Re: HTTPS on docs.djangoproject.com

[Markus Holtermann]

Hey,

Not on djangoproject.com but you can use http://django.readthedocs.org/

/Markus

On June 12, 2015 8:32:09 PM GMT+02:00, "Davor Lučić"  wrote:
>Hello,
>
>Is it possible to request documentation on docs.djangoproject.com
>without
>HTTPS?
>
>I work for corporation that either blocks or uses MITM certs for HTTPS
>and
>I am unable to access Django documentation since its forcing me to use
>HTTPS even when i request HTTP.
>
>Thank you,
>Davor

-- 
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/4CE6801E-9735-41EE-9F3D-6195F7CBB97F%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: Bug in 1.7-1.8 migrations

[Markus Holtermann]

Which exact Django version did you use for generating and applying the
migrations? 1.7 as well as 1.8 had a few bugs regarding bytestrings.
They have been fixed in 1.7.something and 1.8.something. I'd need to
look up the exact patch version.

/Markus

On Fri, Jun 05, 2015 at 04:29:02AM -0700, Владислав Пискунов wrote:

In 1.7 auto-created migration with makemigrations. it contains:

related_name=b''

Now in 1.8 while migrate, django tries Render model state and fails with:

File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 338, in execute_from_command_line
   utility.execute()
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/core/management/__init__.py",
line 330, in execute
   self.fetch_command(subcommand).run_from_argv(self.argv)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/core/management/base.py",
line 390, in run_from_argv
   self.execute(*args, **cmd_options)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/core/management/base.py",
line 441, in execute
   output = self.handle(*args, **options)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
line 221, in handle
   executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/migrations/executor.py",
line 104, in migrate
   state = migration.mutate_state(state, preserve=do_run)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/migrations/migration.py",
line 83, in mutate_state
   operation.state_forwards(self.app_label, new_state)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/migrations/operations/models.py",
line 158, in state_forwards
   apps = state.apps
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/utils/functional.py",
line 60, in __get__
   res = instance.__dict__[self.name] = self.func(instance)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/migrations/state.py",
line 166, in apps
   return StateApps(self.real_apps, self.models)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/migrations/state.py",
line 232, in __init__
   self.render_multiple(list(models.values()) + self.real_models)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/migrations/state.py",
line 262, in render_multiple
   model.render(self)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/migrations/state.py",
line 546, in render
   body,
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/base.py",
line 189, in __new__
   new_class.add_to_class(obj_name, obj)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/base.py",
line 324, in add_to_class
   value.contribute_to_class(cls, name)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/fields/related.py",
line 1767, in contribute_to_class
   super(ForeignObject, self).contribute_to_class(cls, name,
virtual_only=virtual_only)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/fields/related.py",
line 305, in contribute_to_class
   add_lazy_relation(cls, self, other, resolve_related_class)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/fields/related.py",
line 86, in add_lazy_relation
   operation(field, model, cls)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/fields/related.py",
line 304, in resolve_related_class
   field.do_related_class(model, cls)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/fields/related.py",
line 349, in do_related_class
   self.contribute_to_related_class(other, self.rel)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/fields/related.py",
line 1958, in contribute_to_related_class
   super(ForeignKey, self).contribute_to_related_class(cls, related)
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/fields/related.py",
line 1773, in contribute_to_related_class
   if not self.rel.is_hidden() and not related.related_model._meta.swapped:
 File
"/home/vladislav/.virtualenvs/furskru/local/lib/python2.7/site-packages/django/db/models/fields/related.py&q

Re: Little trouble with migration.

[Markus Holtermann]

No need to apologize. If you think there is anything we can / should add to 
Django's documentation that would have either helped you to figure out the 
issue or that had prevented you from running into the issue in the first 
place, please go ahead and open an issue at https://code.djangoproject.com/ 

/Markus

On Thursday, May 7, 2015 at 3:24:47 PM UTC+2, Алексей Широков wrote:
>
> Oh thank you very much for the clarification. 
> I understood in what there was a mistake. And I apologize for my 
> carelessness.
>
> 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/a642c938-df53-4001-ba1f-0594a93376fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Little trouble with migration.

[Markus Holtermann]

Hey there,

app labels (i.e. what you specify in your AppConfig or in AUTH_USER_MODEL) 
are case sensitive. Thus either change AccountConfig.label to "account" 
(this affects all migrations that depend on your account app) or 
AUTH_USER_MODEL to "Account.User". I'd recommend to use lower case app 
labels

/Markus

On Thursday, May 7, 2015 at 11:39:16 AM UTC+2, Алексей Широков wrote:
>
> I have custom user model.
>
> settings.py
> ---
> ...
> AUTH_USER_MODEL = 'account.User'
> ...
>
>
> also I have following AppConfig
>
> account/apps.py
> ---
>
> class AccountConfig(AppConfig):
> name = 'isar.account'
> *label = 'Account'*
> verbose_name = 'Аккаунт'
>
>
> and when I call command migrate I get the following exception:
>
> ...
> File 
> "/var/venvs/isar-future/local/lib/python2.7/site-packages/django/core/management/__init__.py",
>  
> line 120, in call_command
>   return command.execute(*args, **defaults)
> File 
> "/var/venvs/isar-future/local/lib/python2.7/site-packages/django/core/management/base.py",
>  
> line 441, in execute
>   output = self.handle(*args, **options)
> File 
> "/var/venvs/isar-future/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
>  
> line 93, in handle
>   executor = MigrationExecutor(connection, 
> self.migration_progress_callback)
> File 
> "/var/venvs/isar-future/local/lib/python2.7/site-packages/django/db/migrations/executor.py",
>  
> line 19, in __init__
>   self.loader = MigrationLoader(self.connection)
> File 
> "/var/venvs/isar-future/local/lib/python2.7/site-packages/django/db/migrations/loader.py",
>  
> line 47, in __init__
>   self.build_graph()
> File 
> "/var/venvs/isar-future/local/lib/python2.7/site-packages/django/db/migrations/loader.py",
>  
> line 287, in build_graph
>   parent = self.check_key(parent, key[0])
> File 
> "/var/venvs/isar-future/local/lib/python2.7/site-packages/django/db/migrations/loader.py",
>  
> line 165, in check_key
>   raise ValueError("Dependency on unknown app: %s" % key[0])
> ValueError: Dependency on unknown app: account
>
> I think that the problem here 
> https://github.com/django/django/blob/stable/1.8.x/django/db/migrations/migration.py#L178
>

-- 
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/200c62a7-7c59-4962-bd02-5a4a0b65051a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: “Migrate” command for manage.py not recognised when using Django 1.8

[Markus Holtermann]

Hey Kaya,

I suspect you have South installed and in your INSTALLED_APPS. This is not 
supported. South only supports Django <=1.6 -- Django >=1.7 has built-in 
migration support. Please 
see 
https://docs.djangoproject.com/en/dev/topics/migrations/#upgrading-from-south 
for a migration guide from South to Django migrations.

/Markus

On Thursday, April 30, 2015 at 6:04:38 PM UTC+2, Kaya Luken wrote:
>
> Using "path/to/mySite/manage.py migrate" I get
>
> Unknown command: 'migrate'Type 'manage.py help' for usage.
>
> Listed commands are:
>
> changepassword
>   cleanup
>   compilemessages
>   createcachetable
>   createsuperuser
>   dbshell
>   diffsettings
>   dumpdata
>   flush
>   inspectdb
>   loaddata
>   makemessages
>   reset
>   runfcgi
>   runserver
>   shell
>   sql
>   sqlall
>   sqlclear
>   sqlcustom
>   sqlflush
>   sqlindexes
>   sqlinitialdata
>   sqlreset
>   sqlsequencereset
>   startapp
>   syncdb
>   test
>   testserver
>   validate
>
> I believe "Migrate" was added as a native command for manage.py as of 
> Django 1.7. According to "pip list" and the package documentation I am 
> definitely using Django 1.8 and I explicitly called the correct versions of 
> django-admin.py and manage.py in setup.
>

-- 
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/4bda26ca-1bcf-4b13-9812-508b26cc72e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Slowness of the resulting squashed migration

[Markus Holtermann]

Hi,

In principle it is possible to write your own or modify existing migrations 
unless they are already applied.

Regarding the additional AddField() operations: in case you have e.g. 
circular references between two models Django cannot add both models with 
their full columns at the same time. Django first adds one model without 
the ForeignKey, then the second model including the FK to the first model 
and finally adds the field to the first model pointing to the second model 
[1]. Bottom line: if you find a way to optimize something in your squashed 
migration, feel free to go ahead. It would be helpful if you report this as 
an enhance to our issue tracker [2] so we can include a possible 
improvement in future Django versions.

/Markus

[1] Have a look at slide 14f 
of https://speakerdeck.com/andrewgodwin/migrations-under-the-hood
[2] https://code.djangoproject.com/

On Friday, April 24, 2015 at 8:14:34 PM UTC+2, aRkadeFR wrote:
>
> Hello, 
>
> After working on a project and having around 10 migrations per app, 
> I wanted to refactor some migrations (of the same app) into only one 
> and have a faster migrations while testing. 
>
> I did squashmigrations on many of the migrations, but the resulting 
> squased migration is still pretty slow (around 6 seconds to create 4 
> tables on MySQL 5.5 without any data inserted). 
>
> After looking at the migrations, there is some CreateModel(name='') 
> and after the table creation some AddField on the same table/models... 
>
> I would like to know if it's safe to change the migrations by hand? Is 
> there a reason the squashmigrations didn't refactor into only CreateModel 
> without AddField then? 
>
> Thanks 
>
> 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/c75633dd-b41a-46af-9e72-ced31e2e6885%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.8 data migrations not able to locate related collections

[Markus Holtermann]

Hi A Lee,

I think I've seen that one before. Can you check if the fix 
for https://code.djangoproject.com/ticket/24573 resolves the issue?

/Markus

On Friday, April 17, 2015 at 2:52:26 AM UTC+2, A Lee wrote:
>
> Hello,
>
> After upgrading to 1.8 from 1.7.7 our tests are now unable to create test 
> data via data migrations and complain about related collections not 
> existing as attributes for some but not all models (exception stack trace 
> at https://travis-ci.org/virtualcommons/vcweb). It appears to succeed at 
> creating a model object for the first related collection but then dies when 
> attempting to create objects in the second related collection (
> https://github.com/virtualcommons/vcweb/blob/develop/vcweb/experiment/forestry/migrations/0001_initial_forestry.py#L62
> ). 
>
> Any ideas on what might be causing this? Access to related collections 
> through the django shell and via the web interface still seem to be working 
> fine on 1.8, it's just the data migrations that are failing.
>
>

-- 
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/bbb334b8-6d77-4954-9bb9-800fef266a10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django 1.8 upgrade custom user model syncdb

[Markus Holtermann]

Hey Jochen,

glad it works now. In that case you want to look at
https://docs.djangoproject.com/en/1.8/ref/settings/#migration-modules
and place the migrations somewhere in your project. Otherwise the
migrations end up in your virtualenv and are not available when you
deploy the application.

Best,

/Markus

On Wed, Apr 08, 2015 at 08:32:35AM -0700, Jochen Wersdoerfer wrote:

On Wednesday, April 8, 2015 at 4:56:43 PM UTC+2, Jochen Wersdoerfer wrote:



There’s an initial migration for my custom user model in accounts.models,
so the accounts_pixolususer table should have been created. The syncdb
command breaks while adding a constraint to an app without migrations
(meters), which has a model with a foreign key pointing to my custom user
model.



Ok, got it. Can't have a dependency from an unmigrated app to an
app with migrations. Most of my own and some third party apps were
unmigrated. Had circular dependencies, too. Difficult upgrade. You
can add an initial migration for an umigrated third party app installed
via pip by:

./manage.py makemigrations third_party_app

But now it works \o/ :).

best regards,
Jochen

--
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/3ad4dc51-94c0-41da-addf-cd1676243df7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

--
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/20150408154558.GA3356%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgp9EWuvA9hZm.pgp
Description: PGP signature

Re: Django system check gives error when storing method in variable

[Markus Holtermann]

Hey Wouter,

since Django 1.7 Model.check() is a reserved method that is used by the 
system checks framework 
(https://docs.djangoproject.com/en/1.7/topics/checks/#field-model-and-manager-checks).
 
The cleanest way is to remove that line (check = is_paid). Why do you have 
that in the first place?

/Markus

On Sunday, March 29, 2015 at 6:01:04 PM UTC+2, Wouter Miltenburg wrote:
>
> Hi all, 
>
> Haven't used Django 1.7.7 till today, but whenever I want to launch my 
> project I get the following error: 
> ERRORS: 
> gopro.MyPayment: (models.E020) The 'MyPayment.check()' class method is 
> currently overridden by  0x7f0716731b90>. 
>
> I use another django app 
> (https://github.com/wmiltenburg/django-mollie-ideal) inside the app that 
> I am currently writing. The problem seems to be relating to line 75 in 
> models.py 
> (
> https://github.com/wmiltenburg/django-mollie-ideal/blob/master/mollie/ideal/models.py,
>  
>
> check = is_paid), where is_paid is a method. If I comment it out it 
> works fine. However, this used to work in previous Django releases (1.6) 
> and it is valid Python code. In Django 1.7 it shows the following error: 
> TypeError: is_paid() missing 1 required positional argument: 'self'. 
>
> The error shows up when Django performs the system checks. My guess is 
> that the "system check" from Django 1.7 doesn't handle function 
> referencing in Python well (which used to be in Django 1.6). However, I 
> am wondering if this is a more of a general problem in Django itself and 
> if other users experience the same problem. 
>
> Cheers, 
> Wouter. 
>

-- 
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/591911f5-9f54-4099-82f5-8a9e15b1fa7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: migrations don't work

[Markus Holtermann]

Hi,

from the information you provided I can only guess you are migrating away from 
a custom user model to the "normal" Django user model. This won't work (out of 
the box). And even the way to migrate from the Django user model to a custom 
user model is more of a workaround than a solution. Please see 
https://docs.djangoproject.com/en/dev/topics/auth/customizing/#substituting-a-custom-user-model
 for details.

/Markus

On March 22, 2015 7:16:57 PM GMT+01:00, somenxav...@gmail.com wrote:
>Hi,
>
>makemigrations works but migrate does not:
>
>[xan@mercuri gargamella]$ python manage.py makemigrations
>Migrations for 'quedar':
>  0003_auto_20150322_1813.py:
>- Create model Persona
>- Delete model User
>- Add field user to persona
>- Alter field members on dialectgroup
>- Alter field members on languagelevelgroup
>- Alter field members on learninggroup
>- Alter field members on learningpeople
>- Alter field members on teachinggroup
>[xan@mercuri gargamella]$ python manage.py migrate
>Operations to perform:
>  Apply all migrations: admin, auth, sessions, contenttypes, quedar
>Running migrations:
>Applying quedar.0003_auto_20150322_1813...Traceback (most recent call
>last
>):
>File "/usr/lib/python3.4/site-packages/django/apps/config.py", line
>163, 
>in get_model
>return self.models[model_name.lower()]
>KeyError: 'user'
>
>During handling of the above exception, another exception occurred:
>
>Traceback (most recent call last):
>File "/usr/lib/python3.4/site-packages/django/db/migrations/state.py", 
>line 84, in render
>model = self.apps.get_model(lookup_model[0], lookup_model[1])
>File "/usr/lib/python3.4/site-packages/django/apps/registry.py", line
>202, 
>in get_model
>return self.get_app_config(app_label).get_model(model_name.lower())
>File "/usr/lib/python3.4/site-packages/django/apps/config.py", line
>166, 
>in get_model
>"App '%s' doesn't have a '%s' model." % (self.label, model_name))
>LookupError: App 'quedar' doesn't have a 'user' model.
>
>During handling of the above exception, another exception occurred:
>
>Traceback (most recent call last):
>  File "manage.py", line 10, in 
>execute_from_command_line(sys.argv)
>  File 
>"/usr/lib/python3.4/site-packages/django/core/management/__init__.py",
>line 
>385, in execute_from_command_line
>utility.execute()
>  File 
>"/usr/lib/python3.4/site-packages/django/core/management/__init__.py",
>line 
>377, in execute
>self.fetch_command(subcommand).run_from_argv(self.argv)
>File "/usr/lib/python3.4/site-packages/django/core/management/base.py",
>
>line 288, in run_from_argv
>self.execute(*args, **options.__dict__)
>File "/usr/lib/python3.4/site-packages/django/core/management/base.py",
>
>line 338, in execute
>output = self.handle(*args, **options)
>  File 
>"/usr/lib/python3.4/site-packages/django/core/management/commands/migrate.py",
>
>line 161, in handle
>executor.migrate(targets, plan, fake=options.get("fake", False))
>File
>"/usr/lib/python3.4/site-packages/django/db/migrations/executor.py", 
>line 68, in migrate
>self.apply_migration(migration, fake=fake)
>File
>"/usr/lib/python3.4/site-packages/django/db/migrations/executor.py", 
>line 102, in apply_migration
>migration.apply(project_state, schema_editor)
>  File 
>"/usr/lib/python3.4/site-packages/django/db/migrations/migration.py",
>line 
>108, in apply
>operation.database_forwards(self.app_label, schema_editor, 
>project_state, new_state)
>  File 
>"/usr/lib/python3.4/site-packages/django/db/migrations/operations/fields.py",
>
>line 29, in database_forwards
>to_model = to_state.render().get_model(app_label, self.model_name)
>File "/usr/lib/python3.4/site-packages/django/db/migrations/state.py", 
>line 94, in render
>raise ValueError(msg.format(field=operations[0][1],
>model=lookup_model))
>ValueError: Lookup failed for model referenced by field 
>quedar.LearningGroup.members: quedar.User
>[xan@mercuri gargamella]$ 
>
>
>
>Any hints?

-- 
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/97C9627D-9E65-4943-8BD7-6069E3288383%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: [ANNOUNCE] Security releases and advisory issued (1.7.6 and 1.8b2)

[Markus Holtermann]

Hey Francis,

with respect to the ModelAdmin.readonly_fields: no, the vulnerability was 
introduced in 1.7

with respect to the advisory: yes, all projects that make use the template 
filters in Python code and rely on Django 1.0 to 1.8b1 (including) are 
vulnerable.

Best,

/Markus

On Monday, March 9, 2015 at 5:24:57 PM UTC+1, Francis Devereux wrote:
>
> Hi, 
>
> On 9 Mar 2015, at 16:01, Tim Graham > 
> wrote: 
> > 
> > Today the Django team issued multiple releases -- Django 1.7.6 and 1.8b2 
> -- as part of our security process. These releases address a publicly 
> reported security issue, and we encourage all users to upgrade as soon as 
> possible. 
>
> Thanks for these fixes. 
>
> Is Django 1.6.x affected vulnerable to these issues? 
>
> Francis 
>
>

-- 
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/c5ab21cd-81df-425b-8d43-103606f54864%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Release announcements?

[Markus Holtermann]

Hey Anton,

You can find the release roadmap 
at https://code.djangoproject.com/wiki/Version1.8Roadmap

The current plan is to issue the beta on Friday, given that all current 
release blockers are fixed. There is a topic about the 1.8 release blockers 
on the django-developers mailing 
list: https://groups.google.com/forum/#!topic/django-developers/74_MZK27TAE

There is also the django-announce mailing list that just mentions all 
releases: https://groups.google.com/forum/#!forum/django-announce . The 
link to the RSS of our blog is https://www.djangoproject.com/rss/weblog/ 
which will also mention the beta release.

/Markus

On Wednesday, February 18, 2015 at 7:00:50 PM UTC+1, Anton Melser wrote:
>
> Hi,
>
> I have started a new project on 1.8 and am looking for an RSS or mailing 
> list that has release announcements for Django proper - is there anything? 
> My understanding was that the first Beta was supposed to come out on the 16 
> Feb, is that right?
>
> Thanks!
> Anton
>

-- 
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/d58b2d51-a5ca-4368-a3fe-50df55c46048%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrating to initial migration: "ORA-00955: name is already used by an existing object"

[Markus Holtermann]

Hey Carsten,

Did you see the chapter at the end of the page you linked to: Upgrading from 
South: 
https://docs.djangoproject.com/en/1.7/topics/migrations/#upgrading-from-south

1. Make sure the database schema defined by your models (and Django migrations) 
exactly matches the one in the database (this includes null constraints, 
indexes, etc.) to prevent errors in the future

2. Run "manage.py migrate --fake"

/Markus

On February 2, 2015 10:50:14 PM GMT+01:00, Carsten Fuchs 
 wrote:
>Dear Django developers,
>
>in a Django project that was created pre-1.7, did not use South before,
>
>and was recently upgraded to Django 1.7 and is otherwise fine, I'm now 
>trying to convert it to use migrations, following the docs at 
><https://docs.djangoproject.com/en/1.7/topics/migrations/#adding-migrations-to-apps>.
>
>It seems that creating the initial migrations with `makemigrations` 
>works well, but the first run of `migrate` aborts with error 
>"django.db.utils.DatabaseError: ORA-00955: name is already used by an 
>existing object". Please see the full output below.
>
>Unfortunately, I don't know enough about migrations to be able to debug
>
>this myself, or to understand what the problem is.
>
>What are good next steps, or where should I look for the cause of this 
>problem?
>
>Best regards,
>Carsten
>
>
>
>(Zeiterfassung)carsten@blue-ring-ubuntu:~/Zeiterfassung$ rm -rf 
>Lori/migrations/
>
>(Zeiterfassung)carsten@blue-ring-ubuntu:~/Zeiterfassung$ ./manage.py 
>makemigrations Lori
>Migrations for 'Lori':
>   0001_initial.py:
> - Create model AUB
> - Create model Ausbezahlt
> - Create model Aushilfslohn
> - Create model Bereich
> - Create model Code
> - Create model Erfasst
> - Create model KalenderEintrag
> - Create model Kostenstelle
> - Create model Mitarbeiter
> - Create model MonatsSalden
> - Create model Oeffnungszeiten
> - Create model PekoBenchmarkCache
> - Create model PekoGewichte
> - Create model Region
> - Create model Schicht
> - Create model Status
> - Create model SystemEmailEmpfaenger
> - Create model TempMaBereichZuordnung
> - Create model Termin
> - Create model Umsatzgruppe
> - Create model UserProfile
> - Create model Vertragsverlauf
> - Create model Vorblendplan
> - Create model Vortraege
> - Alter unique_together for schicht (1 constraint(s))
> - Add field region to pekogewichte
> - Add field fil_gruppe to pekobenchmarkcache
> - Alter unique_together for pekobenchmarkcache (1 constraint(s))
> - Alter unique_together for monatssalden (1 constraint(s))
> - Add field tmp_bereiche to mitarbeiter
> - Add field vbp_neu to mitarbeiter
> - Add field fil_gruppe to kostenstelle
> - Add field parent to kostenstelle
> - Add field region to kostenstelle
> - Add field kstellen to kalendereintrag
> - Add field regionen to kalendereintrag
> - Add field key to erfasst
> - Add field last_user to erfasst
> - Add field status to erfasst
> - Alter unique_together for erfasst (1 constraint(s))
> - Add field region to bereich
> - Add field key to ausbezahlt
> - Alter unique_together for ausbezahlt (1 constraint(s))
> - Add field ma to aub
>
>(Zeiterfassung)carsten@blue-ring-ubuntu:~/Zeiterfassung$ ./manage.py
>migrate
>Operations to perform:
>   Apply all migrations: admin, contenttypes, Lori, auth, sessions
>Running migrations:
>   Applying Lori.0001_initial...Traceback (most recent call last):
>   File "./manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File 
>"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/__init__.py",
>
>line 385, in execute_from_command_line
> utility.execute()
>   File 
>"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/__init__.py",
>
>line 377, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File 
>"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/base.py",
>
>line 288, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File 
>"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/base.py",
>
>line 338, in execute
> output = self.handle(*args, **options)
>   File 
>"/home/carsten/.virtualenvs/Zeiterfassung/local/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
>
>line 161, in handle
>   

Re: Slow test startup under Django 1.7

[Markus Holtermann]

Hey Warren,

this is a known problem in 1.7. It is fixed in 1.8 
(see https://code.djangoproject.com/ticket/23745). Unfortunately, the 
changes made to reduce the amount of get_models() and render() calls are 
too invasive to backport them to 1.7.

If you have the time, could you try running your project on the 1.8 alpha 
version and check the changes out and provide some feedback on how that 
turned out?

Thanks in advance.

/Markus

On Thursday, January 22, 2015 at 9:47:22 PM UTC+1, Warren Smith wrote:
>
> I'm in the process of converting a large legacy app from Django 1.5 to 
> 1.7. I've got all the tests passing, so I'm researching an issue I noticed 
> during the course of my work: Test startup takes MUCH longer under Django 
> 1.7 than it did under 1.5. I've got a test that, when run by itself, took a 
> total of 5 seconds under 1.5. Under 1.7 it takes over a minute.
>
> To isolate the test startup, I setup a do-nothing test method within a 
> subclass of django.test.TestCase. I ran it under Django 1.5 and 1.7 with 
> similar results to the existing "real" test.
>
> I ran the do-nothing test within cProfile under Django 1.7 and found 
> something very interesting. According to pstats, the method 
> django.apps.config.AppConfig.get_models() was called 2.2+ MILLION times. 
> Even with 79 django apps in my INSTALLED_APPS setting, that seems excessive.
>
> I read the Django 1.7 release notes, especially the App Config stuff. I 
> noticed the warning about not importing models in the application root 
> module. I went through all of our internal apps and made sure they were not 
> importing models in the root module. I had to make some changes, moving 
> imports inside functions/methods. I also looked at my third-party 
> dependency apps. None of those were importing their models in their root 
> modules.
>
> After all that, though, I still see no change in behavior.
>
> I thought I might have some loop happening somewhere, though why it wasn't 
> infinite was interesting. It would be nice to know more about the context 
> of those get_models() calls. Perhaps I had a couple of mis-behaving apps 
> locked in a deadly embrace of some sort.
>
> I hacked on my locally installed django.apps.config.AppConfig class, 
> adding a class-level collections.Counter that gets incremented for 
> self.label by the get_models() method.
> I dumped the results to a json file within my do-nothing test. It wouldn't 
> be comprehensive, but at least it would show me what had happened before 
> the test ran.
>
> I expected to see a few big numbers and a lot of small ones. As often 
> happens when profiling, my expectations were completely wrong. All the 
> counts were very similar, all in the 6000-7999 range. All 79 of my apps 
> were represented.
>
> Is there some sort of cartesian product going on here?
>
> Is this behavior normal and expected?
>
>

-- 
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/147b99c8-a70f-4c27-82f5-be5e2710d4eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Data migration fails because contenttypes not yet ready

[Markus Holtermann]

Hi,

first of all, both, update_all_contenttypes and create_permissions, expect 
their respective app to be migrated completely in order to work as of 
1.7.4 
(https://github.com/django/django/commit/478546fcef38d95866a92bc44d10e15b26c7254c).

The "serialize model manager in migrations" issue, which is part of 1.8, 
will allow you to use custom methods on your model manager inside 
`RunPython` (e.g `MyUser.objects.create_a_fancy_user_account()`) and isn't 
related to the problem you are running into.

The sanest way to generate all ContentTypes and Permissions is to migrate 
those two apps explicitly before migrating the remaining apps:

$ python manage.py migrate contenttypes
$ python manage.py migrate auth
$ python manage.py migrate


That way you can make sure the contenttypes app is completely migrated and 
all contenttypes are created, the auth app is completely migrated and all 
permission are created, and last but not least the remaining apps should 
smoothly migrate forwards. There are thoughts about putting the migration 
graph and the respective model states before/after all migrations into the 
pre/post_migrate signals (#24100) as well as initial ideas emitting a 
signal after each migration (no ticket yet afaik). The latter could be used 
to tackle the above problem.

If you want to create a specific permission during a migration, do the 
following in `RunPython`:

def forwards(apps, schema_editor): 

Permission = apps.get_model('auth', 'Permission')

Permission.objects.create(...)


This is also the way to load initial data starting Django 1.7: using 
`RunPython` or `RunSQL`.

The django-migration-fixture app seems to do some crazy stuff in the 
management command that I'm not going to speculate about how long it's 
going to work. That is completely undocumented and internal API. Apart from 
that, the (de)serializers in django.core.serializers (specifically 
.python.Deserializer) use the global apps for deserialization. Thus, a 
fixture referring to a model that is later removed/renamed, or refers to a 
field that doesn't exist later or must not be null, cannot be applied when 
you run the migrations on an empty database.

/Markus

On Thursday, January 22, 2015 at 12:43:33 PM UTC+1, Daniel Hahler wrote:
>
> Hello,
>
> I was having the same issue as Torsten: it does not appear to be possible 
> to load initial data related to contenttypes or auth during migrations.
>
> As for the problem with contenttypes reported by Torsten, a workaround 
> appears to be calling `update_all_contenttypes` manually from your 
> migration (from django.contrib.contenttypes.management).
>
> But then there's the problem with creating auth.groups.
>
> I've tried the following via `RunPython`:
>
> from django.contrib.auth.management import create_permissions
> create_permissions(apps.get_app_config('auth'), verbosity=0)
>
> This aborts because `app_config.models_module` is None:
>
> app_config.__dict__
> {'models_module': None, 'name': 'auth', 'models': 
> OrderedDict([('group_permissions', ), ...]), 
> 'module': None, 'label': 'auth', 'verbose_name': 'Auth'}
>
> Is this related to https://code.djangoproject.com/ticket/23822 
> ("Serialize model managers in migrations"), and would be possible in Django 
> 1.8?
>
> I am trying to use https://github.com/alexhayes/django-migration-fixture, 
> which is meant to provide a convenient wrapper around the initial_data 
> fixtures (files). My PR with the changes mentioned above is viewable at: 
> https://github.com/alexhayes/django-migration-fixture/pull/2/files.
>
> What is the suggested way to have initial data with Django 1.7, given that 
> initial_data is not used for apps with migrations, and RunPython has the 
> above shortcomings?
>
>
> Thanks,
> Daniel.
>
> Am Dienstag, 21. Oktober 2014 19:42:34 UTC+2 schrieb Torsten Bronger:
>>
>> Hallöchen! 
>>
>> Markus Holtermann writes: 
>>
>> > Are you talking about Django 1.7 migrations or South? In the 
>> > former case you need to make sure that your datamigration depends 
>> > on the contenttypes application. 
>>
>> I'm talking about Django 1.7 migrations.  Unfortunately, 
>> contenttypes is already migrated before my app.  But this doesn't 
>> help because update_all_contenttypes is a post_migrate signal. 
>>
>> Tschö, 
>> Torsten. 
>>
>> -- 
>> Torsten BrongerJabber ID: torsten...@jabber.rwth-aachen.de 
>>   or http://bronger-jmp.appspot.com 
>>
>>

-- 
You received this message because you are subscribed to the Google G

Re: do migrations (Django 1.7+) handle production data?

[Markus Holtermann]

Hey Abraham,

to be more specific, when you used South and ran "manage.py
datamigration" [1] you got an empty migration file with a forwards and
backwards method where you had to fill out the blanks and tell South
what to do, e.g. to create a certain object in the database.

With Django's migration system you get the same with running "manage.py
makemigrations --empty". Django will generate an empty migration file
that you can fill with the operations to run.

Django offers "migrations.RunPython" to run arbitrary Python code, and
"migrations.RunSQL" do perform raw SQL queries. (For documentation
please see the links Russell send earlier).

Best

/Markus

[1] http://south.readthedocs.org/en/latest/commands.html#datamigration

On 01/14/2015 01:43 PM, James Bennett wrote:
> On Wed, Jan 14, 2015 at 6:34 AM, Abraham Varricatt <
> abraham.varric...@googlemail.com> wrote:
> 
> To be more specific, the document you link clearly mentions that "Django
>> can’t automatically generate data migrations for you"
>>
>>
>> And this is what puzzles me. If it isn't automated and is something that
>> needs to be done manually, what's so great about it's inclusion in Django
>> 1.7?
>>
> 
> Django cannot read your mind to figure out what specific changes to your
> data you'd like to have happen. So writing the logic of the data migration
> is up to you.
> 
> Django *can* usually deduce the necessary schema changes from examining
> what the models looked like before and after. And that's the difference.
> 

-- 
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/54B66F6C.1000607%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: malicious requests?

[Markus Holtermann]

Hey Alex,

a trailing . in the host header is valid per RFC 3986: 
http://tools.ietf.org/html/rfc3986#section-3.2.2:

The rightmost domain label of a fully qualified domain name in DNS may be 
> followed by a single "."


/Markus 

On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote:
>
> Are there any known attack vectors that involve appending a period/ 
> full-stop to a sites domain name? 
>
> My Django application throws a handful of errors in production every day: 
>
> ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to add 
> u'www.example.com.' to ALLOWED_HOSTS. 
>
> (note the trailing period) 
>
> Is this malicious behaviour, or just users mistyping the URL? 
>
> Also, browsers are clearly treating the final '.' as part of the path 
> (as these requests are reaching my application), but Django is treating 
> the '.' as part of the hostname. Which is right? 
>
> -- 
> Regards, 
>
>
> Alex 
>

-- 
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/0ff75680-cdc4-49d8-8bdd-c4d727213921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to make a migration irreversible [1.7]

[Markus Holtermann]

Hey Bibhas,

thank you for the report. I can verify that behavior and would classify it 
as a release blocker since it leads to potential data loss. Can you open a 
ticket on https://code.djangoproject.com/ please.

In general a migration is a collection of operations. The migration will 
only be unapplied if all operations are reversible. There is no direct way 
to prevent a migration (file) to be unapplied. I'm not sure if it's worth 
to add a property / attribute to the migration class to centralize that 
check. You could open a ticket as well.

As a workaround you can add "migrations.RunPython(lambda apps, 
schema_editor: None)" as first operation in the operations list for that 
migration. It is a noop in forwards migrations and not reversible. But in 
adding a RunPython operation you will lose the ability to squash migrations.

/Markus

On Sunday, December 21, 2014 1:32:29 PM UTC+1, Bibhas wrote:
>
> Hi,
>
> I need to make a migration irreversible. And strangely I don't see any way 
> to do it in the migration doc. I see that the Operation class has a 
> property called `reversible`, but don't see any way to set it to False.
>
> I had a legacy model that was generated with inspectdb, hence it had 
> managed=False. But now when I Need to make changes to it I removed the 
> managed flag and the migration is trying to delete the table and create it 
> again. I removed the droptable operation and faked the migration to avoid 
> the error. But if I revert the migration, that table is going to be dropped 
> anyway, right? Because it's the revert operation of CreateTable. How do I 
> stop the backward migration for this particular migration? There is nothing 
> much important before it, so it's not a trouble if it's irreversible.
>
> Am I missing something really obvious?
>
> Thanks,
> Bibhas
>

-- 
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/6cbcca9e-d60d-419d-874c-e5d234e7c6a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Where to put my bugfix tests?

[Markus Holtermann]

Hey,

Thank you for contributing. I would add the tests to somewhere in 
"tests/validation/".

/Markus

P.S.: You might want to use the django-developers mailing list for 
questions or discussion of the development of Django itself in the future.

On Sunday, December 21, 2014 3:13:55 AM UTC+1, Андрей Маслов wrote:
>
> Hello everyone.
>
> I decided to make my first bugfix :)
> Ticket: https://code.djangoproject.com/ticket/24008
>
> And I have a question for where to put my tests?
> Should I create a new file?
> Or take already written and add my code (unfortunately I did not find 
> anything related to ValidationError testing)?
>
> Thanks in advance.
>

-- 
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/58d01733-2474-4bb9-a935-0d5c8eaae0db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7: How to migrate data between two external apps

[Markus Holtermann]

I agree, a general "here's how you should do it" section in the docs should 
be added. Would you mind opening a ticket on 
https://code.djangoproject.com/ where you state the problem (e.g. link to 
this discussion). Thanks.

/Markus

On Wednesday, December 17, 2014 6:01:05 AM UTC+1, John-Scott wrote:
>
> My 'solution' was very smelly:
>
>- created the migration in 'my_app' as mentioned in my previous post
>- pushed this change to production to run
>- removed 'foo_tag' from INSTALLED_APPS *AND* deleted the migration 
>file (which meant also manually deleting the history of this migration 
> from 
>the django_migrations table).
>
> It was hard to hold my nose through this experience but it worked. Would 
> be great to have a general solution that could be shared with others but in 
> the meantime, I'll settle for being able to get on with the rest of my life.
>
> On Tuesday, December 16, 2014 9:05:35 AM UTC-5, Markus Holtermann wrote:
>>
>> Hey John-Scott,
>>
>> I'm afraid but I don't see an obvious solution. There are 2 ways you 
>> could work on the issue, I don't like either:
>>
>> 1. remove all references to the "foo_tag" app from all migration files
>>
>> 2. make use of the MIGRATION_MODULES settings:
>>
>> 2.1. create a package "path.to.foo_tag_legacy"
>> 2.2. inside create an empty migration "0001_initial"
>> 2.3. define MIGRATION_MODULES={"foo_tag": "path.to.foo_tag_legacy"}
>>
>> As said, both seem ugly to me. I don't know which way I'd proceed.
>>
>> You might get it working by squashing migrations, but certainly not 
>> without manually writing those migration files.
>>
>> /Markus
>>
>> On Saturday, December 13, 2014 6:26:17 PM UTC+1, John-Scott wrote:
>>>
>>> Say I decided to switch from a third party app foo-tags to app bar-tags. 
>>> Their Tag models are mostly identical so I just need to move the data from 
>>> foo-tag to bar-tag. Since I don't control their migrations, I'd need to 
>>> create a migration in one of my own apps:
>>>
>>> ./manage.py makemigrations my_app --empty
>>>
>>> In this migration I'd need to explicitly list the dependencies on these 
>>> external apps (otherwise was getting errors that the foo and bar apps were 
>>> not available in the app registry):
>>>
>>> # -*- coding: utf-8 -*-
>>> from __future__ import unicode_literals
>>>
>>> from django.db import models, migrations
>>>
>>> def migrate_tags(apps, schema_editor):
>>> FooTag = apps.get_model('foo_tag', 'FooTag')
>>> BarTag = apps.get_model('bar_tag', 'BarTag')
>>> for old_tag in FooTag.objects.all():
>>> new_tag = BarTag.objects.create(name=old_tag.name)
>>>
>>> class Migration(migrations.Migration):
>>> dependencies = [
>>> ('my_app', '0001_initial'),
>>> ('foo_tag', '0001_initial'),
>>> ('bar_tag', '0001_initial'),
>>> ]
>>>
>>> operations = [
>>> migrations.RunPython(migrate_tags)
>>> ]
>>>
>>>
>>> The migration itself works as expected. However if I now remove foo_tag 
>>> from INSTALLED_APPS, Django will now give an error:
>>>
>>> KeyError: "Migration my_app.0002_auto_20141212_1951 dependencies 
>>> reference nonexistent parent node ('foo_tag', '0001_initial')"
>>>
>>> What's the correct way to handle migrating data between 3rd party apps 
>>> where one of the apps is eventually removed?
>>>
>>> Thanks,
>>> John-Scott
>>>
>>

-- 
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/a2a0cce2-6226-4b24-8c7d-bce7fbf74aae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7: How to migrate data between two external apps

[Markus Holtermann]

Hey John-Scott,

I'm afraid but I don't see an obvious solution. There are 2 ways you could 
work on the issue, I don't like either:

1. remove all references to the "foo_tag" app from all migration files

2. make use of the MIGRATION_MODULES settings:

2.1. create a package "path.to.foo_tag_legacy"
2.2. inside create an empty migration "0001_initial"
2.3. define MIGRATION_MODULES={"foo_tag": "path.to.foo_tag_legacy"}

As said, both seem ugly to me. I don't know which way I'd proceed.

You might get it working by squashing migrations, but certainly not without 
manually writing those migration files.

/Markus

On Saturday, December 13, 2014 6:26:17 PM UTC+1, John-Scott wrote:
>
> Say I decided to switch from a third party app foo-tags to app bar-tags. 
> Their Tag models are mostly identical so I just need to move the data from 
> foo-tag to bar-tag. Since I don't control their migrations, I'd need to 
> create a migration in one of my own apps:
>
> ./manage.py makemigrations my_app --empty
>
> In this migration I'd need to explicitly list the dependencies on these 
> external apps (otherwise was getting errors that the foo and bar apps were 
> not available in the app registry):
>
> # -*- coding: utf-8 -*-
> from __future__ import unicode_literals
>
> from django.db import models, migrations
>
> def migrate_tags(apps, schema_editor):
> FooTag = apps.get_model('foo_tag', 'FooTag')
> BarTag = apps.get_model('bar_tag', 'BarTag')
> for old_tag in FooTag.objects.all():
> new_tag = BarTag.objects.create(name=old_tag.name)
>
> class Migration(migrations.Migration):
> dependencies = [
> ('my_app', '0001_initial'),
> ('foo_tag', '0001_initial'),
> ('bar_tag', '0001_initial'),
> ]
>
> operations = [
> migrations.RunPython(migrate_tags)
> ]
>
>
> The migration itself works as expected. However if I now remove foo_tag 
> from INSTALLED_APPS, Django will now give an error:
>
> KeyError: "Migration my_app.0002_auto_20141212_1951 dependencies 
> reference nonexistent parent node ('foo_tag', '0001_initial')"
>
> What's the correct way to handle migrating data between 3rd party apps 
> where one of the apps is eventually removed?
>
> Thanks,
> John-Scott
>

-- 
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/79ab531b-da9c-46b8-ba03-11afeb6906d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multi-table inheritance and primary keys

[Markus Holtermann]

Hey folks,

Tim thankfully merged my patch and backported it to 1.7. You could check 
out Django's stable/1.7.x branch to see if that solves your problem.

/Markus

On Thursday, December 11, 2014 2:21:41 PM UTC+1, Torsten Bronger wrote:
>
> Hallöchen! 
>
> Markus Holtermann writes: 
>
> > It looks like you ran into the bug reported as 
> > https://code.djangoproject.com/ticket/23956 . See my comment #6 
> > for a workaround. 
>
> Thank you for the pointer, this is it indeed.  I commented there. 
>
> Regards, 
> Torsten. 
>
> -- 
> Torsten BrongerJabber ID: torsten...@jabber.rwth-aachen.de 
>  
>   or http://bronger-jmp.appspot.com 
>
>

-- 
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/5a794ffb-143a-4bf6-bc78-d9055265d50b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multi-table inheritance and primary keys

[Markus Holtermann]

Hey Torsten,

It looks like you ran into the bug reported as 
https://code.djangoproject.com/ticket/23956 . See my comment #6 for a 
workaround.

/Markus

On Thursday, December 11, 2014 11:01:51 AM UTC+1, Torsten Bronger wrote:
>
> Hallöchen! 
>
> Is it correct that when using multi-table inheritance, I must not 
> set an explicit primary key in the derived model class?  Currently, 
> I get 
>
>   ... 
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/db/backends/utils.py", line 
> 65, in execute 
> return self.cursor.execute(sql, params) 
> django.db.utils.ProgrammingError: column "process_ptr_id" of relation 
> "samples_deposition" already exists 
>
> while applying the initial migration and wonder whether that what I 
> try to achive is possible at all. 
>
> ("samples" is the app name, "deposition" is the model name of the 
> derived model.) 
>
> Tschö, 
> Torsten. 
>
> -- 
> Torsten BrongerJabber ID: torsten...@jabber.rwth-aachen.de 
>  
>   or http://bronger-jmp.appspot.com 
>
>

-- 
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/d6975c8a-7944-4b00-970c-742289f8069e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changes to Model does not migrate to sqlite with Django 1.7?

[Markus Holtermann]

I tried to reproduce the problem with the steps you explained, but it works 
fine for me. Can you post your existing migration files for that app too, 
please. This will then hopefully give us some hints to solve your problem.

On Monday, December 8, 2014 12:07:11 PM UTC+1, Tobias Dacoir wrote:
>
> Ok, here is part of the User Model:
>
> class User(AbstractBaseUser, PermissionsMixin):
>
> SEX = (
> ('m', 'male'),
> ('f', 'female')
> )
>
> RANG = (
> ('b', 'beginner'),
> ('e', 'expert'),
> ('m', 'master')
> )
>
> username = models.CharField(_('username'), max_length=30, unique=True,
> help_text=_('Required. 30 characters or 
> fewer. Letters, numbers and @/./+/-/_ characters'),
> validators=[
> validators.RegexValidator(re.compile(
> '^[\w.@+-]+$'), _('Enter a valid username.'), _('invalid'))
> ])
> first_name = models.CharField(_('first name'), max_length=30, blank=
> True, null=True)
> last_name = models.CharField(_('last name'), max_length=30, blank=True
> , null=True)
> email = models.EmailField(_('email address'), max_length=255, unique=
> True)
>
> is_staff = models.BooleanField(_('staff status'), default=False,
>help_text=_('Designates whether the 
> user can log into this admin site.'))
>
> is_active = models.BooleanField(_('active'), default=True,
> help_text=_('Designates whether this 
> user should be treated as active. Unselect this instead of deleting 
> accounts.'))
> date_joined = models.DateTimeField(_('date joined'), default=timezone.
> now)
> expires = models.DateTimeField(_('expiration date'), default=
> one_year_from_now)
>
> age = models.IntegerField(blank=True, null=True)
> sex = models.CharField(max_length=1, choices=SEX, blank=True)
> native_language = models.CharField(max_length=200, blank=True)
> english_proficiency = models.CharField(max_length=100, blank=True)
> audio_device = models.CharField(max_length=200, blank=True)
> autoplay_enabled = models.BooleanField(default=True)
>
> USERNAME_FIELD = 'username'
> REQUIRED_FIELDS = ['email', ]
>
> objects = UserManager()
>
> class Meta:
> verbose_name = _('user')
> verbose_name_plural = _('users')
>
> def get_full_name(self):
> full_name = '%s %s' % (self.first_name, self.last_name)
> return full_name.strip()
>
> def get_short_name(self):
> return self.first_name
>
> """
> def is_active(self):
> return timezone.now() <= self.expires
> """
>
> def email_user(self, subject, message, from_email=None):
> send_mail(subject, message, from_email, [self.email])
>
>
>
> (I removed some unrelated fields).
> Now what I did was add the autoplay_enabled feature yesterday which wasn't 
> there before. After adding this field, I saved the models.py ran manage.py 
> makemigrations (no changes detected) and then still tried to run manage.py 
> migrate.
> After starting the server when I tried to log into the Admin panel with 
> the Admin user (the DB was already populated by the Admin user, two more 
> users and other stuff) it gave me an OperationalError: column 
> autoplay_enabled does not exist. 
>
> This happened to me a lot of times when I added new fields to any of the 
> models. I ended up writing a script that pre-populates the DB for me but I 
> still have to manually delete my sqlite file, run migrations or syncdb and 
> then create the superuser again. 
>
> So what am I doing wrong? I'm sure it's just my fault. At first I even 
> manually edited the migrations file in the past, for example when I changed 
> one of the fields to be mandatory instead of being optional. Old data in 
> the database had this field still set to null, and sometimes Django asked 
> me what to do with it but most of the time I never got it to work correctly 
> - so again delete DB and repeat.
>

-- 
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/c31766bb-c639-476d-9c6c-010de12c77df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changes to Model does not migrate to sqlite with Django 1.7?

[Markus Holtermann]

A model is always uniquely identified by its app label and model name. 
Since migrations use that I don't see a way how this could happen. If you 
have two apps with the same app label the AppRegistry will blow up (and 
prevents Django from starting).

On Monday, December 8, 2014 12:15:30 PM UTC+1, James Schneider wrote:
>
> I have to wonder if the name of your class is causing an overlap with the 
> Django contrib model, which may be causing confusion with the migrations 
> process and not catching changes (since the core contrib version doesn't 
> have any changes).
>
> Would it be possible to change the name of the class, even for testing?
> On Dec 8, 2014 3:07 AM, "Tobias Dacoir" > 
> wrote:
>
>> Ok, here is part of the User Model:
>>
>> class User(AbstractBaseUser, PermissionsMixin):
>>
>> SEX = (
>> ('m', 'male'),
>> ('f', 'female')
>> )
>>
>> RANG = (
>> ('b', 'beginner'),
>> ('e', 'expert'),
>> ('m', 'master')
>> )
>>
>> username = models.CharField(_('username'), max_length=30, unique=True
>> ,
>> help_text=_('Required. 30 characters or 
>> fewer. Letters, numbers and @/./+/-/_ characters'),
>> validators=[
>> validators.RegexValidator(re.compile(
>> '^[\w.@+-]+$'), _('Enter a valid username.'), _('invalid'))
>> ])
>> first_name = models.CharField(_('first name'), max_length=30, blank=
>> True, null=True)
>> last_name = models.CharField(_('last name'), max_length=30, blank=
>> True, null=True)
>> email = models.EmailField(_('email address'), max_length=255, unique=
>> True)
>>
>> is_staff = models.BooleanField(_('staff status'), default=False,
>>help_text=_('Designates whether the 
>> user can log into this admin site.'))
>>
>> is_active = models.BooleanField(_('active'), default=True,
>> help_text=_('Designates whether this 
>> user should be treated as active. Unselect this instead of deleting 
>> accounts.'))
>> date_joined = models.DateTimeField(_('date joined'), default=timezone
>> .now)
>> expires = models.DateTimeField(_('expiration date'), default=
>> one_year_from_now)
>>
>> age = models.IntegerField(blank=True, null=True)
>> sex = models.CharField(max_length=1, choices=SEX, blank=True)
>> native_language = models.CharField(max_length=200, blank=True)
>> english_proficiency = models.CharField(max_length=100, blank=True)
>> audio_device = models.CharField(max_length=200, blank=True)
>> autoplay_enabled = models.BooleanField(default=True)
>>
>> USERNAME_FIELD = 'username'
>> REQUIRED_FIELDS = ['email', ]
>>
>> objects = UserManager()
>>
>> class Meta:
>> verbose_name = _('user')
>> verbose_name_plural = _('users')
>>
>> def get_full_name(self):
>> full_name = '%s %s' % (self.first_name, self.last_name)
>> return full_name.strip()
>>
>> def get_short_name(self):
>> return self.first_name
>>
>> """
>> def is_active(self):
>> return timezone.now() <= self.expires
>> """
>>
>> def email_user(self, subject, message, from_email=None):
>> send_mail(subject, message, from_email, [self.email])
>>
>>
>>
>> (I removed some unrelated fields).
>> Now what I did was add the autoplay_enabled feature yesterday which 
>> wasn't there before. After adding this field, I saved the models.py ran 
>> manage.py makemigrations (no changes detected) and then still tried to run 
>> manage.py migrate.
>> After starting the server when I tried to log into the Admin panel with 
>> the Admin user (the DB was already populated by the Admin user, two more 
>> users and other stuff) it gave me an OperationalError: column 
>> autoplay_enabled does not exist. 
>>
>> This happened to me a lot of times when I added new fields to any of the 
>> models. I ended up writing a script that pre-populates the DB for me but I 
>> still have to manually delete my sqlite file, run migrations or syncdb and 
>> then create the superuser again. 
>>
>> So what am I doing wrong? I'm sure it's just my fault. At first I even 
>> manually edited the migrations file in the past, for example when I changed 
>> one of the fields to be mandatory instead of being optional. Old data in 
>> the database had this field still set to null, and sometimes Django asked 
>> me what to do with it but most of the time I never got it to work correctly 
>> - so again delete DB and repeat.
>>
>> -- 
>> 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.

Re: Changes to Model does not migrate to sqlite with Django 1.7?

[Markus Holtermann]

Hi Tobias,

can you share the code for your old model and you new model along with the 
existing migrations for that app, please. Without some details it's hard to 
figure out what's happening.

/Markus

On Monday, December 8, 2014 8:23:33 AM UTC+1, Tobias Dacoir wrote:
>
> Hi,
>
> I'm having trouble with changes to my Models. I just added a couple of new 
> fields to my existing models but when I run manage makemigrations it says: 
> No changes detected. When I try to log in to the admin panel it gives an 
> operational error and says: No such column (because I added a column to my 
> user model). I have tried to get rid of this error using google and various 
> calls to makemigrations app_name or syncdb or whatever, but nothing helps. 
> I always have to delete my sqlite database file and start with a new DB. 
>
> Is this a limitation of sqlite or some bug in Django?
>

-- 
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/d9a7f2a4-7122-4d2e-be52-7836f1c8ff2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Generated migration blocks my application

[Markus Holtermann]

Hey Oliver,

Can you try out the current 1.7 development branch. There is a fix [1] for 
a recursion problem in the migration graph. Would be interesting if that 
fixes your problem. Thanks.

[1] 
https://github.com/django/django/commit/8e3c3be32d0c39a31997b905ebf0490280baa347

/Markus

On Saturday, November 29, 2014 10:39:17 AM UTC+1, Oliver Meinusch wrote:
>
> I solved the problem by myself using the debugger to see there IS a 
> recursion problem with dependecies. I created a migration file by my own 
> which applies to fields to models which needs my first model. Now my 
> problem is gone.
>

-- 
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/ef783897-e2db-49ac-b4da-d339abea1f49%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using data migration to create initial users errors

[Markus Holtermann]

Hey all together,

unfortunately there isn't a way to add users through their manager in 
RunPython yet. The only solution I can see so far, is doing it manually, 
e.g. doing what your `create_user` method does inside RunPython. There is a 
patch though #23822 [1] that needs some tests and docs, but hopefully makes 
it into 1.8.

[1] https://code.djangoproject.com/ticket/23822

/Markus

On Friday, November 28, 2014 11:47:24 AM UTC+1, Guillaume Cisco wrote:
>
> Did you find a way to use method create_user in a data migration?
> I can't see a way to import the manager for using it.
>
> Le jeudi 16 octobre 2014 23:19:43 UTC+2, Collin Anderson a écrit :
>>
>> Hi Ben,
>>
>> Yes, the custom manager objects are not available within migrations. I 
>> bet you might be able to import the UserManager and stick it on the User 
>> model yourself.
>>
>> Collin
>>
>>

-- 
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/39df0514-e249-467c-8ad6-c0ff1f6151b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django 1.7 migrations upgrade from south: db.delete_foreign_key replacement?

[Markus Holtermann]

Hey Nicola,

Django's migration system doesn't natively support "drop this foreign key 
constraint from the database", because you shouldn't be able to run into 
such a situation with the migration system at all (if you do, that's a bug 
from my point of view). I suggest you go with a "RunSQL" operation where 
you drop the 
constraint: 
https://docs.djangoproject.com/en/1.7/ref/migration-operations/#django.db.migrations.operations.RunSQL

/Markus

On Friday, November 14, 2014 4:23:52 PM UTC+1, drakkan wrote:
>
> Hi,
>
> I'm migrating my app to 1.7 and to builtin django migrations from south, I 
> need something like this:
>
>
> http://south.readthedocs.org/en/latest/databaseapi.html#db-delete-foreign-key
>
> how to remove a foreign key using django builtin migration api?
>
> Please note that my purpose is to remove the foreign key and then add it 
> back with "ON DELETE CASCADE" constraint, actually I use the south api to 
> remove the foreign key and then database specific sql to add it with the 
> constraint I need. I would like to avoid to use sql specific code to find 
> the foreign key too,
>
> thanks
> Nicola
>

-- 
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/2351200e-4c07-4a1a-9ccf-2d4652a03565%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations and FileField storage

[Markus Holtermann]

Hey Nico,

if you want to dynamically determin the upload / storage path you should 
use the "upload_to" parameter with a 
callable: 
https://docs.djangoproject.com/en/1.7/ref/models/fields/#django.db.models.FileField.upload_to
 
inside the callable you can safely access the settings without influencing 
the migrations. Excluding the parameter from the migrations isn't possible 
by design.

/Markus

On Thursday, November 13, 2014 1:22:20 AM UTC+1, Nico Benitez wrote:
>
> I have a question about storage objects in a migration enabled project.
>
> I have a project that uses a file system storage backend for storing 
> certain model FileFields, but the location is dependent on the deployment 
> and stored in the settings module. For example, for testing locally I have 
> the storage root pointed at a directory under my home folder. Whenever I 
> run makemigration, it tries to alter all the FileFields to reflect whatever 
> the current setting is, even though this does not affect the database.
>
> Is there a way to prevent the storage parameter from getting serialized in 
> the migration? If not, what is a good way to handle storing files in 
> different locations depending on a configuration, without a bunch of 
> unnecessary migrations?
>

-- 
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/9da1110a-f174-44c7-8391-a89ce3cf4517%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 migrations: problem with renamed upload_to function on FileField

[Markus Holtermann]

Hey Hans,

As stated in the Docs 
(https://docs.djangoproject.com/en/1.7/topics/migrations/#historical-models)

References to functions in field options such as upload_to and 
limit_choices_to are serialized in migrations, so the functions will need 
to be kept around for as long as there is a migration referencing them. Any 
custom model fields will also need to be kept, since these are imported 
directly by migrations.


So, simply open the migration file that has the import to the old function 
and adjust the reference. Inside the CreateModel operation change

('file', models.FileField(upload_to=example.models.ex_upload_to)),

to

('file', models.FileField(upload_to=example.models.ex_upload_to_new)),

/Markus

On Wednesday, November 12, 2014 5:28:52 PM UTC+1, Hans Lawrenz wrote:
>
> I'm having a problem generating migrations after changing the function 
> used for the upload_to parameter on a FileField. After removing the old 
> function from my code and switching to using a closure to generate the 
> function used by upload_to I get the following exception upon running 
> makemigrations:
>
> AttributeError: 'module' object has no attribute 'story_image_url'
>
>
> I made a simple test using an empty app and just renaming the upload_to 
> function and get the same results because the existing migration references 
> the old function.
>
> Any suggestions on how to handle this beyond keeping a dummy function in 
> the code?
>
> Here's an example:
>
> original models.py:
> from django.db import models
> def ex_upload_to(instance, filename):
> return "foo"
> 
> class MyModel(models.Model):
> 
> file = models.FileField(upload_to=ex_upload_to)
>
>
>
> migration:
> from __future__ import unicode_literals
> from django.db import models, migrations
> import example.models
> 
> class Migration(migrations.Migration):
>dependencies = [
>]  
> 
>operations = [
>migrations.CreateModel(
> name='MyModel',
> fields=[
> ('id', models.AutoField(verbose_name='ID', 
> serialize=False, auto_created=True, primary_key=True)),
> ('file', 
> models.FileField(upload_to=example.models.ex_upload_to)),
> ],  
> 
> options={
> },  
> 
> bases=(models.Model,),
> ),  
> ]  
>
>
> new models.py:
> from django.db import models
> 
> def ex_upload_to_new(instance, filename):
> return "foo"
> 
> class MyModel(models.Model):
> file = models.FileField(upload_to=ex_upload_to_new)
>
>
>
>
>

-- 
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/8d0fac4b-24f9-44d4-970b-9222fed3c588%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Where does django store auth migrations?

[Markus Holtermann]

Hey Ed,

you certainly don't have to copy the virtualenv over to production!

Can you share some insights on your custom user model and your settings. A 
complete traceback, if you have any, helps too.

/Markus

On Monday, November 10, 2014 9:00:04 AM UTC+1, Dr Ed wrote:
>
>
>
> On Sunday, 9 November 2014 14:50:54 UTC+1, Daniel Roseman wrote:
>>
>> On Sunday, 9 November 2014 13:40:12 UTC, Dr Ed wrote:
>>>
>>> Okay, I'm confused. I found it, in here:
>>> /Users//.virtualenvs//lib/python2.7/site-
>>> packages/django/contrib/auth/migrations
>>>
>>> Why are app related migrations being stored in this location?
>>>
>>> Cheers,
>>>
>>> Ed
>>>
>>
>> What? Migrations related to Django's auth app are, not surprisingly, 
>> stored alongside the code to that app. Why does this puzzle you? 
>>
>
> I guess it's because I thought that we could build migrations on the 
> development machines and then update the project on the production machine 
> and apply the migrations. Obviously this assumption was wrong and we need 
> to distribute the entire .virtualenv too... 
>
> Fine, if that's the way it is, that's the way it is, but to me this seems 
> odd because everything else in there is just something you 'pip install' 
> and I would not expect to mix 'user data' with 'installed packages' like 
> this. It actually seems like an unfortunate design decision since it forces 
> you - unless you try to be clever - to put django etc into the 
> repository... we did this before and shifting to 1.7 was more painful as a 
> result).
>
> Anyway, thanks for the reply!
>
> Cheers,
>
> Ed
>

-- 
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/6f20e8d6-faa2-45ad-a02c-958c9e9239d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-apply migrations on restored database

[Markus Holtermann]

Hey Hector,

There is a database table called "django_migrations" that is used to keep track 
of the applied migrations. I guess it's not documented, because touching it 
shouldn't ever be necessary.

It would be interesting to see how you ended up in a state that Django thinks 
all migrations have been applied, though.

/Markus

On October 30, 2014 7:07:02 PM CET, "Héctor Urbina"  wrote:
>Hello,
>
>I'm working on a development branch for a django (1.7) project. I have
>a
>couple of migrations, including a data migration, in this branch; and I
>already applied the migrations. After that, I took a dump of the
>production
>database (which didn't have those migrations, of course) and restored
>it to
>use in development. So, first thing I need to do is to re-apply all the
>development migrations to the database "again", but django says "no
>migrations to apply".
>
>I can't find in the documentation how is that django knows what
>migrations
>have been applied so far, or if there is a way of changing that, in
>order
>to re-apply them.
>
>Any help would be appreciated,
>
>Hector.
>
>-- 
>Héctor Urbina S.
>Ingeniero en Bioinformática
>Fono: 82049138
>
>-- 
>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/CADHcORjtM2ywhbMGZWDrsatReCz1_H76JrX_axo6mysTL-xH2Q%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/EB185059-7189-43EE-BCBA-77EBCB83AB9C%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: django 1.7 migrations: changes detected while nothing has changed ?

[Markus Holtermann]

Hey Michael,

The problem seems to be the same as in #23473 
https://code.djangoproject.com/ticket/23473 . Try adding a __eq__ method on the 
classes marked as deconstructible.

/Markus

On October 22, 2014 6:11:39 PM CEST, Michael  
wrote:
>Hi,
>
>Does anybody know how are changes detected by the ```makemigrations``` 
>command in django 1.7?
>It seems that I have a bug. The original post is on stackoverflow 
><http://stackoverflow.com/questions/26370786/django-1-7-migrations-changes-detected-while-nothing-has-changed>
>
>but no one has replied so I am trying here.
>
>
>I have the issue that it always tells me there are changes for one of
>my 
>field whereas there are not. When I run the command, it just writes the
>
>same migration file over and over with no changes.
>
>The field is a custom field on which I implemented the deconstruct
>method 
>and have some parameters that are objects so I used the deconstructible
>
>decorator.
>
>I created a project on github that replicates the issue: 
>https://github.com/YAmikep/django-testmigrations
>
>What did I do wrong? Is this a bug?
>
>
>Here is what I ran:
>
>/projects/testmigrations$ python manage.py makemigrations app1
>Migrations for 'app1':
>  0001_initial.py:
>- Create model ModelA
>/projects/testmigrations$ python manage.py migrate
>Operations to perform:
>  Apply all migrations: admin, contenttypes, auth, app1, sessions
>Running migrations:
>  Applying contenttypes.0001_initial... OK
>  Applying auth.0001_initial... OK
>  Applying admin.0001_initial... OK
>  Applying app1.0001_initial... OK
>  Applying sessions.0001_initial... OK
>/projects/testmigrations$ python manage.py makemigrations
>Migrations for 'app1':
>  0002_auto_20141014_2123.py:
>- Alter field field1 on modela
>/projects/testmigrations$ python manage.py makemigrations
>Migrations for 'app1':
>  0003_auto_20141014_2123.py:
>- Alter field field1 on modela
>
>
>The migration files 0002_auto_20141014_2123.py and 
>0003_auto_20141014_2123.py contain the exact same operations:
>
>operations = [
>migrations.AlterField(
>model_name='modela',
>name='field1',
>field=app1.models.CustomField(max_length=50, 
>value_manager=app1.models.ValueManager(values=[app1.models.Value(val=1),
>
>app1.models.Value(val=2)])),
>),
>]
>
>
>Thanks
>Mike
>
>-- 
>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/bd651fde-425d-4493-85bf-2a1e17ad5765%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/3B0E03C9-C486-40A0-83DC-FE48FBB5262D%40markusholtermann.eu.
For more options, visit https://groups.google.com/d/optout.

Re: Data migration fails because contenttypes not yet ready

[Markus Holtermann]

Hey Torsten,

Are you talking about Django 1.7 migrations or South? In the former case
you need to make sure that your datamigration depends on the
contenttypes application.

If you use South: yes, calling update_all_contenttypes seems to be a
valid solution.

Best,

Markus

On Tue, Oct 21, 2014 at 06:40:43PM +0200, Torsten Bronger wrote:

Hallöchen!

I want to implement an initial data migration (basically, the same
thing initial_data.json used to do).  The problem is that my initial
data must be connected with ContentType instances.  However,
update_all_contenttypes() hasn't been called at this stage, so my
migration fails.

As far as I can see, update_all_contenttypes is idempotent.  Can I
safely call update_all_contenttypes during the data migration?  I
wonder whether the models may be available in an older version, and
whether this may confuse update_all_contenttypes.

That said, it *seems* to work ...

Tschö,
Torsten.

--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
 or http://bronger-jmp.appspot.com

--
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/87tx2x9y0k.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.


--


pgpxOMNlgfR40.pgp
Description: PGP signature

Re: Backwards migrations on a single app (Django 1.7)

[Markus Holtermann]

Hey Dan,

Without further details I tend to say no. However, the behavior is
different than the one you might be used to from South.

There is a ticket that can be used for discussions on that topic (for
now) [1].

/Markus

[1] https://code.djangoproject.com/ticket/23410


On Sun, Oct 05, 2014 at 04:31:41AM -0700, Dan wrote:

I am trying to migrate backwards on 1 app using:

./manage.py migrate app_name 0001

But it it is migrating all apps back to 0001

Am using django 1.7 am i doing something wrong?

--
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/b93ac501-a75a-477c-9395-17a838ac81b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--


pgpo2XbjSZUnU.pgp
Description: PGP signature

Re: updating site domain with data migration

[Markus Holtermann]

On Mon, Sep 22, 2014 at 08:41:36AM -0700, Anil Jangity wrote:

If I don't use syncdb, I should also create the super user account
using data migration? If so, it seems like I need to go do
User.objects.create_superuser().


There still is the option of running "python manage.py createsuperuser"
after the migrations are applied. If I don't need a superuser account
during the migration, this would be my way of doing it.

/Markus


pgpj4q48V6qNY.pgp
Description: PGP signature

Re: updating site domain with data migration

[Markus Holtermann]

Hey Anil,

On Sun, Sep 21, 2014 at 05:29:18PM -0700, Anil Jangity wrote:

$ python manage.py syncdb


Just as a side note: "syncdb" is deprecated and is being replaced by
"migrate".



I have a main/migration/update_site.py:
def update_site(apps, schema_editor):
   current_site = Site.objects.get_current()
   current_site.domain = "example.com"
   current_site.name = "Example"
   current_site.save()


class Migration(migrations.Migration):

   operations = [
   migrations.RunPython(update_site),
   ]



You are missing a dependency to the sites app in your migration as well
as to the previous migration in the "main" app. Have a look at
https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies

Adding

dependencies = [
 ("main", "whatever_the_name_of_the_previous_migration_is"),
 ("sites", "0001_initial"),
]

should work.

I tried to explain the way dependencies in Django's new migration
framework work in a blog post:
https://markusholtermann.eu/2014/09/django-17-database-migrations-done-right/#how-do-dependencies-between-migrations-work
Might be interesting.

/Markus


pgpsM4spLmQir.pgp
Description: PGP signature

Unofficial Kindle builds of the Django documentation

[Markus Amalthea Magnuson]

Hey all,

I've done .mobi builds of the Django documentation so you can read it on a 
Kindle:

http://alimony.github.io/django-docs-kindle/

Just thought people here might be interested :)

-- 
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/44a36d4d-12c1-4dd0-bb3d-a55302628448%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: compiler

[Markus Christen]

I have tryed your input, but i have always the same problem... i cant fix 
it. it doesent work and i dont know why. (i have it in pycharm and there 
are only these 2 return problems marked.)
 

Am Freitag, 2. November 2012 18:44:46 UTC+1 schrieb ke1g:

> Surely the error message included a line number?
>
> Also, probably not related, but check that there is no whitespace after 
> your line ending back-slashes.  (Hint it is safer to put the opening triple 
> quote before the backslash, and safer yet to put the triple quoted string 
> in a pare of parentheses, the opening one where you have the backslash.)
>
> On Wed, Oct 31, 2012 at 3:28 AM, Markus Christen 
> 
> > wrote:
>
>> Good Morning
>> I have downloaded files, that can helps by my mssql-odbc connection. This 
>> is my downloaded file:
>>
>> http://code.google.com/p/django-pyodbc/source/browse/trunk/sql_server/pyodbc/compiler.py?r=190
>>  
>> On lines 188 and 273, i become the message "'return' outside of 
>> function". It's not a space/tab fail, i have checked this.
>> How can i fix this?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-users/-/uvBBHw13tokJ.
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-users...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/DMb-vkIM5xsJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

compiler

[Markus Christen]

Good Morning
I have downloaded files, that can helps by my mssql-odbc connection. This 
is my downloaded file:
http://code.google.com/p/django-pyodbc/source/browse/trunk/sql_server/pyodbc/compiler.py?r=190
 
On lines 188 and 273, i become the message "'return' outside of function". 
It's not a space/tab fail, i have checked this.
How can i fix this?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/uvBBHw13tokJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database setup

[Markus Christen]

>
> What i know now:
>  
>
-- 

>  
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.mysql',
> 'NAME': 'baan5c',
> 'USER': '***',
> 'PASSWORD': '*',
> 'HOST': 'MAURITIUS',
> 'PORT': '1433',
> }
> }
>
-- 

>  
> This will works, if my DB is a mysql. But I use MsSql.
> The pyodbc is installed and i made connects over it, to the DB. But for 
> settings.py, i cant find the base.py of this pyodbc.
> Any idea where i can find it?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/-SD8TV-mOV4J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Database setup

[Markus Christen]

EDIT:
I have a second to implements. Its a Lotus Notes DB, and for the userauth 
there is a file on my computer.
I tryed it with  the odbc of IBM:
 
---
import pyodbc
conn = pyodbc.connect('DRIVER={Lotus Notes SQL Driver 
(*.nsf)};SERVER=Wind/Sefar;DATABASE=Kopie_SCHSales.nsf;UID=***/M/CHTHA/Sefar;PWD=*');
---
 
I can connect, but i cant read out data, thats my i try with this Admin 
Site.
Do someone know how to implements?
I know how to make Multiple DB's...

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/uyf5Zc1AhB8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Database setup

[Markus Christen]

Good Morning
First i made an odbc connect liek this:
 
-
import pyodbc
cnxn = pyodbc.connect('DRIVER={SQL 
Server};SERVER=MAURITIUS;DATABASE=baan5c;UID=***;PWD=*')
cursor = cnxn.cursor()
cursor.execute("SELECT x.t_name, y.t_mail FROM tttaad20 as x, 
tttcmf20 as y WHERE (x.t_name = y.t_name) AND (x.t_user = 'muster')")
row = cursor.fetchall()
if row:
 print row

This gave me out the correct data (name + e-mail) from a user.
I tryed now to use this database in the Admin site, but i'm to stupid to 
implements this correct into the Database Setup.
The server is not on my computer, it is in the same LAN
 
Can someone help me please?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/a8cnBtTu1RYJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: implement of view

[Markus Christen]

>
> How can i create 2 views on one page?
>> def sql(request): and def portal(request): 
>>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/xneUlf_fSGAJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: implement of view

[Markus Christen]

 Hmm ok, i can use 
 
 return render_to_response("sql.html", { 'row': row })
 
and when i call now http://127.0.0.1:8000/sql/, i can see the correct data. 
But i will call http://127.0.0.1:8000/portal/ and try to implements the sql 
code in this page.
 
I have by base.html in addition now " {% include "sql.html" %} ", the sql 
looks like:
 sql.html---
{% block content %}Kundendaten {{ row }}.{% endblock %}
--
 
my output by portal call is:
-
PortalAusgabe Kundendaten

Zeit der Aktualisierung Oct. 25, 2012, 8:16 a.m..

Kundendaten .
--

Danke fuer die Benutzung meiner Seite.

-

the data output is not there, but it must look like:

Kundendaten [('Niederer Hansruedi (THA) ', 'hansruedi.bl...@blobb.ch ')].

i hope my problem is now better descibed...

maybe i find a way, but i hope for input. :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/_bOenlD205AJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: implement of view

[Markus Christen]

Ok, when i use now  http://127.0.0.1:8000/sql/, the output is
Kundendaten [('bla Hansruedi (THA) ', 'hansruedi@blubb.ch ')].
 
i have in base.html now " {% include "sql.html" %}" in addition.
when i use now http://127.0.0.1:8000/portal/, my output is just:
Kundendaten .
 
how can i fix this problem?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/iaebQXum0yMJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: implement of view

[Markus Christen]

>
> Thank you for this page. I take my time today, to learn on it. :)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/a9kvWj-zSjAJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: implement of view

[Markus Christen]

>
> Thank you for your answer. i have chapter 1-4 of 
> http://www.djangobook.com/en/2.0/index.html done, but not much time to go 
> throught the hole book atm. i will try it with your code. :)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/OhKq_pl-TqkJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: implement of view

[Markus Christen]

>
> I forgot, sql is now hardcodet and i have to change it. on first page i 
> have to give the filter and the username...
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/aq_OCQt8vxkJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

implement of view

[Markus Christen]

Hi all
i have there a little problem and my knowhow with django is not existent. ^^
What i have...
--- urls.py -
from django.conf.urls import patterns, include, url
from klasse.views import portal, sql
urlpatterns = patterns('',
 (r'^portal/$', portal),
 (r'^sql/$', sql),
)
-
 views.py 
from django.shortcuts import render_to_response
import datetime
def portal(request):
now = datetime.datetime.now()
return render_to_response('portal.html', {'current_date': now})
 
def sql(request):
 cnxn = pyodbc.connect('DRIVER={SQL 
Server};SERVER=MAURITIUS;DATABASE=baan5c;UID=***;PWD=***')
 cursor = cnxn.cursor()
 cursor.execute("SELECT x.t_name, y.t_mail FROM tttaad20 as x, 
tttcmf20 as y WHERE (x.t_name = y.t_name) AND (x.t_user = '***')")
 row = cursor.fetchall()
 return HttpResponse(row)
---
 
The Settings are correct... The output of sql works
 
- portal.html 

{% extends "base.html" %}
{% block title %}Kundendaten{% endblock %}
{% block content %}Zeit der Aktualisierung {{ current_date }}.{% 
endblock %}
-
 
--- base.html 
---
{% include "header.html" %}
{% block title %}{% endblock %}


Portal
 Ausgabe Kundendaten
{% block content %}{% endblock %}
{% include "footer.html" %}
-
 
how can i implements now these "def sql(request):" into my html code? pls 
help me...

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/YtO3FCGz1UMJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

WebPage with MsSql access

[Markus Christen]

Hi all
I have to make a WebPage with Django. It must be possible to connect from 
the page to the mssql database. i have an odbc program know atm, and this 
works...
-
import pyodbc
 
cnxn = pyodbc.connect('DRIVER={SQL Server}; 
SERVER=MAURITIUS;DATABASE=baan5c;UID=portal;PWD=P0rtalReader')
cursor = cnxn.cursor()
 
cursor.execute("SELECT x.t_name, y.t_mail FROM tttaad20 as x, 
tttcmf20 as y WHERE (x.t_name = y.t_name) AND (x.t_user = 'niedereh')")
row = cursor.fetchall()
if row:
 print row
-
How i have to make the page, that i can change UID, PWD and the filter with 
a textfield and how can i make the field for the data output from server?
 
I know now only how to draw up the page thx 
http://www.djangobook.com/en/2.0/index.html i worked chapter 1-3 but i have 
not more time... :(
 
i hope you can help me...
greeze Markus

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/JKtPhUUvfmIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Django - Lotus Notes

[Markus Christen]

I have to create a web-service  and i hope it works with Django. My plan is 
connecting to a Lotus Notes database. Can this work? If yes, how? Else no, 
how can i do this, witch programm do i need? I will programm it based on a 
Python language. I am a new programmer and used Python just for one week 
till now...

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/t7Nwc7_WX-cJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Query Distances from User

[Markus Gattol]

I see. You could use geolocation and still let the user input his location 
manually though even after you got a result via geolocation. The manual 
result via geocoding you can do in various ways like simple 'user puts in 
address, lat/lng is returned' or maybe even 'user drags marker to his 
position on map, lat/lng is returned'. Several ways to do it really. I'd 
however still use geolocation as a first step to aid user comfort and leave 
it to the user to decide whether or not he wants to correct his location if 
necessary/desired.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/jgAhtvlbIfIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Query Distances from User

[Markus Gattol]

You're mistaken if you think only mobile devices support geolocation 
queries; current Chrome for example supports it already

 - info: https://developers.google.com/maps/articles/geolocation
 - test your browser: 
http://hpneo.github.com/gmaps/examples/geolocation.html

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/A22jTtb-BKMJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

template filter to split string

[Markus Gattol]

within the head section of my base.html I am using


{% block title %}
{% if request.path_info == '/' %}
home
{% else %}
{{ request.path_info | slugify }}
{% endif %}
{% endblock %}


to set the title of a page. Certainly slugify isn't perfect so I am looking 
for a filter to turn the request.path string from e.g. /foo/baz/bar into 
bar Is there an easy way to do this or will I end up writing my own filter?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/qqi9dTGtc5UJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Query Distance from User

[Markus Gattol]

I can also recommend https://github.com/HPNeo/gmaps as a wrapper, speeds up 
and simplifies dealing with Google's API a lot.

On Sunday, 15 July 2012 17:30:16 UTC+2, Markus Gattol wrote:
>
> You can use geolocation 
> https://developers.google.com/maps/articles/geolocation and if that's not 
> accurate enough let the user provide his address and with it query Google's 
> https://developers.google.com/maps/documentation/javascript/geocoding API
>
> The tricky bit here is if you want to get the lat/lng back onto your 
> server so you can store it in your database. I ended up using 
> https://github.com/abourget/gevent-socketio and store stuff in MongoDB 
> using mongoengine.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/GlhayzaEkwUJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Query Distance from User

[Markus Gattol]

You can use geolocation 
https://developers.google.com/maps/articles/geolocation and if that's not 
accurate enough let the user provide his address and with it query Google's 
https://developers.google.com/maps/documentation/javascript/geocoding API

The tricky bit here is if you want to get the lat/lng back onto your server 
so you can store it in your database. I ended up using 
https://github.com/abourget/gevent-socketio and store stuff in MongoDB 
using mongoengine.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/k9QDjpoVxMgJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Internationalized URL different per language

[Markus Gattol]

Have a look at https://github.com/trapeze/transurlvania

On Friday, 13 July 2012 21:48:54 UTC+2, galgal wrote:
>
> I need to make an urlpattern different for each language, but following to 
> the same view.
>
> for example:
> url(r'^category/(?P[\w-]+)/, 'news.views.category', 
> name='category'), in english
> url(r'^kategoria/(?P[\w-]+)/, 'news.views.category', 
> name='category'), in polish
>
> if you have EN set, "kategoria" won't work. Is it possible?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/jkYLDa4jVZQJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: geocoding - getting latlng from JavaScript, send to server, store into MongoDB

[Markus Gattol]

Answering to my own question: this is what I ended up using 
http://dajaxproject.com/maps/ to send coordinates (latlng) back to the 
server (from the users browser) and then store it in MongoDB. I can then 
easily query MongoDB for near points, send the data back to the users 
browser and draw markers on the map. Good stuff!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/wz2zVQcUbKgJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

geocoding - getting latlng from JavaScript, send to server, store into MongoDB

[Markus Gattol]

Hi folks,

I am using https://github.com/hmarr/mongoengine and Django 1.4 for my 
current project. MongoDB allows for easy geo queries e.g. you have one 
latlng and want all other points in your database within a certain 
radius...  all that's fine and working already.

Now I want to use Google Maps API v3 to do geocoding ie a user inputs an 
address which I ship off to Google to return with the latlng value to stick 
into MongoDB so I can do my radius queries (the point I was referring to 
above). Geocoding is done using JavaScript running on the users browser 
https://developers.google.com/maps/documentation/javascript/geocoding ie I 
need to get that latlng info (in a JavaScript variable) from the users 
browser onto my server and from there into MongoDB. Storing stuff into 
MongoDB is straight forward, I am not sure about how to get the latlng info 
onto my server though.

Should I simply issue a HTTP POST from JavaScript or decode to JSON and do 
an AJAX call to my server? I am no Django expert yet but maybe there is 
some simpler way to get the latlng information from the JavaScript variable 
and stick it into a request.POST so I can grab it from within a view (just 
as you do it with forms)?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/xdzml63oIzsJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: online transactions with python

[Markus Gattol]

https://github.com/agiliq/merchant the braintree backend is good, so is 
stripe. Depends on your type of transaction and the pricing you get.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/bZO5GTdC9C0J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Could someone please give some suggestions about how to set up email sending settings on production.

[Markus Gattol]

you either use your own MTA (e.g. postfix) or you use a third party such as 
Amazon SES for which there is a Django application: 
https://github.com/hmarr/django-ses

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/AfpNMgNw07gJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Alternatives to celery

[Markus Gattol]

Have a look at https://github.com/dmgctrl/django-ztask It's based on 
ZeroMQ, you can schedule and background tasks in various ways, same machine 
or even across the network.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/BFHmXHBbRVsJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Simple task dispatching (How heavy is celery + RabbitMQ)

[Markus Gattol]

You don't need to roll your own... have a look at 
https://github.com/dmgctrl/django-ztask It's based on ZeroMQ and really 
lightweight compared to any alternative with a broker (yes, it's brokerless 
but that's a good thing I think for most use cases which don't really need 
a broker).

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/xcmtk-oHe6wJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: help_text line continuation

[Markus Gattol]

have a look 
at http://www.markus-gattol.name/ws/python.html#multi-line_strings_expressions 
...it's the same for statements, just put stuff inside ( and )

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/CL-ZY2kTqPoJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

ZeroMQ / Mongrel2

[Markus Gattol]

Maybe sombody has given http://code.google.com/p/django-dmq and Mongrel2 a 
spin already and can report how it went? The reason I am interested is 
because it would allow me to get rid of WSGI altogether and have this stack 
(ZeroMQ being directly Mongrel2 for example):



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/lTS_fz9GVYIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Ajax replacement in django

[Markus Gattol]

If you don't want to do AJAX but still need to have a bidirectional link 
between client and server then websockets is probably what you want.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/-K2_KvDu24UJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: PayPal Adaptive Payments

[Markus Gattol]

Rather than reinventing the wheel take a look at 
https://github.com/agiliq/merchant It's possible to split one payment into 
90,5,5 as you want, all you need to do is write a little logic atop 
merchant.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/mnMNCxghPLsJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: STATIC_ROOT confusion

[Markus Gattol]

>
>
> Your STATICFILES_DIRS should not be set to static.
> Create a new theme directory, put your files there and update your 
> STATICFILES_DIRS.
> Have a look at 
> http://www.linovia.com/blog/django-staticfiles-troubleshooting/ for an 
> example.
>

Yeah, read that post and I disagree. Introducing yet another name on the 
filesystem (theme) certainly isn't helping people (this thread and many 
others show there's enough confusion already). It makes more sense to have a 
1:1 mapping between variable naming in settings.py and directories on the 
filesystem e.g. STATIC_ROOT to static_root, STATIC_DIRS to static/. 
Plus, Django is not Joomla or Plone or... so thinking in terms of "themes" 
is semantically wrong as it makes you think of Django as a CMS (one layer to 
high).

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/qWxdPCVJEucJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.