Django oscar core apps confilicts with my local apps

[Kishan Mehta]

 

I have been working on a e commerce website. I am using django-oscar 1.1 
for this. Here is my installed app looks like :

INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
# local apps
'content',
'usermgmt',
'resources',
'assessment',
'analytics',
'utils',
# 'notify',
# Auth related apps
'oauth2_provider',
'social.apps.django_app.default',
'rest_framework_social_oauth2',
# rest
'rest_framework',
'djoser',
# misc - third party
'reversion',
'corsheaders',
'notifications',
#oscar
'oscarapi',



] + get_core_apps()


While running server : 


Traceback (most recent call last):
 File "manage.py", line 10, in 
execute_from_command_line(sys.argv)
 File 
"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/core/management/__init__.py",
 line 338, in execute_from_command_line
utility.execute()
File 
"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/core/management/__init__.py",
 line 312, in execute
django.setup()
File 
"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/__init__.py",
 line 18, in setup
apps.populate(settings.INSTALLED_APPS)
File 
"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/apps/registry.py",
 line 89, in populate
"duplicates: %s" % app_config.label)
 django.core.exceptions.ImproperlyConfigured: Application labels aren't unique, 
duplicates: analytics



Aparently analystics is conflicting with the analytics in get_core_apps().


Is there any way to resolve this ?

-- 
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/4202bc69-8d68-4506-9186-f4de1d1a0c20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django oscar core apps confilicts with my local apps

[Avraham Serour]

Change your app name

On Tue, Aug 25, 2015, 10:12 AM Kishan Mehta  wrote:

> I have been working on a e commerce website. I am using django-oscar 1.1
> for this. Here is my installed app looks like :
>
> INSTALLED_APPS = [
> 'django.contrib.admin',
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.messages',
> 'django.contrib.staticfiles',
> # local apps
> 'content',
> 'usermgmt',
> 'resources',
> 'assessment',
> 'analytics',
> 'utils',
> # 'notify',
> # Auth related apps
> 'oauth2_provider',
> 'social.apps.django_app.default',
> 'rest_framework_social_oauth2',
> # rest
> 'rest_framework',
> 'djoser',
> # misc - third party
> 'reversion',
> 'corsheaders',
> 'notifications',
> #oscar
> 'oscarapi',
>
>
>
> ] + get_core_apps()
>
>
> While running server :
>
>
> Traceback (most recent call last):
>  File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>  File 
> "/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/core/management/__init__.py",
>  line 338, in execute_from_command_line
> utility.execute()
> File 
> "/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/core/management/__init__.py",
>  line 312, in execute
> django.setup()
> File 
> "/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/__init__.py",
>  line 18, in setup
> apps.populate(settings.INSTALLED_APPS)
> File 
> "/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-packages/django/apps/registry.py",
>  line 89, in populate
> "duplicates: %s" % app_config.label)
>  django.core.exceptions.ImproperlyConfigured: Application labels aren't 
> unique, duplicates: analytics
>
>
>
> Aparently analystics is conflicting with the analytics in get_core_apps().
>
>
> Is there any way to resolve this ?
>
> --
> 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/4202bc69-8d68-4506-9186-f4de1d1a0c20%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/CAFWa6tLcpPdgYZQi3MiGS3EKYo6mcRK%2BDed5w0hGEari-N1SGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django + microservices: What's correct approach?

[cr0hn]

Thank you for your responses.

I try to find some guide to create micro-services architecture using 
Django. I know that micro-service is a design paradigm, so I'm looking for 
the best way to implement it using Django (+ django-rest-framework).

I also know that there're not a unique response, but I would like to answer 
questions like that:
Create a Django project for each micro-service or all using the same 
project?

   - Micro-services must communicate themselves using the same REST API, 
   some way for better approach?
   - How to deploy the project: Running "python manage.py runserver" or 
   something like "python manage.py start MY_MICROSERVICE"?
   - How to communicate the services for reduce response time and using 
   async way?

I know how to implement all of things above, but I'm looking for some 
recommendation of someone who have had the same problem or who has created 
micro-services with django.

I hope I explained better now :)

Regards.


El lunes, 24 de agosto de 2015, 17:59:01 (UTC+2), Tom Christie escribió:
>
> Django REST framework is a general purpose API toolkit, and more than 
> capable of building microservice-type services. Likewise there are plenty 
> of frameworks in alternative languages that are also suitable for building 
> APIs that could be characterized as 'microservice'.
>
> The reason you're finding it hard to discover much on the subject is 
> probably due to microservices being an architectural style, rather than a 
> framework choice.
>
> Are there any *specific* technical issues that you're looking for help 
> with? What sort of service are you building, and is this for a Web App 
> frontend, a native client, both or something else?
>
> Aside: Unless you've got automated deployments nailed, great monitoring, a 
> heavily used service with a really nicely designed separation of concerns, 
> and a culture of personal responsibility for the engineers taking 
> code-to-deployment then the microservices probably (as a super-rough rule 
> of thumb) isn't worth the extra up-front infrastructure it requires.
>

-- 
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/ceefe6b9-ab71-405c-abae-dc09ed3f695f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.7 to 1.8 upgrade: test suite failing

[simon . shillaker]

Hi Tim,

Thanks again for your help and sorry for the long delay. We've now solved 
the issue but I'd like to share the changes we made. I'm not sure which are 
essential and they're all in the RTFM category, however, they might serve 
as useful pointer to someone:

1. Make sure the TestCase version of test lifecycle methods is *always* run 
(setUpTestData, setUp etc.). Be careful with any mixins or missing super() 
calls that might be circumventing the TestCase version of the method (it 
seems like you could get away with this in 1.7 but not 1.8)
2. Avoid setUpClass, use setUpTestData instead
3. Don't mix django TestCase and unittest.TestCase in the same suite. Use 
SimpleTestCase where you need a lightweight test.
4. If a test spawns threads that need to access the database data, use 
TransactionalTestCase, not TestCase.
5. RTFM: https://docs.djangoproject.com/en/1.8/topics/testing/tools/

Thanks again,

Simon

On Monday, July 20, 2015 at 11:03:42 AM UTC+1, simon.s...@eporta.com wrote:
>
> Hi Tim,
>
> Thanks again for the responses. Tom is now on holiday for a week but we'll 
> pick up where he left off and try to replicate the issue in a minimal 
> project.
>
> Cheers,
>
> Simon
>
> On Wednesday, July 15, 2015 at 3:03:31 PM UTC+1, Tim Graham wrote:
>>
>> A minimal project to reproduce the issue would be helpful.
>>
>> On Wednesday, July 15, 2015 at 5:41:49 AM UTC-4, tom.sz...@eporta.com 
>> wrote:
>>>
>>> Unfortunately, adding the super() calls didn't help.
>>>
>>> On Tuesday, July 14, 2015 at 12:47:02 PM UTC+1, Tim Graham wrote:

 Please try adding the super() calls.

 On Tuesday, July 14, 2015 at 5:44:09 AM UTC-4, tom.sz...@eporta.com 
 wrote:
>
> Hi, yes. Some of my test classes do use setUpClass() without calling 
> super().
>
> On Monday, July 13, 2015 at 5:44:03 PM UTC+1, Tim Graham wrote:
>>
>> Do your test classes use setUpClass() and/or tearDownClass()? If so, 
>> are you missing super() calls in those methods?
>>
>> On Monday, July 13, 2015 at 9:37:03 AM UTC-4, tom.sz...@eporta.com 
>> wrote:
>>>
>>> Thanks for the link
>>> This is the commit at which my tests start failing:
>>> da9fe5c Fixed #20392 -- Added TestCase.setUpTestData()
>>>
>>> On Monday, July 13, 2015 at 12:39:57 PM UTC+1, Tim Graham wrote:

 That's a starting point, but there are still a lot of commits 
 between 1.8 and 1.7.x. Here's what I meant by "bisecting the commit":


 https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression

 On Monday, July 13, 2015 at 5:50:49 AM UTC-4, tom.sz...@eporta.com 
 wrote:
