Re: Django 1.9 ./manage.py migrate error

[Xuton Ion]

Thanks for the assistance so far.

Reading https://docs.djangoproject.com/en/1.9/topics/migrations/ it says I 
should be able to run migrate to apply migrations.
But does this mean I have to manually do something, or should that work the 
same as it did on 1.8?

I am assuming that it should also be able to create the database from the 
model with just running that one command.

When creating a new project the migrate line runs fine, so it seems to be 
something specific to the project. I cant share the project though

On Saturday, 12 December 2015 19:14:55 UTC+2, Tim Graham wrote:
>
> Is there a reason you can't use migrations? --run-syncdb is really only 
> meant for huge projects (hundreds or thousands of models) where migrations 
> are too slow. Not sure why it's not working though. You'd have to project a 
> sample project for me to debug further.
>
> On Saturday, December 12, 2015 at 11:53:37 AM UTC-5, Xuton Ion wrote:
>>
>> No, I haven't added any migrations. 
>>
>> I did try with --run-syncdb though, and still had the same error though
>>
>> On Saturday, 12 December 2015 16:26:15 UTC+2, Tim Graham wrote:
>>>
>>> Does your application have migrations? Quoting the 1.9 release notes, 
>>> "Automatic syncing of apps without migrations is removed. Migrations are 
>>> compulsory for all apps unless you pass the --run-syncdb 
>>> 
>>>  
>>> option to migrate."
>>>
>>> On Saturday, December 12, 2015 at 8:42:58 AM UTC-5, Xuton Ion wrote:

 Hi

 I seem to have an issue with running migrate and have been googling all 
 day without any luck

 I have an app which works and runs on 1.8
 After cloning the repo and creating a new ve, I ended up with Django 1.9

 Running the ./manage.py migrate creates the database, but none of the 
 tables from the model. It returns
 django.db.utils.OperationalError: no such table: table_name

 If I delete the db.sqlite3 (still in dev so not postgress yet), 
 deactivate my ve and use my ve with django 1.8, the migrate line runs 
 fine. 
 If I then re-activate my ve with 1.9, everything works fine. I can make 
 changes and run makemigrations, and it works. But the initial state seems 
 to not work

 Anyone else have the same issue, or have some advice for me?

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/71fbdcc6-9851-4b00-8818-33167f47f927%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: git exclude files

[Scot Hacker]

On Saturday, December 12, 2015 at 7:38:21 AM UTC-8, Gary Roach wrote:
>
> Unfortunately, venv doesn't give me a choice as to where the files are 
> stored. They are all under the top directory of the same name as the 
> project but are actually in the same directory as the top level project 
> folder. ie /root/archive/ venv files, and archive/ project. From what you 
> say, they should not be included in the git source control. 
>

I think the misunderstanding here is that you're thinking you should put 
your project code into the venv/virtualenv directory. That's not really how 
it's intended to be used. A typical setup might be:

~/virtualenvs/myproject
~/dev/myproject

When you activate myproject, the corresponding virtualenv is placed on your 
python path, so the libs it contains are available to you, and your pip 
installs end up there. But you do *your own* work in ~/dev/myproject. 
Complete separation of installed libs from your own project code. The 
question you're asking should never come up.

./s

 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/71e3a0b0-9ac4-4728-aca6-c1abd86f884a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9 ./manage.py migrate error

[Tim Graham]

Is there a reason you can't use migrations? --run-syncdb is really only 
meant for huge projects (hundreds or thousands of models) where migrations 
are too slow. Not sure why it's not working though. You'd have to project a 
sample project for me to debug further.

On Saturday, December 12, 2015 at 11:53:37 AM UTC-5, Xuton Ion wrote:
>
> No, I haven't added any migrations. 
>
> I did try with --run-syncdb though, and still had the same error though
>
> On Saturday, 12 December 2015 16:26:15 UTC+2, Tim Graham wrote:
>>
>> Does your application have migrations? Quoting the 1.9 release notes, 
>> "Automatic syncing of apps without migrations is removed. Migrations are 
>> compulsory for all apps unless you pass the --run-syncdb 
>> 
>>  
>> option to migrate."
>>
>> On Saturday, December 12, 2015 at 8:42:58 AM UTC-5, Xuton Ion wrote:
>>>
>>> Hi
>>>
>>> I seem to have an issue with running migrate and have been googling all 
>>> day without any luck
>>>
>>> I have an app which works and runs on 1.8
>>> After cloning the repo and creating a new ve, I ended up with Django 1.9
>>>
>>> Running the ./manage.py migrate creates the database, but none of the 
>>> tables from the model. It returns
>>> django.db.utils.OperationalError: no such table: table_name
>>>
>>> If I delete the db.sqlite3 (still in dev so not postgress yet), 
>>> deactivate my ve and use my ve with django 1.8, the migrate line runs fine. 
>>> If I then re-activate my ve with 1.9, everything works fine. I can make 
>>> changes and run makemigrations, and it works. But the initial state seems 
>>> to not work
>>>
>>> Anyone else have the same issue, or have some advice for me?
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/19087e81-b933-46de-94c4-d1f2eaac217c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: a bug in model.Manager.values_list?