>
> Thanks for the swift reply. The problem starts with Django 1.8.0. 
> My test suite passes on all 1.7.x versions.
>
> On Friday, July 10, 2015 at 2:32:25 PM UTC+1, Tim Graham wrote:
>>
>> No ideas, but if you could bisect to find the Django commit where 
>> the problem started to appear that will probably help.
>>
>> On Friday, July 10, 2015 at 7:21:37 AM UTC-4, 
>> tom.sz...@eporta.com wrote:
>>>
>>> Hi,
>>>
>>> I've recently tried upgrading from Django 1.7.6 to 1.8.3 but 
>>> haven't been able to get my test suite to pass.
>>>
>>> My main problem is that all of the tests pass when run 
>>> individually, but when run as an entire test suite, many arbitraily 
>>> fail 
>>> due to an *InterfaceError: connection already closed*:
>>>
>>>   File 
>>> "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py"
>>> , line 838, in execute_sql
>>> cursor = self.connection.cursor()
>>>   File 
>>> "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py"
>>> , line 164, in cursor
>>> cursor = self.make_cursor(self._cursor())
>>>   File 
>>> "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py"
>>> , line 137, in _cursor
>>> return self.create_cursor()
>>>   File 
>>> "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", 
>>> line 97, in __exit__
>>> six.reraise(dj_exc_type, dj_exc_value, traceback)
>>>   File 
>>> "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py"
>>> , line 137, in _cursor
>>> return self.create_cursor()
>>>   File 
>>> "/usr/local/lib/python2.7/dist-packages/django/db/backends/postgresql_psycopg2/base.py"
>>> , line 212, in create_cursor
>>> cursor = self.connection.cursor()
>>> InterfaceError: connection already closed
>>>
>>>
>>>
>>> I was previously using psycopg2.6 with Postgres 9.3 and have 
>>> tri

Re: Django oscar core apps confilicts with my local apps

['Hugo Osvaldo Barrera' via Django users]

On Tue, Aug 25, 2015, at 04:33, Avraham Serour wrote:
> Change your app name



Actually, changing the app label should suffice:

https://docs.djangoproject.com/en/1.8/ref/applications/#for-application-authors

> On Tue, Aug 25, 2015, 10:12 AM Kishan Mehta
>  wrote:
>> I have been working on a e commerce website. I am using django-oscar
>> 1.1 for this.  Here is my installed app looks like :


>>
>> INSTALLED_APPS =[ 'django.contrib.admin', 'django.contrib.auth',
>> 'django.contrib.contenttypes', 'django.contrib.sessions',
>> 'django.contrib.messages', 'django.contrib.staticfiles',
>> # local apps
>> 'content', 'usermgmt', 'resources', 'assessment', 'analytics',
>> 'utils',
>> # 'notify', Auth related apps
>> 'oauth2_provider', 'social.apps.django_app.default',
>> 'rest_framework_social_oauth2',
>> # rest
>> 'rest_framework', 'djoser',
>> # misc - third party
>> 'reversion', 'corsheaders', 'notifications', #oscar 'oscarapi',
>>
>>
>> ]+ get_core_apps()


>>
>>
>>
>> While running server :


>>


>>
>>
>>
>>
>> Traceback(most recent call last): File"manage.py", line 10,in
>> execute_from_command_line(sys.argv) 
>> File"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-
>> packages/django/core/management/__init__.py", line 338,in
>> execute_from_command_line utility.execute() 
>> File"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-
>> packages/django/core/management/__init__.py", line 312,in execute
>> django.setup() 
>> File"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-
>> packages/django/__init__.py", line 18,in setup
>> apps.populate(settings.INSTALLED_APPS) 
>> File"/home/rss-20/.virtualenvs/kishan_pal/local/lib/python3.4/site-
>> packages/django/apps/registry.py", line 89,in populate "duplicates:
>> %s"% app_config.label)
>> django.core.exceptions.ImproperlyConfigured:Application labels aren't
>> unique, duplicates: analytics
>>
>>
>>
>>
>>
>>
>> Aparently analystics is conflicting with the analytics in
>> get_core_apps().


>>


>> Is there any way to resolve this ?


>>


>> --
>>
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/4202bc69-8d68-4506-9186-f4de1d1a0c20%40googlegroups.com[1].
>>
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/CAFWa6tLcpPdgYZQi3MiGS3EKYo6mcRK%2BDed5w0hGEari-N1SGQ%40mail.gmail.com[2].
>
For more options, visit https://groups.google.com/d/optout.

--
Hugo Osvaldo Barrera
 


Links:

  1. 
https://groups.google.com/d/msgid/django-users/4202bc69-8d68-4506-9186-f4de1d1a0c20%40googlegroups.com?utm_medium=email&utm_source=footer
  2. 
https://groups.google.com/d/msgid/django-users/CAFWa6tLcpPdgYZQi3MiGS3EKYo6mcRK%2BDed5w0hGEari-N1SGQ%40mail.gmail.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 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/1440493674.2289326.365311305.20A57B39%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django + microservices: What's correct approach?

[Steve McConville]

Hi Crohn.

You're asking a lot of related but very general questions here. I know
you are looking for someone who has "had the same problem" but we
don't know what your problem is. The whole point of any architecture
is that it's supposed to be a solution to your problems, not a problem
in itself :) If you tell us what you are trying to create (roughly
from the perspective of your users) and why you want to solve that
problem with microservices and Django, there may be sensible advice
people on the list can offer. Anyone who offers you architectural
advice before knowing what your system actually does is usually
selling something.

Many of the resources you'll need to learn about architecture and
about Django implementations will have been published before 2014, and
hence won't contain the word "microservices".

To address specific things you've asked (none of which are specific to
microservice architectures):

1. REST
Django is a HTTP application framework, and you can obviously use any
approach that HTTP supports, including REST. RESTful or RPC-like
services using JSON as a serialisation format are common.
Django-rest-framework is obviously geared towards REST :)

2. Deployment
The built-in runserver is only appropriate for development, and
certainly not for a services based approach. The normal way to deploy
django applications is with a WSGI server such as uwsgi or gunicorn.
These are typically run behind a reverse proxy or load balancer. If
you are planning to deploy many services, it's worth automating this
process as much as possible. There's good recommendations on how to
deploy Django for production in the docs:
https://docs.djangoproject.com/en/1.8/howto/deployment/

3. Performance analysis
Performance analysis of communicating services can be tricky. To
master it you'll need a grasp of distributed systems and queuing
theory and this will take a lot of reading, maths and experimentation.
There are books and software that can help you with this such as PPA:
http://www.perfdynamics.com/iBook/ppa.html

4. Async
Django is not designed to be an asynchronous server. Async webapps are
usually more complex than synchronous ones. You may be better off
either:
  a) using one of the queueing systems for Django
https://www.djangopackages.com/grids/g/workers-queues-tasks/
  b) using things like asyncio, gevent or twisted if you are *sure*
you need them.

I hope this is a helpful response, and good luck with your project!


On 25 August 2015 at 08:42, cr0hn  wrote:
> Thank you for your responses.
>
> I try to find some guide to create micro-services architecture using Django.
> I know that micro-service is a design paradigm, so I'm looking for the best
> way to implement it using Django (+ django-rest-framework).
>
> I also know that there're not a unique response, but I would like to answer
> questions like that:
> Create a Django project for each micro-service or all using the same
> project?
>
> Micro-services must communicate themselves using the same REST API, some way
> for better approach?
> How to deploy the project: Running "python manage.py runserver" or something
> like "python manage.py start MY_MICROSERVICE"?
> How to communicate the services for reduce response time and using async
> way?
>
> I know how to implement all of things above, but I'm looking for some
> recommendation of someone who have had the same problem or who has created
> micro-services with django.
>
> I hope I explained better now :)
>
> Regards.
>
>
> El lunes, 24 de agosto de 2015, 17:59:01 (UTC+2), Tom Christie escribió:
>>
>> Django REST framework is a general purpose API toolkit, and more than
>> capable of building microservice-type services. Likewise there are plenty of
>> frameworks in alternative languages that are also suitable for building APIs
>> that could be characterized as 'microservice'.
>>
>> The reason you're finding it hard to discover much on the subject is
>> probably due to microservices being an architectural style, rather than a
>> framework choice.
>>
>> Are there any *specific* technical issues that you're looking for help
>> with? What sort of service are you building, and is this for a Web App
>> frontend, a native client, both or something else?
>>
>> Aside: Unless you've got automated deployments nailed, great monitoring, a
>> heavily used service with a really nicely designed separation of concerns,
>> and a culture of personal responsibility for the engineers taking
>> code-to-deployment then the microservices probably (as a super-rough rule of
>> thumb) isn't worth the extra up-front infrastructure it requires.
>
> --
> 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 d

Re: Django + microservices: What's correct approach?

[Tom Christie]

> Create a Django project for each micro-service or all using the same 
project?

Different projects.

> Micro-services must communicate themselves using the same REST API, some 
way for better approach?

The API *is* the service boundary yup.

> How to deploy the project: Running "python manage.py runserver" or 
something like "python manage.py start MY_MICROSERVICE"?

Same way you'd deploy any other Django service.

>  How to communicate the services for reduce response time and using async 
way?

Just use requests, and don't worry about this.

But finally and most importantly:

Almost certainly *don't bother*. Micro-services have a large up-front cost, 
and they're not worth it unless you've got a good reason to do so (eg you 
have a large service and you know that you need to scale different 
components independently, and ensure distributed reponsibilities across a 
large engineering team)

Unless you know that you've got an issue like that and you can pinpoint it, 
it's unclear why a microservices approach would be preferable. (If you're 
purely looking at this as a learning exercise then that's slightly 
different)   

A single project providing an API for your front end is *far* more likely 
to be what you're actually looking for.

-- 
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/7a3005a8-0ecc-4b6e-b614-c5d536b610dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

middleware

[Pawanesh Gautam]

why middleware is required ?? 

-- 
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/b160c03e-a9c2-42f9-a95e-52fbace330c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations and FileField storage

[Steve Capell]

Hi Nico,

I had the same problem when I was using this storage object:

photoStorage = FileSystemStorage(location=os.path.join(settings.MEDIA_ROOT, 
'photos/original'), base_url='/photos/original')

class Photo(models.Model):
image = models.ImageField(storage=photoStorage)


The "location" argument ends up being serialized, which makes the 
migrations dependent on MEDIA_ROOT. To fix the problem I wrote my own 
subclass of FileSystemStorage:

@deconstructible
class PhotoFileSystemStorage(FileSystemStorage):
def __init__(self, photoPath):
self.photoPath = photoPath
super(PhotoFileSystemStorage,self).__init__(location=os.path.join(settings.MEDIA_ROOT,
 
self.photoPath), base_url=self.photoPath)

def __eq__(self, other):
   return self.photoPath == other.photoPath

photoStorage = PhotoFileSystemStorage('photos/original')

When an instance of PhotoFileSystemStorage is serialized it just writes out 
self.photoPath, which does not depend on MEDIA_ROOT. After implementing 
this, the migration looks like this:

class Migration(migrations.Migration):

dependencies = [
...
]

operations = [
migrations.AlterField(
model_name='photo',
name='image',

field=models.ImageField(storage=myapp.models.PhotoFileSystemStorage(b'photos/original')),
),
]

You can see it does not depend on MEDIA_ROOT and won't be different if you 
move the project around or deploy it.

The django docs on this are 
here: https://docs.djangoproject.com/en/1.8/topics/migrations/

Hope this helps.


Steve


-- 
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/b1972234-7ef7-48f6-8dee-afcfacf7fafb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

#WomenWhoCanCode Hackathon at Hike Messenger Office, Bangalore

[Abhishek Kumar Gupta]

Hi Everyone,

Greetings to you from Dexter Talent Labs!!!

"Be the kind of Woman that when your feet hit the floor on each challenging
competition the devil says "Oh crap, SHE's up!"

We are hosting a one day technical coding event.  You may say half-a-thon :)

We invite all the women coders to come and participate.  We also request
awesome men to encourage women in their life who knows coding to
participate in this contest.  We have associated with the NGO - Durga (
www.durgaindia.org).

On this challenge we want you to use your *Hacking* skills to increase *Women's
Safety*.

Join by *registering* at *www.dexterhack.com *

Awesome goodies waiting and also *opportunity to get hired by Hike
Messenger* (a well funded, awesomely cool mobile chat messenger company,
www.get.hike.com).

*Event Date:* 12th September 2015 (Saturday)

*Start Time*: 9 am sharp

*Ends at* : 7pm

*Location*: Hike Ltd., The pearl, #157-160- Next to Imperial Solitaire
Apartment, 5th Main, Sector 7, HSR Layout, Bangalore - 560102



​

*Note*: It would be even more awesome when you bring your friends also to
participate.  So you know now what to be done ;)

Thanks & Regards
Janaki
Talent Hacker
Dexter Talent Labs

*Upcoming Hackathon: www.dexterhack.com *



   Best Regards,
Abhishek Kumar Gupta
PESIT-ISE


​

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

Re: Django dev server issue

[ilyas Jumadurdyew]

The problem is in your packages. You probably tried to solve so other issue 
and installed some package that you dont need. 

I had the same problem, clearing unused packages solved the problem

On Monday, 3 January 2011 02:25:16 UTC+5, daniels wrote:
>
> Hi, 
> I'm having a issue with Django's dev server. I did a "django-admin.py 
> startproject" then "manage.py startapp home", then added the app in 
> settings.py and in urls.py. The app only has  a index function in 
> views.py which is mapped to / and just renders a simple html template. 
> What happens is that sometimes(and this is often) when i load the page 
> in a broswer (tryed Chrome and Firefox) or refresh it, the page starts 
> loading but it never finishes. And if i hit the browser's stop button 
> i get this in the console 
>
>
>
> Exception happened during processing of request from ('127.0.0.1', 
> 52495) 
> Traceback (most recent call last): 
>   File "C:\Python26\lib\SocketServer.py", line 283, in 
> _handle_request_noblock 
> self.process_request(request, client_address) 
>   File "C:\Python26\lib\SocketServer.py", line 309, in process_request 
> self.finish_request(request, client_address) 
>   File "C:\Python26\lib\SocketServer.py", line 322, in finish_request 
> self.RequestHandlerClass(request, client_address, self) 
>   File "C:\Python26\lib\site-packages\django\core\servers 
> \basehttp.py", line 562, in __init__ 
> BaseHTTPRequestHandler.__init__(self, *args, **kwargs) 
>   File "C:\Python26\lib\SocketServer.py", line 618, in __init__ 
> self.finish() 
>   File "C:\Python26\lib\SocketServer.py", line 661, in finish 
> self.wfile.flush() 
>   File "C:\Python26\lib\socket.py", line 297, in flush 
> self._sock.sendall(buffer(data, write_offset, buffer_size)) 
> error: [Errno 10053] An established connection was aborted by the 
> software in your host machine 
>  
>
>
> Any idea what's causing this? As it really cripples my dev time. 
> I'm on a Windows 7 32bit machine

-- 
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/7f7312de-170f-4574-87d2-c2afe39576e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Live Site to Localhost (Testing)

[Bhadreshsinh Gohil]

Dear Bhanu

Put your download sites in your config folder(web directory) and restore
your database.

*Thanks And Regards*

Bhadreshsinh Gohil

Asst. Prof.

GTU PG School,

Mo. No. +91 7600 95 94 93
--
[ GTU PG School is on Social-Media too. Kindly follow us at:
*Facebook:* @Facebook
 & *Twitter:*
@GTUPGSchool  ]
*Website:* GTUPGSchool
 & *MOODLE:*
@e-learning 

On Thu, Aug 20, 2015 at 8:10 PM,  wrote:

> We have a completely developed Django Site running on live, But it never
> had a testing environment. Now, I downloaded all the files of Website and
> download a mysql dump file.
> I want to run this on my local machine windows (Just to push my changes
> here to test before going live).
> I installed all requirements (Python 2.7, Pip, Mysql, Django), and able to
> create a new project and run the server. How do I configure and run the
> downloaded site now?
>
> Your help is highly Appreciated.
>
> Thanks,
> Bhanu.
>
> --
> 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/8ec6f13f-53fb-49e0-b7c2-98be447e7960%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/CAEAngN%3D%3D89Kv6Mjqu0p4gf72sAewrx5ikaeLHbmyfQRN9aFWqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: middleware