[knbk]

Models and querysets are not serializeable using the default `json` tools, 
but Django provides its own set of tools that allow you to serialize models 
and querysets. Take a look at serializing django objects 

. 

On Saturday, December 12, 2015 at 5:41:16 PM UTC+1, Derek wrote:
>
> "Its not a bug, its a feature."
>
> See: 
> https://docs.djangoproject.com/en/1.9/ref/models/querysets/#when-querysets-are-evaluated
>
> If you were designing Django's internals, you might have decided that the 
> Queryset "should behave" in a certain way, but the designers have chosen 
> this approach.  There is no "disguise" about this; it's well-known and 
> well-documented.
>
>
> On Friday, 11 December 2015 15:43:45 UTC+2, Ws Hu wrote:
>>
>> import json
>> from myapp.models import MyModel
>>
>>
>> x = json.dumps(MyModel.objects.values_list('myField', flat=True)) # "[] 
>> is not JSON serializable"
>> x = json.dumps([x for x in MyModel.objects.values_list('myField', flat=
>> True)]) #ok
>>
>>
>>
>> 
>> It seems that the database is accessed only if the result of 
>> objects.filter()/all()/values_list()/... is printed/iterated/... .
>> It's fine, but I think the methods of model manager like 
>> filter()/all()/values_list() should behave as if it is processing python 
>> objects. I have not yet digged into json module, but it did penetrated 
>> django's disguise.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1a244212-cb4a-4917-b6a4-901081e555d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9 ./manage.py migrate error

[Xuton Ion]

No, I haven't added any migrations. 

I did try with --run-syncdb though, and still had the same error though

On Saturday, 12 December 2015 16:26:15 UTC+2, Tim Graham wrote:
>
> Does your application have migrations? Quoting the 1.9 release notes, 
> "Automatic syncing of apps without migrations is removed. Migrations are 
> compulsory for all apps unless you pass the --run-syncdb 
> 
>  
> option to migrate."
>
> On Saturday, December 12, 2015 at 8:42:58 AM UTC-5, Xuton Ion wrote:
>>
>> Hi
>>
>> I seem to have an issue with running migrate and have been googling all 
>> day without any luck
>>
>> I have an app which works and runs on 1.8
>> After cloning the repo and creating a new ve, I ended up with Django 1.9
>>
>> Running the ./manage.py migrate creates the database, but none of the 
>> tables from the model. It returns
>> django.db.utils.OperationalError: no such table: table_name
>>
>> If I delete the db.sqlite3 (still in dev so not postgress yet), 
>> deactivate my ve and use my ve with django 1.8, the migrate line runs fine. 
>> If I then re-activate my ve with 1.9, everything works fine. I can make 
>> changes and run makemigrations, and it works. But the initial state seems 
>> to not work
>>
>> Anyone else have the same issue, or have some advice for me?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c847e7d7-1f2b-45d3-97ef-1a5a6a52b39a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: a bug in model.Manager.values_list?

[Derek]

"Its not a bug, its a feature."

See: 
https://docs.djangoproject.com/en/1.9/ref/models/querysets/#when-querysets-are-evaluated

If you were designing Django's internals, you might have decided that the 
Queryset "should behave" in a certain way, but the designers have chosen 
this approach.  There is no "disguise" about this; it's well-known and 
well-documented.


On Friday, 11 December 2015 15:43:45 UTC+2, Ws Hu wrote:
>
> import json
> from myapp.models import MyModel
>
>
> x = json.dumps(MyModel.objects.values_list('myField', flat=True)) # "[] 
> is not JSON serializable"
> x = json.dumps([x for x in MyModel.objects.values_list('myField', flat=
> True)]) #ok
>
>
>
> 
> It seems that the database is accessed only if the result of 
> objects.filter()/all()/values_list()/... is printed/iterated/... .
> It's fine, but I think the methods of model manager like 
> filter()/all()/values_list() should behave as if it is processing python 
> objects. I have not yet digged into json module, but it did penetrated 
> django's disguise.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/122c7ed6-a79d-4c84-b5fa-28899040f64d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: git exclude files

[Gary Roach]

Unfortunately, venv doesn't give me a choice as to where the files are 
stored. They are all under the top directory of the same name as the 
project but are actually in the same directory as the top level project 
folder. ie /root/archive/ venv files, and archive/ project. From what 
you say, they should not be included in the git source control.


Gary R

On 12/11/2015 02:51 PM, Tim Graham wrote:
I don't know of a use case where virtualenvs are stored in source 
control. I wouldn't recommend putting the virtual environment in your 
project folder either. If you use a tool like virtualenvwrapper [1] 
you can store all your virtualenvs in a single directory on your 
system to make managing them easy.


[1] https://virtualenvwrapper.readthedocs.org/