[Mayank G]

Middleware allows you to process certain pre specified activities like,
Logging, User Authentication, Tokenization and filtration of data. Route
authentication, Access control list validations.
It provides flexibility to invoke appropriate middleware on different
routes.
These act as glue to provide extra functionality.
Certain tasks which need to be processed before of after serving request,
it must be included inside middleware

On Tue, Aug 25, 2015 at 4:44 PM, Pawanesh Gautam  wrote:

> why middleware is required ??
>
> --
> 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/b160c03e-a9c2-42f9-a95e-52fbace330c9%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/CA%2B_AzAQp9CBfbaS6AZxE-aEqoA48%2BbN%3D7pyuHS889%2BLBEaYsWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.7 migrations: Adding one field to User`s model

[marcin . j . nowak]

Hi,

I would like to add one field to User.

I've created new model based on original Django`s user:

 class User(AbstractUser):
is_verified = models.BooleanField(default=False)

class Meta:
db_table = 'auth_user'


Now I'm trying to make migrations, but Django tries to create `auth_user` 
table from scratch, and this is not what I'm expecting.

I've tried to migrate schema by adding one field:

[...] 
 operations = [
migrations.AddField('User', 'is_verified', 
models.BooleanField(default=False)),
]

But during migrations Django dies at:

[...]
  File "eggs/Django-1.7.8-py2.7.egg/django/db/migrations/migration.py", 
line 76, in mutate_state
operation.state_forwards(self.app_label, new_state)
  File 
"eggs/Django-1.7.8-py2.7.egg/django/db/migrations/operations/fields.py", 
line 26, in state_forwards
state.models[app_label, 
self.model_name.lower()].fields.append((self.name, field))
KeyError: ('myapp', u'user')


I need to add just one column using builtin migrations. 
How to do that?
This is bug or feature?

BR,
Marcin

-- 
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/4732d84b-0611-4098-ac9f-01d6bf4d871e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[marcin . j . nowak]

On Tuesday, April 28, 2015 at 7:20:17 AM UTC+2, Mike Dewhirst wrote:
>
> Anyway, I suspect disabling migration - even if a 
> "master-switch" could be built - is undesirable if one is using any of 
> the django tables. 
>
>
>
I'm not sure we're talking about the same.

Some of us don't need builtin migration system. It is badly designed, same 
as South was.
I know that we can make simple migrations in seconds, but we're wasting 
hours elsewhere.

Database migrations should be managed by database tool. 
"Model migrations" are fiction... this is a conceptual mistake. There are 
no models mapped to db tables - there are tables mapped to models.

We're working with databases and their representations in application 
layer, and not vice versa.
 
Thanks,
Marcin

-- 
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/de18bd57-ad18-4464-8783-009e26abced2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Avraham Serour]

> We're working with databases and their representations in application
layer, and not vice versa.

Speak for yourself, I'm working with the models, saving them in the
database is just an implementation detail

On Tue, Aug 25, 2015 at 3:21 PM,  wrote:

>
>
> On Tuesday, April 28, 2015 at 7:20:17 AM UTC+2, Mike Dewhirst wrote:
>>
>> Anyway, I suspect disabling migration - even if a
>> "master-switch" could be built - is undesirable if one is using any of
>> the django tables.
>>
>>
>>
> I'm not sure we're talking about the same.
>
> Some of us don't need builtin migration system. It is badly designed, same
> as South was.
> I know that we can make simple migrations in seconds, but we're wasting
> hours elsewhere.
>
> Database migrations should be managed by database tool.
> "Model migrations" are fiction... this is a conceptual mistake. There are
> no models mapped to db tables - there are tables mapped to models.
>
> We're working with databases and their representations in application
> layer, and not vice versa.
>
> Thanks,
> Marcin
>
> --
> 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/de18bd57-ad18-4464-8783-009e26abced2%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/CAFWa6tL0LXfusjhi3DKfP%2BQ4UpsWTJVUxNp96%3Dj_D%3D1a3A-oMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Marcin Nowak]

On 25 August 2015 at 14:32, Avraham Serour  wrote:

> > We're working with databases and their representations in application
> layer, and not vice versa.
>
> Speak for yourself, I'm working with the models, saving them in the
> database is just an implementation detail
>

I'm speaking on behalf of a one of experienced developers, who knows that
data is most important thing in IT.
And this is not an implementation detail, because the bulit-in tool is
forcing us to do things in the your way/workflow, and sometimes blocks us.
Let the user decide which tool is better for his job.


Marcin

-- 
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/CAB2m7CwT%3Dp%3Dke6P6iKvQkHufTQ14WAD_KVM92ni4NfbrLxhEGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[bobhaugen]

I agree that migrations should be optional, for all the reasons listed in 
this thread, but hope it doesn't now turn into a religious war between 
models-first and database-first. Not relevant to the 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/b4510e75-6b88-4168-9d34-320e44fbe60f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Live Site to Localhost (Testing)

[Gergely Polonkai]

If this is a Django-only thing, you can use manage.py to dump and load your
data, without the SQL dump. The code, I guess, is available from somewhere,
e.g. in a VCS so you just have to clone/checkout.
On 20 Aug 2015 16:40,  wrote:

> We have a completely developed Django Site running on live, But it never
> had a testing environment. Now, I downloaded all the files of Website and
> download a mysql dump file.
> I want to run this on my local machine windows (Just to push my changes
> here to test before going live).
> I installed all requirements (Python 2.7, Pip, Mysql, Django), and able to
> create a new project and run the server. How do I configure and run the
> downloaded site now?
>
> Your help is highly Appreciated.
>
> Thanks,
> Bhanu.
>
> --
> 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/8ec6f13f-53fb-49e0-b7c2-98be447e7960%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/CACczBUJm1%3DMfoAzxG2Fnwk8KOz2RaAZ1novkERmimOo3bAE%2BBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Tim Graham]

What does "turning off migrations" mean in practice? Is it not enough to 
avoid the makemigrations and migrate management commands?

On Tuesday, August 25, 2015 at 9:31:30 AM UTC-4, bobhaugen wrote:
>
> I agree that migrations should be optional, for all the reasons listed in 
> this thread, but hope it doesn't now turn into a religious war between 
> models-first and database-first. Not relevant to the 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/772ea2f0-49d0-4733-93f4-434fda072a50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Marcin Nowak]

On 25 August 2015 at 16:21, Tim Graham  wrote:

> What does "turning off migrations" mean in practice? Is it not enough to
> avoid the makemigrations and migrate management commands?



Currently I'm replacing mgmt commands to avoid accidential calls, and also
replacing test runner.  But, for example, `runserver` complains about
unapplied migrations (which is not true), and I don't know what else and
when other db alterations can be executed.

"Global turn off" should give us assurance that nothing would be changed in
db automatically.

BR,
Marcin

-- 
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/CAB2m7CxBWsouYWmASv1gXQ%3DHyyqjnNenspkztv%3Dzv_f4P0uuZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Carl Meyer]

On 08/25/2015 08:42 AM, Marcin Nowak wrote:
> 
> On 25 August 2015 at 16:21, Tim Graham  > wrote:
> 
> What does "turning off migrations" mean in practice? Is it not
> enough to avoid the makemigrations and migrate management commands?
> 
> 
> 
> Currently I'm replacing mgmt commands to avoid accidential calls, and
> also replacing test runner.  But, for example, `runserver` complains
> about unapplied migrations (which is not true), and I don't know what
> else and when other db alterations can be executed. 
> 
> "Global turn off" should give us assurance that nothing would be changed
> in db automatically.  

I thought we already covered this topic, and `managed=False` should work
for your use case. That's the exact meaning of this flag: "I don't want
Django to manage my database, please never touch it." Have you tried
adding that flag to your models? Does something about that not work for you?

Carl

-- 
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/55DC817D.6070905%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Turn off migrations completely in Django 1.7

[Marcin Nowak]

On 25 August 2015 at 16:53, Carl Meyer  wrote:

> I thought we already covered this topic, and `managed=False` should work
> for your use case. That's the exact meaning of this flag: "I don't want
> Django to manage my database, please never touch it." Have you tried
> adding that flag to your models? Does something about that not work for
> you?
>


Managed=False is not same. I.e. I can't set managed=False for 3rd party
apps (including `django.contrib`)
But to be honest I didn't tried iterate over all INSTALLED_APPS to patch
meta options...


BR,
Marcin

-- 
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/CAB2m7CyVB06KZKXXtFiwZpBTgEkt4n0q5r%2BVwo-V4d29XWNy9g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Carl Meyer]

On 08/25/2015 09:02 AM, Marcin Nowak wrote:
> 
> On 25 August 2015 at 16:53, Carl Meyer  > wrote:
> 
> I thought we already covered this topic, and `managed=False` should work
> for your use case. That's the exact meaning of this flag: "I don't want
> Django to manage my database, please never touch it." Have you tried
> adding that flag to your models? Does something about that not work
> for you?
> 
> 
> 
> Managed=False is not same. I.e. I can't set managed=False for 3rd party
> apps (including `django.contrib`)
> But to be honest I didn't tried iterate over all INSTALLED_APPS to patch
> meta options...

Hmm, yes, third-party apps are an issue.

My recollection from the last time you brought this up is that we
decided an AppConfig-level setting to do the equivalent of managed=False
for an entire app would be a reasonable feature request. Since you can
provide your own AppConfig for third-party apps, this would cover that
use case, too.

Carl

-- 
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/55DC841A.4070206%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Django 1.7 migrations: Adding one field to User`s model

[Tim Graham]

This might be related to the difficulties of migrating an existing project 
to a custom user model. I'm not sure the steps to workaround the problem. 
We have an open ticket to recommend starting off a project with a custom 
user model to avoid this problem [1]. Sorry I can't be of more help.

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

On Tuesday, August 25, 2015 at 7:51:08 AM UTC-4, marcin@gmail.com wrote:
>
> Hi,
>
> I would like to add one field to User.
>
> I've created new model based on original Django`s user:
>
>  class User(AbstractUser):
> is_verified = models.BooleanField(default=False)
>
> class Meta:
> db_table = 'auth_user'
>
>
> Now I'm trying to make migrations, but Django tries to create `auth_user` 
> table from scratch, and this is not what I'm expecting.
>
> I've tried to migrate schema by adding one field:
>
> [...] 
>  operations = [
> migrations.AddField('User', 'is_verified', 
> models.BooleanField(default=False)),
> ]
>
> But during migrations Django dies at:
>
> [...]
>   File "eggs/Django-1.7.8-py2.7.egg/django/db/migrations/migration.py", 
> line 76, in mutate_state
> operation.state_forwards(self.app_label, new_state)
>   File 
> "eggs/Django-1.7.8-py2.7.egg/django/db/migrations/operations/fields.py", 
> line 26, in state_forwards
> state.models[app_label, self.model_name.lower()].fields.append((
> self.name, field))
> KeyError: ('myapp', u'user')
>
>
> I need to add just one column using builtin migrations. 
> How to do that?
> This is bug or feature?
>
> BR,
> Marcin
>

-- 
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/336848e0-5ce2-41fb-b883-35c1fe38ad79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Carl Meyer]

On 08/25/2015 09:23 AM, Marcin Nowak wrote:
> On 25 August 2015 at 17:04, Carl Meyer  > wrote:
> 
> Hmm, yes, third-party apps are an issue.
> 
> My recollection from the last time you brought this up is that we
> decided an AppConfig-level setting to do the equivalent of managed=False
> for an entire app would be a reasonable feature request. Since you can
> provide your own AppConfig for third-party apps, this would cover that
> use case, too.
> 
> 
> That would be a better than nothing and it's flexible.
> 
> But in the most of my cases I will need to provide app configs for all
> apps. This can mean a lot of unnecessary work.
> Something like 'disable all' is simplest solution, but naturally limited.
> 
> Maybe there is a solution for both?

Sometimes when you have unusual requirements you have to do a little
more work to meet them. To my knowledge, out of the many hundreds of
thousands of Django users, you are the first and only one to request a
way to turn off migrations entirely. So I don't think there is a very
strong need to make that easy, when we can add a more flexible feature
that makes it possible.

It is not possible to build a framework where _everything_ is easy. We
aim for "Simple things should be easy, advanced things should be possible."

Carl

-- 
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/55DC8971.9030308%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Turn off migrations completely in Django 1.7

[Marcin Nowak]

> > Maybe there is a solution for both?
>
> Sometimes when you have unusual requirements you have to do a little
> more work to meet them. To my knowledge, out of the many hundreds of
> thousands of Django users, you are the first and only one to request a
> way to turn off migrations entirely.


Maybe no one else talks about it. I don't believe that there are no other
database-centric projects, where Django is used to map (external) database
tables to objects and generate some HTML or RESTful output.


> It is not possible to build a framework where _everything_ is easy. We
> aim for "Simple things should be easy, advanced things should be possible."
>
>
Well.. I would like to do something as hard as usual, but turn off some
unnecessary stuff. Same as not including "django.contrib.admin" in
INSTALLED_APPS, same as switching template engine to Jinja2, or same as
removing unnecessary middleware.

I just thought that skipping some function calls is simplest than creating
new feature for building workarounds, and even will be shorter than time
for talking about it. But I was wrong.

BR,
Marcin

-- 
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/CAB2m7CzEFcvjOO9685rQ5cqV6oo08a%2BzVs-%2BmkEqu%3DBZ4bFf7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Marcin Nowak]

On 25 August 2015 at 17:04, Carl Meyer  wrote:

> Hmm, yes, third-party apps are an issue.
>
> My recollection from the last time you brought this up is that we
> decided an AppConfig-level setting to do the equivalent of managed=False
> for an entire app would be a reasonable feature request. Since you can
> provide your own AppConfig for third-party apps, this would cover that
> use case, too.
>

That would be a better than nothing and it's flexible.

But in the most of my cases I will need to provide app configs for all
apps. This can mean a lot of unnecessary work.
Something like 'disable all' is simplest solution, but naturally limited.

Maybe there is a solution for both?

BR,
Marcin

-- 
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/CAB2m7CxVLc1MAYJT1f0h7DjwJGwkjqs3Ksvb%3D4bpi%2Bjiq7MbMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Marcos Eliziario]

Changing the database accidentally can be avoided simply by adjusting the 
privileges of the database user django uses. 

Flexibility in a software project always come out at the expense of 
simplicity. So, generally, django developers are right to avoid rarely need 
features in exchange for a simple, more testable code base. 

It may look simple, but in the end it is not. Think about all the tests 
that presume you have migrations enabled, your simple change would require 
new tests to try to ensure it doesn't break anything and at least a 
thorough check.

The thing is, nobody ever requested that, it is not a popular feature 
request, so, it is not there and won't be there unless someone contributes 
with a solid patch and a solid case for this added complexity

On Tuesday, August 25, 2015 at 12:55:29 PM UTC-3, Marcin Nowak wrote:
>
>
> > Maybe there is a solution for both?
>>
>> Sometimes when you have unusual requirements you have to do a little
>> more work to meet them. To my knowledge, out of the many hundreds of
>> thousands of Django users, you are the first and only one to request a
>> way to turn off migrations entirely. 
>
>
> Maybe no one else talks about it. I don't believe that there are no other 
> database-centric projects, where Django is used to map (external) database 
> tables to objects and generate some HTML or RESTful output.
>  
>
>> It is not possible to build a framework where _everything_ is easy. We
>> aim for "Simple things should be easy, advanced things should be 
>> possible."
>>
>>
> Well.. I would like to do something as hard as usual, but turn off some 
> unnecessary stuff. Same as not including "django.contrib.admin" in 
> INSTALLED_APPS, same as switching template engine to Jinja2, or same as 
> removing unnecessary middleware. 
>
> I just thought that skipping some function calls is simplest than creating 
> new feature for building workarounds, and even will be shorter than time 
> for talking about it. But I was wrong. 
>
> BR,
> Marcin
>
>