On Friday, December 11, 2015 at 4:08:29 PM UTC-5, Gary Roach wrote:

Since Python3, venv seems to be preferable to virtualenv. Most of the
howto's are for virtualenv. The file setup between the two is
completely
different. So do I include the bin/, include/, lib/, and the lib64 ->
/root/archive/lib files in the git repository or should they be
excluded. If the need to be excluded, how.

This is a Django 1.8, Python3.4 project, Debian 8 (jessie) project.

Gary R

--
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/0aa43312-1070-4c21-94ca-4a39cd15096a%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/566C3F47.4%40verizon.net.
For more options, visit https://groups.google.com/d/optout.

Re: Populating default data into sql tables using sql file inside the sql folder of app is not working

[Tim Graham]

You can use migrations and the RunSQL operation.

https://docs.djangoproject.com/en/stable/ref/migration-operations/#runsql

On Saturday, December 12, 2015 at 8:59:08 AM UTC-5, naveen tamanam wrote:
>
> In older django versions I use to load the default values using sql files 
> which are in the folder sql in side the app directory. But in django.1.9c1 
> it's not working. 
>When I look at django documentation it seems like support raw sql file 
> is removed to load the default data. 
>   How to load the dafault data using  raw sql queries. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f560714c-0546-4d98-8986-d3e32ff4a5b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 1.9 ./manage.py migrate error

[Tim Graham]

Does your application have migrations? Quoting the 1.9 release notes, 
"Automatic syncing of apps without migrations is removed. Migrations are 
compulsory for all apps unless you pass the --run-syncdb 

 
option to migrate."

On Saturday, December 12, 2015 at 8:42:58 AM UTC-5, Xuton Ion wrote:
>
> Hi
>
> I seem to have an issue with running migrate and have been googling all 
> day without any luck
>
> I have an app which works and runs on 1.8
> After cloning the repo and creating a new ve, I ended up with Django 1.9
>
> Running the ./manage.py migrate creates the database, but none of the 
> tables from the model. It returns
> django.db.utils.OperationalError: no such table: table_name
>
> If I delete the db.sqlite3 (still in dev so not postgress yet), deactivate 
> my ve and use my ve with django 1.8, the migrate line runs fine. 
> If I then re-activate my ve with 1.9, everything works fine. I can make 
> changes and run makemigrations, and it works. But the initial state seems 
> to not work
>
> Anyone else have the same issue, or have some advice for me?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/1e3e71e3-762e-4b1c-a780-5c7792a94027%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Populating default data into sql tables using sql file inside the sql folder of app is not working

[naveen tamanam]

In older django versions I use to load the default values using sql files
which are in the folder sql in side the app directory. But in django.1.9c1
it's not working.
   When I look at django documentation it seems like support raw sql file
is removed to load the default data.
  How to load the dafault data using  raw sql queries.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAMQEg5f1Y5xAHaeoHLAtOUam7sJPvNptkx4XD9a%3DqO97DbF%2BBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Tool to document project urls, views, templates, etc...

[Mat Gessel]

Anyone know of a tool that can analyze a project and generate a list or
graph of *views* & related information?

I'm maintaining a medium size Django project. For each feature/change, I am
finding myself creating a "map" of the relevant view names/relationships
for quick reference. This includes:

   - URL pattern
   - URL pattern name
   - view class name
   - template file name

Example:

> /training/, course-list, TrainingCourseList,
> training/trainingcourse_list.html
> /training/courses//, course-detail, TrainingCourseDetail,
> training/trainingcourse_detail.html
> /training/courses//purchase/, course-cart, TrainingCourseCart,
> training/trainingcourse_cart.html
> /training/checkout/, course-checkout, TrainingCourseCheckout,
> training/trainingcourse_checkout.html


I'm new to Django and I like it so far, but identifying references is a bit
of a nuisance. I found manage.py graph_models, but that only processes
models.

I lieu of a tool, anyone have organizational practices they'd like to share?

Thanks,

-- 
Mat Gessel
http://www.asquare.net

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAGuKJ6%2BmZVeg7%2BUGdBijeiRhtjshT4bEU1MaDO4yADq41UmEWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django 1.9 ./manage.py migrate error

[Xuton Ion]

Hi

I seem to have an issue with running migrate and have been googling all day 
without any luck

I have an app which works and runs on 1.8
After cloning the repo and creating a new ve, I ended up with Django 1.9

Running the ./manage.py migrate creates the database, but none of the 
tables from the model. It returns
django.db.utils.OperationalError: no such table: table_name

If I delete the db.sqlite3 (still in dev so not postgress yet), deactivate 
my ve and use my ve with django 1.8, the migrate line runs fine. 
If I then re-activate my ve with 1.9, everything works fine. I can make 
changes and run makemigrations, and it works. But the initial state seems 
to not work

Anyone else have the same issue, or have some advice for me?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/58bc7f16-83d9-4ea9-82c6-1970b995fa78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.