-- 
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/298493b8-8d01-435d-a2b3-cb4d2a1ab77b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Turn off migrations completely in Django 1.7

[Marcin Nowak]

On 25 August 2015 at 18:44, Marcos Eliziario 
wrote:

Changing the database accidentally can be avoided simply by adjusting the
> privileges of the database user django uses.


It's not perfect. The connection requires write access and Django inserts
some data automatically.
But table-level grants can be a paritial solution.

And still Django complains about unapplied migrations...


The thing is, nobody ever requested that, it is not a popular feature
> request, so, it is not there and won't be there unless someone contributes
> with a solid patch and a solid case for this added complexity


I would like to provide solid patch as a pull request, but I'm afraid that
it will be rejected due to some kind of spirit, politics or something
else.

BR,
Marcin

-- 
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/CAB2m7Cyn4rTb-8Y5QJynjhd4puYDVwNv4FaKay446J7W%3DvGUmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Forms questions

[Hugo Kitano]

Here it is, very simple:

 Submit form: 

{% csrf_token %}
{{ form.as_p }}





On Monday, August 24, 2015 at 4:31:47 PM UTC-7, Sait Maraşlıoğlu wrote:
>
> Can you provide the template code?
>
>
> On Tuesday, 25 August 2015 00:16:40 UTC+3, Hugo Kitano wrote:
>>
>> Hi, I'm trying to figure out what's wrong with my form:
>>
>> I've noticed that every time I load my submit view, the request.method is 
>> GET not POST, so nothing gets saved to the database.
>>
>>
>> Here's views.py
>>
>>
>> models.py
>>
>>
>> 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/92cc7199-3794-43d6-8692-76d0655119e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using ModelForms

[Hugo Kitano]

Noted.  "/stat/s" is an index page.  Here is what my urls.py looks like.  
Also, by using print statements, I've realized that the request.method is 
always GET, not POST, which makes it so no model instance is ever saved.  
What does this GET request refer to specifically?

Thanks






On Monday, August 24, 2015 at 3:29:40 PM UTC-7, Hugo Osvaldo Barrera wrote:
>
>  
> On Mon, Aug 24, 2015, at 16:41, Hugo Kitano wrote:
>
> I'm actually now pretty certain that my html file is what's causing it to 
> not work
>  
>
>  
> Including your message as an inline image rather than simple text will 
> reduce the amount of people that can actually read your message (and 
> complicate following the thread).
>  
> Does "/stats/" point to the above mentioned view ("submit")? What does 
> your urls.py look like? Did you try putting a "print" (or anything alike) 
> into the view function to really make sure it's the one being called?
>  
> --
> Hugo Osvaldo Barrera
>  
>

-- 
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/fa0965d5-6286-41e3-b408-3ddf2f42664c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working with FileFields/FieldFiles

[Hugo Kitano]

I guess my question is more "dumb" than that.  I need a concatenated string 
"*a**b*" where *a *is given and *b *is the name of a file uploaded to a 
field in a model.

Thanks!


On Saturday, August 22, 2015 at 2:55:03 PM UTC-7, Hugo Osvaldo Barrera 
wrote:
>
>  
>  
>  
> On Fri, Aug 21, 2015, at 14:28, Hugo Kitano wrote:
>
> Hi, I'm a beginner with Django, and I'm trying to figure out how to work 
> with FieldFiles.
>  
> One of my models has a FileField in which the user must submit a .bed 
> file.  I use another library in python to analyze the .bed file.
> The .bed file is saved to a specific directory on disk, and I want
>  
> file_on_disk = Bed('/Users/.../media/statistics.bed')
>  
> where statistics.bed is the name of the file, and media is the directory 
> all files are saved to.  How would I construct this line of code?
>  
> Thanks!
>
>  
> You're probably after the upload_to argument of FileField, which let you 
> define where files are saved:
>  
> 
> https://docs.djangoproject.com/en/1.8/ref/models/fields/#django.db.models.FileField.upload_to
>  
> (I assume you're already looked into MEDIA_ROOT):
>  
> https://docs.djangoproject.com/en/1.8/ref/settings/#media-root
>  
> --
> Hugo Osvaldo Barrera
>  
>

-- 
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/0341ccce-e637-40fc-b971-0b2fb5d0c624%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Working with FileFields/FieldFiles

['Hugo Osvaldo Barrera' via Django users]

On Tue, Aug 25, 2015, at 14:31, Hugo Kitano wrote:
> I guess my question is more "dumb" than that.  I need a concatenated
> string "*a**b*" where *a *is given and *b *is the name of a file
> uploaded to a field in a model.
>
> Thanks!

Something like this?

class Blah(models.Model):    def upload_to(self,
filename="untitled", instance=None):    return "somestring"
+ filename

data = FileField(upload_to=upload_to)

>
> On Saturday, August 22, 2015 at 2:55:03 PM UTC-7, Hugo Osvaldo
> Barrera wrote:
>>
>>
>>
>> On Fri, Aug 21, 2015, at 14:28, Hugo Kitano wrote:
>>> Hi, I'm a beginner with Django, and I'm trying to figure out how to
>>> work with FieldFiles.
>>>
>>> One of my models has a FileField in which the user must submit a
>>> .bed file.  I use another library in python to analyze the .bed
>>> file. The .bed file is saved to a specific directory on disk, and
>>> I want
>>>
>>> file_on_disk = Bed('/Users/.../media/statistics.bed')
>>>
>>> where statistics.bed is the name of the file, and media is the
>>> directory all files are saved to.  How would I construct this line
>>> of code?
>>>
>>> Thanks!
>>
>> You're probably after the upload_to argument of FileField, which let
>> you define where files are saved:
>>
>> https://docs.djangoproject.com/en/1.8/ref/models/fields/#django.db.models.FileField.upload_to
>>
>> (I assume you're already looked into MEDIA_ROOT):
>>
>> https://docs.djangoproject.com/en/1.8/ref/settings/#media-root
>>
>> --
>> Hugo Osvaldo Barrera
>>

--
Hugo Osvaldo Barrera
 

-- 
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/1440525802.2355699.365780817.21B3BB67%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using ModelForms

['Hugo Osvaldo Barrera' via Django users]

On Tue, Aug 25, 2015, at 14:16, Hugo Kitano wrote:
> Noted.  "/stat/s" is an index page.  Here is what my urls.py looks
> like.  Also, by using print statements, I've realized that the
> request.method is always GET, not POST, which makes it so no model
> instance is ever saved.  What does this GET request refer to
> specifically?
>
> Thanks
>
>
>
>
>

Your form posts to /stats/, but /stats/ does not map to your view method
`submit`. You need to post data to the view that's processing it, so fix
t form or the urls.py.

> On Monday, August 24, 2015 at 3:29:40 PM UTC-7, Hugo Osvaldo
> Barrera wrote:
>>
>> On Mon, Aug 24, 2015, at 16:41, Hugo Kitano wrote:
>>> I'm actually now pretty certain that my html file is what's causing
>>> it to not work
>>>
>>>
>>
>> Including your message as an inline image rather than simple text
>> will reduce the amount of people that can actually read your message
>> (and complicate following the thread).
>>
>> Does "/stats/" point to the above mentioned view ("submit")? What
>> does your urls.py look like? Did you try putting a "print" (or
>> anything alike) into the view function to really make sure it's the
>> one being called?
>>
>> --
>> Hugo Osvaldo Barrera
>>
> Email had 1 attachment:


>  * Auto Generated Inline Image 1  12k (image/png)

--
Hugo Osvaldo Barrera
 

-- 
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/1440525932.2355984.365782913.4B441EBD%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using ModelForms

[Hugo Kitano]

So the form should have action = '/stats/submit/' ? If I do this, whenever 
I click submit, it brings me back to the submission page, telling me that I 
didn't submit a file even if I did.

On Tuesday, August 25, 2015 at 11:05:59 AM UTC-7, Hugo Osvaldo Barrera 
wrote:
>
>  
> On Tue, Aug 25, 2015, at 14:16, Hugo Kitano wrote:
>
> Noted.  "/stat/s" is an index page.  Here is what my urls.py looks like.  
> Also, by using print statements, I've realized that the request.method is 
> always GET, not POST, which makes it so no model instance is ever saved.  
> What does this GET request refer to specifically?
>  
> Thanks
>  
>  
>  
>  
>
>  
> Your form posts to /stats/, but /stats/ does not map to your view method 
> `submit`. You need to post data to the view that's processing it, so fix t 
> form or the urls.py.
>  
>
> On Monday, August 24, 2015 at 3:29:40 PM UTC-7, Hugo Osvaldo Barrera wrote:
>
>  
> On Mon, Aug 24, 2015, at 16:41, Hugo Kitano wrote:
>
> I'm actually now pretty certain that my html file is what's causing it to 
> not work
>  
>
>  
> Including your message as an inline image rather than simple text will 
> reduce the amount of people that can actually read your message (and 
> complicate following the thread).
>  
> Does "/stats/" point to the above mentioned view ("submit")? What does 
> your urls.py look like? Did you try putting a "print" (or anything alike) 
> into the view function to really make sure it's the one being called?
>  
> --
> Hugo Osvaldo Barrera
>  
>
> Email had 1 attachment:
>
>- Auto Generated Inline Image 1
>  12k (image/png)
>
>  
> --
> Hugo Osvaldo Barrera
>  
>

-- 
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/5cd4b875-2f32-4dca-8a4b-231695fec586%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Forms questions

[Hugo Kitano]

I've realized that the action field in the form should be "/stats/submit/", 
the same view as the one that sent me to the template.  However, whenever I 
submit with the form then, it tells me that the file I submit is missing, 
even when it is definitely there.

On Tuesday, August 25, 2015 at 10:10:30 AM UTC-7, Hugo Kitano wrote:
>
> Here it is, very simple:
>
>  Submit form: 
> 
> {% csrf_token %}
> {{ form.as_p }}
> 
> 
>
>
>
> On Monday, August 24, 2015 at 4:31:47 PM UTC-7, Sait Maraşlıoğlu wrote:
>>
>> Can you provide the template code?
>>
>>
>> On Tuesday, 25 August 2015 00:16:40 UTC+3, Hugo Kitano wrote:
>>>
>>> Hi, I'm trying to figure out what's wrong with my form:
>>>
>>> I've noticed that every time I load my submit view, the request.method 
>>> is GET not POST, so nothing gets saved to the database.
>>>
>>>
>>> Here's views.py
>>>
>>>
>>> models.py
>>>
>>>
>>> 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/5b3c906a-8902-41f4-82b6-e2140ac0efae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Migrating old users into custom user model

[Ben Wattie]

Hello,

I have an existing project with migrations, datamigrations and I need a 
custom user model now, not just 1-1 profile so I created one.

However, when I switch the AUTH_USER_MODEL setting, I can't access the old 
auth.user model for my datamigration

def transfer_users(apps, schema_editor):
OldUser = apps.get_model('auth', 'User')
User = apps.get_model('users', 'User')
for old_user in OldUser.objects.all():
new_user = User.objects.create(
date_joined=old_user.date_joined,
email=old_user.email and old_user.email or '%s...@example.com' % 
old_user.username,
first_name=old_user.first_name,
id=old_user.id,
is_active=old_user.is_active,
is_staff=old_user.is_staff,
is_superuser=old_user.is_superuser,
last_login=old_user.last_login,
last_name=old_user.last_name,
password=old_user.password)
for perm in old_user.user_permissions.all():
new_user.user_permissions.add(perm)
for group in old_user.groups.all():
new_user.groups.add(group)


class Migration(migrations.Migration):

dependencies = [
('users', '0001_initial'),
('auth', '0006_require_contenttypes_0002'),
]

operations = [
migrations.RunPython(transfer_users)
]


Running this migration gives 

> AttributeError: Manager isn't available; User has been swapped for 
> 'users.User'

When trying to use OldUser.objects.all()

Is there another way to do this? Preferably in a datamigration not using a 
database shell


-- 
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/7d85a040-ddc3-4c8e-8c8a-ed4d302baa87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrating old users into custom user model

[Carl Meyer]

Hi Ben,

On 08/25/2015 03:33 PM, Ben Wattie wrote:
> I have an existing project with migrations, datamigrations and I need a
> custom user model now, not just 1-1 profile so I created one.

Unfortunately, while this is technically possible (I haven't done it
myself, but I know at least one person who says they have), it's very
complex and requires a fair amount of familiarity with the migrations
system and use of the advanced SeparateDatabaseAndState operation. And
nobody, AFAIK, has written documentation on how to do it.

I don't believe this is really an acceptable state of affairs, so I've
filed https://code.djangoproject.com/ticket/25313 to at least clearly
acknowledge that it _ought_ to be fixed. I don't know when I'll get a
chance to work on it myself (not real likely unless I revisit an old
project, because nowadays I _always_ start every project with a custom
User model, to avoid this problem). Maybe the ideal scenario here is
that you figure it out and then write the docs on how it's done :-)

Sorry I can't give you a better answer,

Carl

-- 
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/55DCE528.5060605%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

New User Tips?

[John Thomas]

Hi Django-Users:

I am starting a project.  I just saw the tip below.  I was wondering if you
would share other tips you have.

   1. I _always_ start every project with a custom User model, to avoid
   this problem ["this problem" = "difficult to transfer to a custom user
   model."]


John Thomas

-- 
If you are not the intended recipient of this message, please promptly 
notify the sender of the transmission error, delete this message and do not 
disclose or make improper use of it. Electronic messages are not 
necessarily secure or error-free and can contain viruses, and the sender is 
not liable for any of these occurrences.

-- 
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/CAJ22gMD11fRGrCr-oE89Y1dCgEK2TUc%2BFc7batbdzTk3qf9T9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.7 migrations: Adding one field to User`s model

['Hugo Osvaldo Barrera' via Django users]

On Tue, Aug 25, 2015, at 08:51, marcin.j.no...@gmail.com wrote:
> Hi,
>
> I would like to add one field to User.
>
> I've created new model based on original Django`s user:
>
> class User(AbstractUser):    is_verified =
> models.BooleanField(default=False)
>
> class Meta:        db_table = 'auth_user'
>
>
> Now I'm trying to make migrations, but Django tries to create
> `auth_user` table from scratch, and this is not what I'm expecting.
>
> I've tried to migrate schema by adding one field:
>
> [...]     operations = [        migrations.AddField('User',
> 'is_verified', models.BooleanField(default=False)),    ]
>
> But during migrations Django dies at:
>
> [...]  File "eggs/Django-1.7.8-
> py2.7.egg/django/db/migrations/migration.py", line 76, in mutate_state
> operation.state_forwards(self.app_label, new_state)  File "eggs/Django-1.7.8-
> py2.7.egg/django/db/migrations/operations/fields.py", line 26, in
> state_forwards    state.models[app_label,
> self.model_name.lower()].fields.append((self.name, field)) KeyError:
> ('myapp', u'user')
>
>
> I need to add just one column using builtin migrations. How to do
> that? This is bug or feature?
>
> BR, Marcin

Here's how I'd get around this (I've recently worked on a project with
an existing db where we needed to track new changes via migrations, and
this is what we did).

I'm assuming your project has no existing migrations. If it does, it
should not include migrations for this specific model. If it does,
you've another problem.

1. Create an initial migrations with the model that matches the
   existing database.
2. Add any new fields, etc.
3. Create new migrations that apply changes.
4. Run python manage.py migrate --fake-initial. This will skip the
   *first* migrations for tables that exist, and proceed with other
   ones. Since the first migration would have created a table that looks
   like your existing one, that's not an issue. The following migrations
   will add a field

Lemme know if this helps.

--
Hugo Osvaldo Barrera
 

-- 
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/1440542514.2465730.366012897.1630E7F6%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrating old users into custom user model

[Ben Wattie]

Hi Carl, 

Thanks for your reply.
If I figure it out I would surely submit doc, but it's more likely that I 
will just come up with a workaround.

Starting a project with a custom user model every time just to avoid this 
doesn't feel so great since the documentation just says things like 
 "probably don't use a custom user model, even though its supported, use 
1-1 profile instead"
But then later on the track requirements can change and you need a custom 
model but its very difficult to migrate.



On Wednesday, August 26, 2015 at 9:59:37 AM UTC+12, Carl Meyer wrote:
>
> Hi Ben, 
>
> On 08/25/2015 03:33 PM, Ben Wattie wrote: 
> > I have an existing project with migrations, datamigrations and I need a 
> > custom user model now, not just 1-1 profile so I created one. 
>
> Unfortunately, while this is technically possible (I haven't done it 
> myself, but I know at least one person who says they have), it's very 
> complex and requires a fair amount of familiarity with the migrations 
> system and use of the advanced SeparateDatabaseAndState operation. And 
> nobody, AFAIK, has written documentation on how to do it. 
>
> I don't believe this is really an acceptable state of affairs, so I've 
> filed https://code.djangoproject.com/ticket/25313 to at least clearly 
> acknowledge that it _ought_ to be fixed. I don't know when I'll get a 
> chance to work on it myself (not real likely unless I revisit an old 
> project, because nowadays I _always_ start every project with a custom 
> User model, to avoid this problem). Maybe the ideal scenario here is 
> that you figure it out and then write the docs on how it's done :-) 
>
> Sorry I can't give you a better answer, 
>
> Carl 
>
>

-- 
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/7a22af3d-46d9-4b3b-aa51-368c6d0089eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrating old users into custom user model

[Carl Meyer]

Hi Ben,

On 08/25/2015 05:14 PM, Ben Wattie wrote:
> Thanks for your reply.
> If I figure it out I would surely submit doc, but it's more likely that
> I will just come up with a workaround.

Fair enough :-)

> Starting a project with a custom user model every time just to avoid
> this doesn't feel so great since the documentation just says things like
>  "probably don't use a custom user model, even though its supported, use
> 1-1 profile instead"
> But then later on the track requirements can change and you need a
> custom model but its very difficult to migrate.

And that's why the docs are simply wrong when they say that, and should
be changed. See https://code.djangoproject.com/ticket/24370

Carl

-- 
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/55DCF751.9020204%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: New User Tips?

[Lachlan Musicman]

1. Do the tutorial if you've never used Django before
2. Keep your code in a repo, have a dev site and a prod site at least
3. Use virtualenv
4. This list is a good place to come for support. Also, the IRC channel
with FunkyBob.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 26 August 2015 at 08:09, John Thomas 
wrote:

> Hi Django-Users:
>
> I am starting a project.  I just saw the tip below.  I was wondering if
> you would share other tips you have.
>
>1. I _always_ start every project with a custom User model, to avoid
>this problem ["this problem" = "difficult to transfer to a custom user
>model."]
>
>
> John Thomas
>
>
> If you are not the intended recipient of this message, please promptly
> notify the sender of the transmission error, delete this message and do not
> disclose or make improper use of it. Electronic messages are not
> necessarily secure or error-free and can contain viruses, and the sender is
> not liable for any of these occurrences.
>
> --
> 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/CAJ22gMD11fRGrCr-oE89Y1dCgEK2TUc%2BFc7batbdzTk3qf9T9A%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/CAGBeqiMSNsqMt-DQ4551%3DbKj7jDe-GdEgYcbiJfUonUBJ1M2Aw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Loading scikit model in Django

[Chih How Bong]

Hi guys, I have searched the answers for days with no avail, thus I would 
like to ask here.

I am running a svm scikit model in Django, currently, every request have to 
load the ~20mb scikit model, and it was really slow.

I wonder if I should load the model in settings.py, and store in in 
session? However, the scikit model can be updated by a certain user.

Any comment? I am rather new to django, thank 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/47bfb6d1-6e43-441f-ac8e-8ab2145113b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading scikit model in Django

[James Schneider]

> Hi guys, I have searched the answers for days with no avail, thus I would
like to ask here.
>
> I am running a svm scikit model in Django, currently, every request have
to load the ~20mb scikit model, and it was really slow.
>
> I wonder if I should load the model in settings.py, and store in in
session? However, the scikit model can be updated by a certain user.
>
> Any comment? I am rather new to django, thank in advance.

Have you thought at all about using a cache system such as memcached? The
initial load would probably be slow, but it's possible that subsequent
access to that same object would see a speed improvement. You would need to
establish a workflow that ensures the object stays up to date whenever
changes are made, but repeated reads would likely see a substantial
improvement.

Storing that amount of data in the session would not have the desired
effect, if anything, things would probably get worse, depending on the
backend used to store sessions. Sessions are reloaded during every request
(and therefore probably not addressing your issue), whereas a cache system
is meant to hold things in an easy/quickly accessible format and location,
independent of the request/response cycle.

-James

https://docs.djangoproject.com/en/1.8/topics/cache/#memcached

-- 
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/CA%2Be%2BciWYbdmvuTcsf2XN%3DUT4ZCCmMfOVOQgSq4pgLKboOYHqQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading scikit model in Django

[Chih How Bong]

Thanks you James for your suggestion. I am going to look into the memcached 
now.

I was thinking that the ideal solution will be to load the model into a 
global variable, then the request can use refer to this variable for the 
model. I don't know if that possible.

Thanks.

On Wednesday, August 26, 2015 at 10:14:04 AM UTC+8, James Schneider wrote:
>
>
> > Hi guys, I have searched the answers for days with no avail, thus I 
> would like to ask here.
> >
> > I am running a svm scikit model in Django, currently, every request have 
> to load the ~20mb scikit model, and it was really slow.
> >
> > I wonder if I should load the model in settings.py, and store in in 
> session? However, the scikit model can be updated by a certain user.
> >
> > Any comment? I am rather new to django, thank in advance.
>
> Have you thought at all about using a cache system such as memcached? The 
> initial load would probably be slow, but it's possible that subsequent 
> access to that same object would see a speed improvement. You would need to 
> establish a workflow that ensures the object stays up to date whenever 
> changes are made, but repeated reads would likely see a substantial 
> improvement.
>
> Storing that amount of data in the session would not have the desired 
> effect, if anything, things would probably get worse, depending on the 
> backend used to store sessions. Sessions are reloaded during every request 
> (and therefore probably not addressing your issue), whereas a cache system 
> is meant to hold things in an easy/quickly accessible format and location, 
> independent of the request/response cycle.
>
> -James
>
> https://docs.djangoproject.com/en/1.8/topics/cache/#memcached
>

-- 
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/9959b7ab-8bd8-438f-b7cf-fecff475b5cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading scikit model in Django

[James Schneider]

> Thanks you James for your suggestion. I am going to look into the
memcached now.
>
> I was thinking that the ideal solution will be to load the model into a
global variable, then the request can use refer to this variable for the
model. I don't know if that possible.
>

Possible...yes. Good idea? Well, let's just say a cache is what you need in
this case. I'm hoping that your objects can be serialized or pickled, that
will make them much easier to store in the cache. This will also make it
easier to support concurrent users with different objects in the cache.

The tough part is going to be maintaining a consistent state for the object
in the cache if the user is making changes to it (updating the instance and
then updating the cache with the new object so that further request are
working with current data).

You may also want to consider handling changes via a batch job processor
such as Celery if the updates are lengthy (locking the object for updates,
retrieving the object, updating it, saving it to the DB or a file, and then
updating the cache with the new version). That way your users get an
instant response saying that their changes have been submitted and the
updated version should be available shortly. It really depends on your user
base and the timing of operations.

Start with implementing the cache, once that is working, look at a batch
processor like celery if the response is still less than desirable, since
there is a fair amount of setup required to get a batch processor online.

I've never worked with custom memcached entries, so I've reached the end of
my knowledge scope here.

-James

-- 
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/CA%2Be%2BciWAWUOBetHzxWysq4WXiUhnvftf%2BJ0N-p%3Djs2zWYt4Hhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.