Re: PROBLEM

[Carlton Gibson]

Hi David, 

This group is for "Contributions to Django itself". You need to head over 
to Django Users  for 
support questions.

(But it looks like you didn't save your urls.py — the `polls/` route isn't 
shown as being searched.) 

Good luck!

Kind Regards,

Carlton

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4e7d0d57-2a54-47a2-9f22-b027e23c3a91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem in makemigration

[utpalbrahma1995]

sorry sir.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b64879f6-dd16-488b-9bab-06b9df1ab64e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem in makemigration

[Adam Johnson]

This mailing list is for the development of Django itself, not for support.
Use the django-users mailing list for that, or IRC #django on freenode, or
a site like Stack Overflow.

On 20 March 2018 at 13:26,  wrote:

> Django is unable to detect new changes i have made in my models.py.I even
> deleted my database
> What is the solution?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/e4318c63-00a1-4a87-a0ab-
> f8600c906152%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

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

Re: Problem with running tests with mysql database.

[Josh Smeaton]

If you're having issues with specific environments and configuring all of 
the dependencies, you can try using https://github.com/django/django-box 
which is a Vagrant virtual machine running on Virtualbox. It has postgres, 
mysql, sqlite, and all of the pythons Django uses for testing. You could 
also just take a look at the settings files it uses for 
testing: https://github.com/django/django-box/tree/master/roles/djangodata/files

On Saturday, 11 March 2017 09:03:51 UTC+11, Anton Samarchyan wrote:
>
> I have a pull request in which some tests for some of environments are 
> failing. (it's fine for the default tests with sqlite and some others) - 
> https://github.com/django/django/pull/7994 
>
> Now, I am trying to run the tests with the database set to mysql.
>
> I added a file settings_mysql.py which I put in the tests folder: 
> http://pastebin.com/113Xx2Am 
>
> To try it out I use the master branch (commit 
> c577d8a4981233b4d0f65c6ce57ae33d304095b9).
>
> Then I run ./runtests.py --settings settings_mysql and I am getting errors.
>
> Then I rerun it with parallel=1 - ./runtests.py --settings settings_mysql 
> --parallel=1
>
> and I get the following result:
>
> FAILED (failures=56, errors=42, skipped=1046, expected failures=4)
>
> Full log - https://paste.ee/p/Tfc9H
>
> Does anyone have an idea what might be wrong and what is the best way to 
> run tests for different databases?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/78cfa185-0443-4d78-a059-f3c016209d71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with running tests with mysql database.

[Adam Johnson]

For the lock wait timeout errors, it's probable something (another test
run?) is still connected to the database and holding the locks. Try
restarting mysql.

And if you are still having problems, knowing the version of MySQL you're
using, plus how you installed it, would be helpful.

On 10 March 2017 at 22:14, Tim Graham  wrote:

> For the error, "Database returned an invalid datetime value. Are time zone
> definitions for your database installed?", see https://docs.djangoproject.
> com/en/dev/ref/databases/#time-zone-definitions.
>
> Adding this to the 'default' and 'other' dictionaries in DATABASES may
> solve some of the encoding problems:
>
> 'TEST': {
> 'CHARSET': 'utf8',
> 'COLLATION': 'utf8_general_ci',
> },
>
> If you still have some errors after that, please post an updated output.
>
> On Friday, March 10, 2017 at 5:03:51 PM UTC-5, Anton Samarchyan wrote:
>>
>> I have a pull request in which some tests for some of environments are
>> failing. (it's fine for the default tests with sqlite and some others) -
>> https://github.com/django/django/pull/7994
>>
>> Now, I am trying to run the tests with the database set to mysql.
>>
>> I added a file settings_mysql.py which I put in the tests folder:
>> http://pastebin.com/113Xx2Am
>>
>> To try it out I use the master branch (commit
>> c577d8a4981233b4d0f65c6ce57ae33d304095b9).
>>
>> Then I run ./runtests.py --settings settings_mysql and I am getting
>> errors.
>>
>> Then I rerun it with parallel=1 - ./runtests.py --settings settings_mysql
>> --parallel=1
>>
>> and I get the following result:
>>
>> FAILED (failures=56, errors=42, skipped=1046, expected failures=4)
>>
>> Full log - https://paste.ee/p/Tfc9H
>>
>> Does anyone have an idea what might be wrong and what is the best way to
>> run tests for different databases?
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/6f86afff-c4c1-481e-8e17-
> 7aae2cf0bde7%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

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

Re: Problem with running tests with mysql database.

[Tim Graham]

For the error, "Database returned an invalid datetime value. Are time zone 
definitions for your database installed?", see 
https://docs.djangoproject.com/en/dev/ref/databases/#time-zone-definitions.

Adding this to the 'default' and 'other' dictionaries in DATABASES may 
solve some of the encoding problems:

'TEST': {
'CHARSET': 'utf8',
'COLLATION': 'utf8_general_ci',
},

If you still have some errors after that, please post an updated output.

On Friday, March 10, 2017 at 5:03:51 PM UTC-5, Anton Samarchyan wrote:
>
> I have a pull request in which some tests for some of environments are 
> failing. (it's fine for the default tests with sqlite and some others) - 
> https://github.com/django/django/pull/7994 
>
> Now, I am trying to run the tests with the database set to mysql.
>
> I added a file settings_mysql.py which I put in the tests folder: 
> http://pastebin.com/113Xx2Am 
>
> To try it out I use the master branch (commit 
> c577d8a4981233b4d0f65c6ce57ae33d304095b9).
>
> Then I run ./runtests.py --settings settings_mysql and I am getting errors.
>
> Then I rerun it with parallel=1 - ./runtests.py --settings settings_mysql 
> --parallel=1
>
> and I get the following result:
>
> FAILED (failures=56, errors=42, skipped=1046, expected failures=4)
>
> Full log - https://paste.ee/p/Tfc9H
>
> Does anyone have an idea what might be wrong and what is the best way to 
> run tests for different databases?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6f86afff-c4c1-481e-8e17-7aae2cf0bde7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem UnicodeDecodeError when run createsuperuser

[Florian Apolloner]

Please show the output of the locale command and your full settings.

On Saturday, February 4, 2017 at 10:58:28 PM UTC+1, Lucas Simon Rodrigues 
Magalhaes wrote:
>
> Hello everyone,
>
> I have a problem when run createsuperuser.py command in python 3.4. How 
> can I solve it definitely?
>
> Look the code:
>
> https://gist.github.com/lucassimon/7837dce442e3a4a090ce4d155b4a2035
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/670b0076-723f-49fd-96f2-037474349ac8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem UnicodeDecodeError when run createsuperuser

[Bhanu jamwal]

or see indentation error


On Sunday, February 5, 2017 at 3:28:28 AM UTC+5:30, Lucas Simon Rodrigues 
Magalhaes wrote:
>
> Hello everyone,
>
> I have a problem when run createsuperuser.py command in python 3.4. How 
> can I solve it definitely?
>
> Look the code:
>
> https://gist.github.com/lucassimon/7837dce442e3a4a090ce4d155b4a2035
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f0bea241-27f4-47ac-b02a-32cb539be3ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with caching template loader

[Preston Timmons]

Yep, that looks wrong. Looks like it was added in this commit:

https://github.com/django/django/commit/f33db5a09acfc3df3085235a5712c46094eb9a0d

The test case could be improved also by checking the appropriate key is set.

Preston

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/de745f58-3ad6-4688-881f-1379a0e9a4ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with profile picture and mysql. URGENT !!

[Tim Graham]

This mailing list is for the development of Django. Please direct questions 
about how to use Django to the django-users mailing list.

On Friday, August 8, 2014 12:41:52 AM UTC-4, Swathi Rajanna wrote:
>
> My app does not use South as it keeps giving me django.core.management 
> Improperly Configured error. Hence I have to do syncdb every time. But 
> recently I wanted to add an image element to the previously created class 
> in models.py but it keeps giving me unknown element image in field list. I 
> tried dropping the table and reusing but it didn't work. If I try to alter 
> the table the select * from table shows empty set. Need urgent help on how 
> to add a profile picture to my user profile.
> Thanks !!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/13c9e896-0e56-4c28-98d7-4de061a24c08%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem migrating from South to Django migrations for Linux distributions

[Raphael Hertzog]

Hi Brian,

On Fri, 25 Jul 2014, Brian May wrote:
> I can't help but think this might be unrealistic (?). Changes required for
> new versions of Django often break compatibility with old versions, and
> 1.4.5 is really old now. Just because many packages don't have versioned
> dependencies on Django (or a versioned dependency on a really old version)
> doesn't necessarily mean they will work with any 1.4.5. Anyone want to test
> every Django package in Debian sid against the Django in wheezy?

I agree with you that this is not realistic. A better alternate solution
is to document the process of how to execute the South migrations with
Django 1.6 in a virtualenv after having done the upgrade to Debian 8.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

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

Re: Problem migrating from South to Django migrations for Linux distributions

[Raphael Hertzog]

Hi Andrew, 

thanks for your quick answer.

On Thu, 24 Jul 2014, Andrew Godwin wrote:
> There is no way around this; it's unfortunate that the packaging situation
> means that Django will get auto-upgraded as part of a distribution upgrade;
> I'm surprised that Debian hasn't had this with packages before? (Version
> upgrades that break installed but non-packaged things)

We probably had this kind of things before and the best we can do for
non-packaged things is usally to document this in the release notes.

But for packaged things, we try usually hard to get things to just work
without any human intervention. Hence my question.

> Neither of your suggested ways to go forward will work; the two history
> models are very different, so the tagging of positions isn't going to work,
> and Django 1.7 has changed substantially enough internally that porting
> South 1.x up to it would be a very large amount of work.

OK.

> Also, what are the applications in particular that this will be a problem
> for? I'm curious to know what Django + South things Debian is shipping
> these days.

Applications that depend on South and have different upstream versions
in Debian 7 and Debian 8 are:
http://tracker.debian.org/pkg/python-django-voting
http://tracker.debian.org/pkg/python-django-threadedcomments
http://tracker.debian.org/pkg/python-django-reversion
http://tracker.debian.org/pkg/python-django-picklefield
http://tracker.debian.org/pkg/bcfg2

Given the package names, it probably means only a single end-user application.
The others are Django "extensions" for use in non-packaged applications.

And looking more closely the case of bcfg2, the package in Debian 7 does
not use South, it started using South in the version in Jessie so it
should be easy to deal with.

For the 4 others, they should provide some NEWS.Debian entry warning
users of the potential upgrade problem.

(Bccing the 5 relevant bug reports to keep a record of this)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

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

Re: Problem migrating from South to Django migrations for Linux distributions

[Andrew Godwin]

So, South migrations will not work with Django 1.7. Period.

There is no way around this; it's unfortunate that the packaging situation
means that Django will get auto-upgraded as part of a distribution upgrade;
I'm surprised that Debian hasn't had this with packages before? (Version
upgrades that break installed but non-packaged things)

Neither of your suggested ways to go forward will work; the two history
models are very different, so the tagging of positions isn't going to work,
and Django 1.7 has changed substantially enough internally that porting
South 1.x up to it would be a very large amount of work.

How has Debian dealt with breaking changes like this in the past? Things
like Rails upgrades come to mind. This change isn't as bad - nothing will
actually _break_ when you upgrade, and apps will still run, but migrate
will instead fall back to non-migration mode (which won't destroy any
tables, but will fail to apply any table alterations).

Also, what are the applications in particular that this will be a problem
for? I'm curious to know what Django + South things Debian is shipping
these days.

Andrew


On Thu, Jul 24, 2014 at 1:27 PM, Raphael Hertzog  wrote:

> [ Please keep me in CC ]
>
> Hello,
>
> I'm one of the python-django Debian package maintainers and I have been
> working on preparing the field for Django 1.7... and we have one problem
> that we don't know how to handle.
>
> Consider that Debian contains Django but also Django applications using
> South. When our users will upgrade from Debian 7 to Debian 8
> they will upgrade at the same time Django itself and the Django
> applications.
>
> The new versions of the Django applications are likely to have unapplied
> schema migrations managed by South but the system will have Django 1.7
> and we have no means to let the users apply those schema changes.
>
> I see two ways to go forward:
> - either we find a way to apply South migrations with Django 1.7
> - or we enhance Django migrations to be able to tag some point
>   in the Django migrations as equivalent to some other point in the
>   South migrations, that way we can recreate the supposedly-unapplied
>   South migrations with Django 1.7 and mark those as unneeded if all
>   South migrations were already applied
>
> How can we solve this problem?
>
> Thank you for your help!
> --
> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer
>
> Discover the Debian Administrator's Handbook:
> → http://debian-handbook.info/get/
>

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

Re: Problem migrating from South to Django migrations for Linux distributions

[Michael Manfre]

On Thu, Jul 24, 2014 at 4:44 PM, Joseph Curtin <4...@jbcurtin.io> wrote:
>
> My question now would be, can django migrations and south migrations
> co-exist and can I turn off django migrations?
>
No, migrations is a required feature of Django and cannot be turned off.
The best you could do is generate the SQL from the migrations and manually
apply to the database.

Regards,
Michael Manfre

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

Re: Problem migrating from South to Django migrations for Linux distributions

[Joseph Curtin]

Normally, in development with south. If the migrations get to the point
were they're out of sync. The lead Dev removed the conflicting migrations
and runs the schema migration command.

As for the django 1.7 flow of migrations, I cannot comment on it, but I
would go into this problem with the assumption: I should be able to create
an initial migration and go from there.

One complication I see with this, is that only the django runtime knows
about south which makes it near impossible to detect this in your
packaging.

My question now would be, can django migrations and south migrations
co-exist and can I turn off django migrations?

Cheers,
-Joseph Curtin
On Jul 24, 2014 1:27 PM, "Raphael Hertzog"  wrote:

> [ Please keep me in CC ]
>
> Hello,
>
> I'm one of the python-django Debian package maintainers and I have been
> working on preparing the field for Django 1.7... and we have one problem
> that we don't know how to handle.
>
> Consider that Debian contains Django but also Django applications using
> South. When our users will upgrade from Debian 7 to Debian 8
> they will upgrade at the same time Django itself and the Django
> applications.
>
> The new versions of the Django applications are likely to have unapplied
> schema migrations managed by South but the system will have Django 1.7
> and we have no means to let the users apply those schema changes.
>
> I see two ways to go forward:
> - either we find a way to apply South migrations with Django 1.7
> - or we enhance Django migrations to be able to tag some point
>   in the Django migrations as equivalent to some other point in the
>   South migrations, that way we can recreate the supposedly-unapplied
>   South migrations with Django 1.7 and mark those as unneeded if all
>   South migrations were already applied
>
> How can we solve this problem?
>
> Thank you for your help!
> --
> Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer
>
> Discover the Debian Administrator's Handbook:
> → http://debian-handbook.info/get/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20140724202733.GA8255%40x230-buxy.home.ouaza.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Problem in doing Calcultion in django Application

[Daniele Procida]

On Wed, Jun 18, 2014, Muskan arora  wrote:

>I have a problem in calculating Sum.
> my models.py is as follows :-

You'll get answers to your questions on the django-users email list, 
 - the web interface is 
. 

The list you've posted to is django-developers, an email list is for the 
discussion of the development of Django itself.

You might also find helpful the #django IRC channel on irc.freenode.net.

I hope that helps,

Daniele

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

Re: problem with testing for DeprecationWarning

[Aymeric Augustin]

On 1 mars 2014, at 10:51, Erik Romijn  wrote:

> Curiously, when I run this test independently, or when I run utils_tests 
> independently, this test succeeds. Perhaps there is some interaction with 
> other tests in the suite?

If that's the problem, ./runtests.py --bisect utils_tests should tell you which 
test interacts badly with your changes.

I hope this helps,

-- 
Aymeric.




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0E665766-0C92-4AC9-9109-4E1FA1B09C88%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with number format when not using L10N

[Yonel Ceruto González]

In conclusion one could say that if USE_L10N is not True then no thousands 
separator is displayed, of course, only thru the configuration of django.

El viernes, 20 de diciembre de 2013 08:15:58 UTC-5, Yonel Ceruto González 
escribió:
>
> Ok no problem,
>
> Although the documentation may be inconsistent, I think the comment 
> https://code.djangoproject.com/ticket/21544 # comment: 8, discloses a 
> particular 
> case where I customize the THOUSAND_SEPARATOR with USE_L10N = False. This is 
> the source of my problem, because he expects to see the thousands 
> separator to the display the numbers.
>
> El jueves, 19 de diciembre de 2013 16:19:42 UTC-5, Shai Berger escribió:
>>
>> Hi, 
>>
>> On Thursday 19 December 2013 05:25:11 Yonel Ceruto González wrote: 
>> > Forgive me if at some point was arrogant, it was not my intention to 
>> impose 
>> > my judgment or criticize, for me, the best framework that exists. Maybe 
>> I 
>> > was not regarded with good intentions and therefore I believe the 
>> answers 
>> > were focused to dodge my proposal.Most likely I knew not express well, 
>> beg 
>> > a thousand pardons. 
>>
>> As the person who closed the ticket, your mail here indicates that I may 
>> have 
>> been too harsh, and I apologize for that. I would like to assure you that 
>> your 
>> intentions appear good, and your proposal was rejected purely on 
>> technical 
>> reasons, mostly according to the documentation of USE_THOUSAND_SEPARATOR 
>> and 
>> USE_L10N. 
>>
>> However, having looked again, I now think that you do have a case -- 
>> while for 
>> the settings you pointed to, the documentation strongly implies the 
>> current 
>> behavior, the documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR 
>> does 
>> support your interpretation (and in your first message you mentioned 
>> having set 
>> NUMBER_GROUPING=3). For both these settings, the documentation says: 
>>
>> Note that if USE_L10N is set to True, then the locale-dictated 
>> format has 
>> higher precedence and will be applied instead. 
>>
>> So -- to me, it looks like the documentation is not entirely consistent, 
>> and 
>> should be clarified; and while changing the behavior would be 
>> problematic, 
>> changing it to match (some) documentation should be a possibility. 
>>
>> I'm waiting for other opinions -- in particular, anyone involved with the 
>> introduction of these settings, who can explain the original intentions 
>> -- to 
>> decide if we should reopen the ticket[1] as is or change it to a 
>> documentation 
>> ticket. 
>>
>> Shai. 
>>
>> [1] https://code.djangoproject.com/ticket/21544 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a1cfc902-9284-4c68-9c70-35f9516c6e48%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with number format when not using L10N

[Yonel Ceruto González]

 Ok no problem,

Although the documentation may be inconsistent, I think the comment 
https://code.djangoproject.com/ticket/21544 # comment: 8, discloses a 
particular 
case where I customize the THOUSAND_SEPARATOR with USE_L10N = False. This is 
the source of my problem, because he expects to see the thousands separator to 
the display the numbers.

El jueves, 19 de diciembre de 2013 16:19:42 UTC-5, Shai Berger escribió:
>
> Hi, 
>
> On Thursday 19 December 2013 05:25:11 Yonel Ceruto González wrote: 
> > Forgive me if at some point was arrogant, it was not my intention to 
> impose 
> > my judgment or criticize, for me, the best framework that exists. Maybe 
> I 
> > was not regarded with good intentions and therefore I believe the 
> answers 
> > were focused to dodge my proposal.Most likely I knew not express well, 
> beg 
> > a thousand pardons. 
>
> As the person who closed the ticket, your mail here indicates that I may 
> have 
> been too harsh, and I apologize for that. I would like to assure you that 
> your 
> intentions appear good, and your proposal was rejected purely on technical 
> reasons, mostly according to the documentation of USE_THOUSAND_SEPARATOR 
> and 
> USE_L10N. 
>
> However, having looked again, I now think that you do have a case -- while 
> for 
> the settings you pointed to, the documentation strongly implies the 
> current 
> behavior, the documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR 
> does 
> support your interpretation (and in your first message you mentioned 
> having set 
> NUMBER_GROUPING=3). For both these settings, the documentation says: 
>
> Note that if USE_L10N is set to True, then the locale-dictated 
> format has 
> higher precedence and will be applied instead. 
>
> So -- to me, it looks like the documentation is not entirely consistent, 
> and 
> should be clarified; and while changing the behavior would be problematic, 
> changing it to match (some) documentation should be a possibility. 
>
> I'm waiting for other opinions -- in particular, anyone involved with the 
> introduction of these settings, who can explain the original intentions -- 
> to 
> decide if we should reopen the ticket[1] as is or change it to a 
> documentation 
> ticket. 
>
> Shai. 
>
> [1] https://code.djangoproject.com/ticket/21544 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5390f70e-f86f-48d3-8bf2-90e30d7f9c39%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with number format when not using L10N

[Curtis Maloney]

I recall helping someone on #django with something similar to this, where
the documentation, logical expectations and actual code went in rather
different directions.

There was a condition where despite the setting being observed at one
layer, a lower layer then went and ignored it anyway... will have to dig it
up again...

--
Curtis


On 20 December 2013 08:19, Shai Berger  wrote:

> Hi,
>
> On Thursday 19 December 2013 05:25:11 Yonel Ceruto González wrote:
> > Forgive me if at some point was arrogant, it was not my intention to
> impose
> > my judgment or criticize, for me, the best framework that exists. Maybe I
> > was not regarded with good intentions and therefore I believe the answers
> > were focused to dodge my proposal.Most likely I knew not express well,
> beg
> > a thousand pardons.
>
> As the person who closed the ticket, your mail here indicates that I may
> have
> been too harsh, and I apologize for that. I would like to assure you that
> your
> intentions appear good, and your proposal was rejected purely on technical
> reasons, mostly according to the documentation of USE_THOUSAND_SEPARATOR
> and
> USE_L10N.
>
> However, having looked again, I now think that you do have a case -- while
> for
> the settings you pointed to, the documentation strongly implies the current
> behavior, the documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR does
> support your interpretation (and in your first message you mentioned
> having set
> NUMBER_GROUPING=3). For both these settings, the documentation says:
>
> Note that if USE_L10N is set to True, then the locale-dictated
> format has
> higher precedence and will be applied instead.
>
> So -- to me, it looks like the documentation is not entirely consistent,
> and
> should be clarified; and while changing the behavior would be problematic,
> changing it to match (some) documentation should be a possibility.
>
> I'm waiting for other opinions -- in particular, anyone involved with the
> introduction of these settings, who can explain the original intentions --
> to
> decide if we should reopen the ticket[1] as is or change it to a
> documentation
> ticket.
>
> Shai.
>
> [1] https://code.djangoproject.com/ticket/21544
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1516598.QbdADRIKfy%40deblack
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

Re: Problem with number format when not using L10N

[Shai Berger]

Hi,

On Thursday 19 December 2013 05:25:11 Yonel Ceruto González wrote:
> Forgive me if at some point was arrogant, it was not my intention to impose
> my judgment or criticize, for me, the best framework that exists. Maybe I
> was not regarded with good intentions and therefore I believe the answers
> were focused to dodge my proposal.Most likely I knew not express well, beg
> a thousand pardons.

As the person who closed the ticket, your mail here indicates that I may have 
been too harsh, and I apologize for that. I would like to assure you that your 
intentions appear good, and your proposal was rejected purely on technical 
reasons, mostly according to the documentation of USE_THOUSAND_SEPARATOR and 
USE_L10N.

However, having looked again, I now think that you do have a case -- while for 
the settings you pointed to, the documentation strongly implies the current 
behavior, the documentation for NUMBER_GROUPING and THOUSAND_SEPARATOR does 
support your interpretation (and in your first message you mentioned having set 
NUMBER_GROUPING=3). For both these settings, the documentation says:

Note that if USE_L10N is set to True, then the locale-dictated format 
has
higher precedence and will be applied instead.

So -- to me, it looks like the documentation is not entirely consistent, and 
should be clarified; and while changing the behavior would be problematic, 
changing it to match (some) documentation should be a possibility.

I'm waiting for other opinions -- in particular, anyone involved with the 
introduction of these settings, who can explain the original intentions -- to 
decide if we should reopen the ticket[1] as is or change it to a documentation 
ticket.

Shai.

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

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

Re: Problem with number format when not using L10N

[Yonel Ceruto González]

Forgive me if at some point was arrogant, it was not my intention to impose 
my judgment or criticize, for me, the best framework that exists. Maybe I 
was not regarded with good intentions and therefore I believe the answers 
were focused to dodge my proposal.Most likely I knew not express well, beg 
a thousand pardons.

The truth is that my problem is not yet solved and the ticket was closed. 
Later I will address the problem and my suggestion otherwise.

For now, thank you,

Best Regards

El martes, 3 de diciembre de 2013 11:37:28 UTC-5, Claude Paroz escribió:
>
> This is the topic of https://code.djangoproject.com/ticket/21544 where 
> you can read my position.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7e2d0ab4-87b9-4f2f-b0fd-6ce734222c49%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with number format when not using L10N

[Yonel Ceruto González]

It is understood that if I have enabled the thousands separator 
USE_THOUSAND_SEPARATOR = True and NUMBER_GROUPING > 0 to display all 
numbers with the pattern:
 
#THOUSAND_SEPARATOR###DECIMAL_SEPARATOR##
 
If is enabled or not USE_L10N only determines the "values" of 
DECIMAL_SEPARATOR and THOUSAND_SEPARATOR according to the current locate 
set to LANGUAGE_CODE, but if USE_L10N = False then is display the default 
values.
 
Why USE_L10N determining use of thousands separator?
 
https://docs.djangoproject.com/en/dev/ref/settings/#use-l10n
Here not speak of this variable determines the use of the thousands 
separator.
 Please clarify, thanks

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

Re: Problem with number format when not using L10N

[Claude Paroz]

This is the topic of https://code.djangoproject.com/ticket/21544 where you 
can read my position.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55aed0dd-dcf4-4826-aba9-6ee2f5bac17d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with number format when not using L10N

[Yonel Ceruto González]

I think the configuration of the variable USE_L10N aims at in this case, 
determine the format of number and not condition the use of the grouping of 
thousands.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1d99dbfd-f6c2-4756-93ad-80d2f672b23c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with number format when not using L10N

[Yonel Ceruto González]

 Rectify the frontline:

I want to use the grouping of thousands in my numeric formats, for which I 
use the "floatformat" filter.


El martes, 3 de diciembre de 2013 08:13:21 UTC-5, Yonel Ceruto González 
escribió:
>
> Deseo usar la agrupación de millares en mis formatos numéricos, for which 
> I use the "floatformat" filter.
>  
> My configuration in "settings.py" is:
> USE_L10N = False
> USE_THOUSAND_SEPARATOR = True
> NUMBER_GROUPING = 3
>  
> Showing my numbers without the grouping of thousands.
>
> When I check in depth why I realize that the grouping of thousands is 
> subject to the value of the Variable settings.USE_L10N:
>
> django / utils / numberformat.py:
>
> def format (...):
> ...
> use_grouping = settings.USE_L10N and settings.USE_THOUSAND_SEPARATOR
> Think it would be correct to eliminate the constraint that prohibits the 
> display grouping of thousands, if not L10N used?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1bc96ccb-7032-4bf5-8914-6cef19606155%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with creating a one-to-one instance

[Carsten Fuchs]

Hi Jacob, hi Florian,

Am 19.04.2013 18:18, schrieb Jacob Kaplan-Moss:

Unfortunately, we can't help you. Django-developers isn't a "second
level" for django-users; they're completely different lists. The
purpose of this list is to discuss the development of Django itself,
not answer user questions.


I'm very sorry.
Thanks for pointing me to the right places.

Best regards,
Carsten

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with creating a one-to-one instance

[Florian Apolloner]

Hi Carsten,

first of all, django-dev is not a second level support list, so for the 
future please refrain from posting here just because you get no answer on 
the user list. As for the issue on hand, try accessing ma.vbp_id after you 
assign the instance, this should give you some clues.

Cheers,
Florian

P.S.: Also if you want your app to be reusable code in English  and not in 
German ;)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with creating a one-to-one instance

[Jacob Kaplan-Moss]

Hi Carsten -

On Fri, Apr 19, 2013 at 10:43 AM, Carsten Fuchs  wrote:
> sorry to bother you here, but I posted to django-users first
> (https://groups.google.com/d/msg/django-users/WHnCxHkEVjE/9puR4youvwsJ) and
> there was no reply, so please let me re-try here:

Unfortunately, we can't help you. Django-developers isn't a "second
level" for django-users; they're completely different lists. The
purpose of this list is to discuss the development of Django itself,
not answer user questions.

You might try waiting a few more days -- you only asked your question
on -users a couple days ago -- and trying again. Or you may want to
try IRC (#django on Freenode) or StackOverflow.

Sorry we can't help,

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: PROBLEM WITH MY CUSTOMIZED save() method

[Karen Tracey]

Please ask questions about using Django on django-users. This list is for
the discussion of developing Django itself.

Thanks,
Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with Custom Manage.py command and Crontab

[Karen Tracey]

Please ask questions about using Django on django-users. The topic of this
list is the development of Django itself.

Thanks,
Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Problem with writing custom field to work with inherit models

[Russell Keith-Magee]

On Thu, Apr 7, 2011 at 4:21 AM, Sebastian Bauer  wrote:
> Hi, could you explain to us why this isn't working?
> https://github.com/humanfromearth/django-stdimage/issues/11

Not in this forum. You've posted to django-developers, which is a
forum for discussing the development of django itself.

It looks like you're trying to use django-developers as "second tier"
tech support -- allow me to assure you that it isn't. I'm sorry if
nobody has been able to answer your question on django-users, but
posting to django-devlopers isn't the way to 'escalate' your question
when you don't get an answer elsewhere.

Yours,
Russ Magee %-)

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

Re: Problem with DECIMAL_SEPARATOR

[Łukasz Rekucki]

On 10 March 2011 21:49, Siara  wrote:
> Hi
> I'm writing application which return json with data for another app.
> I'm from Poland so I set LANGUAGE_CODE = 'pl', the problem is that we
> are using coma instead of dot in float numbers, and setting language
> to polish changing dot for coma in jsons, but i need dot.
> I tried DECIMAL_SEPARATOR = '.'  but its doesnt work, it looks like
> LANGUAGE_CODE is overwriting DECIMAL_SEPARATOR settings.
> So any ideas how to keep polish internatiolization with
> DECIMAL_SEPARATOR as dot intead coma ?
>

This looks like a usage question to me, so please direct your question
to django-users. You should include the code you're using to serialize
your data (and the data you're serializing).

-- 
Łukasz Rekucki

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

Re: Problem due to contenttype cache

[Rahul]

Hi carl,
 I have file a ticket for this.
For details please find it on http://code.djangoproject.com/ticket/15568

Thanks,
Rahul Priyadarshi

On Mar 5, 9:27 am, Carl Meyer  wrote:
> On Mar 4, 5:55 am, Rahul  wrote:
>
>
>
> > When i ran test cases of multiple_databases model of regressiontests
> > then "test_generic_key_deletion" test case gave Error at the point
> > where it was trying to create Review object using "other" db,
> > but when i ran "test_generic_key_deletion" test case only then it
> > passed perfectly.
>
> > When i narrowed the problem and run this test case with
> > "test_generic_key_cross_database_protection" then even it gives Error
> > at same line.
>
> > In my investigation i found that in
> > "test_generic_key_cross_database_protection" test case, one Reiview
> > object is getting created and because there exist FK relationship with
> > ContentType, content type record for this is getting populated in DB
> > and content type lookup are cached. At the end of this test case,
> > content type record gets cleared by rollback, but content type lookup
> > still remain in cache, so that when inside "test_generic_key_deletion"
> > it tries to create Review object it gets content type from the cache
> > and does not have  to go to  DB. Next when it tries to populate review
> > table, Integrity error is raised as it has not made entry to content
> > type table.
>
> > I also tested it with InnoDB and getting same error here as well.
>
> > Could you please let me know if you wants to let it gives error for
> > this test case for InnoDB or I am running this wrong way.
>
> Any failed test on a supported backend (which includes InnoDB) is a
> bug. Please file a ticket, including this information and the full
> settings with which you're running the tests. Thanks!
>
> Carl

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

Re: Problem due to contenttype cache

[Carl Meyer]

On Mar 4, 5:55 am, Rahul  wrote:
> When i ran test cases of multiple_databases model of regressiontests
> then "test_generic_key_deletion" test case gave Error at the point
> where it was trying to create Review object using "other" db,
> but when i ran "test_generic_key_deletion" test case only then it
> passed perfectly.
>
> When i narrowed the problem and run this test case with
> "test_generic_key_cross_database_protection" then even it gives Error
> at same line.
>
> In my investigation i found that in
> "test_generic_key_cross_database_protection" test case, one Reiview
> object is getting created and because there exist FK relationship with
> ContentType, content type record for this is getting populated in DB
> and content type lookup are cached. At the end of this test case,
> content type record gets cleared by rollback, but content type lookup
> still remain in cache, so that when inside "test_generic_key_deletion"
> it tries to create Review object it gets content type from the cache
> and does not have  to go to  DB. Next when it tries to populate review
> table, Integrity error is raised as it has not made entry to content
> type table.
>
> I also tested it with InnoDB and getting same error here as well.
>
> Could you please let me know if you wants to let it gives error for
> this test case for InnoDB or I am running this wrong way.

Any failed test on a supported backend (which includes InnoDB) is a
bug. Please file a ticket, including this information and the full
settings with which you're running the tests. Thanks!

Carl

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

Re: Problem with ``Model.objects.create``

[Valts]

On Jan 4, 8:46 pm, Waylan Limberg  wrote:
> That being said, it does strike me as being a little odd that there is
> no way to validate your data when using create() or get_or_create().
> In fact, the docs [1] describe both those methods as shortcuts. But if
> you're writing an app that always needs to validate your data, then
> you will never use those shortcuts which makes them rather useless. Of
> course, they existed long before (the current) model validation
> mechanism did, so I wonder if it would be reasonable to propose that
> they (at least optionally) be updated to run validation before saving.

Just my $0.02: I think that such feature would be useful when using
get_or_create() when I don't want the object to be saved into the
database if it does not validate. There could be added another special
keyword argument "full_clean", "validate" or similar to
get_or_create(). If the proposed idea gets the green light I am
willing to create the ticket and the necessary patches.

In case of create() IMO there is no need for any changes as create()
is really simple and I'd rather make create_clean() shortcut in my own
project without polluting keyword arguments with special cases.

Best regards,
Valts.

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

Re: Problem with ``Model.objects.create``

[Yo-Yo Ma]

On Jan 4, 4:43 pm, Jacob Kaplan-Moss  wrote:
> On Tue, Jan 4, 2011 at 3:37 PM, Yo-Yo Ma  wrote:
> > What's with all the hostility here? I've heard about this from others.
>
> Let's just stop this, right now. There's no hostility in Marty's tone
> -- if you're reading that, then take the night off and come back to
> django-dev tomorrow.
>
> This discussion is starting to go down the path of many other ones
> you've been involved in in the past, and you need to stop right now.
>
> I've twice warned you privately, and now I'll warn you publicly: ad
> homonym attacks and hostile, personal notes like yours aren't
> acceptable here. Stop now.
>
> Jacob

> But spinning around about how...

Are you saying, that's not hostile? And, which ad hominem attack/s are
you referring to? I'm being serious. If I'm going to the gauntlets,
can you at least tell me how you came to the conclusion that I used ad
hominem?

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

Re: Problem with ``Model.objects.create``

[Jacob Kaplan-Moss]

On Tue, Jan 4, 2011 at 3:37 PM, Yo-Yo Ma  wrote:
> What's with all the hostility here? I've heard about this from others.

Let's just stop this, right now. There's no hostility in Marty's tone
-- if you're reading that, then take the night off and come back to
django-dev tomorrow.

This discussion is starting to go down the path of many other ones
you've been involved in in the past, and you need to stop right now.

I've twice warned you privately, and now I'll warn you publicly: ad
homonym attacks and hostile, personal notes like yours aren't
acceptable here. Stop now.

Jacob

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

Re: Problem with ``Model.objects.create``

[Yo-Yo Ma]

Waylan:
> Therefore, don't use Person.objects.create()

Marty:
> Developer mistakes can ruin your data. Full stop.

> Unfortunately, this is one of the many issues where "X doesn't work
> the way I think it should" gets confused with "X doesn't work the way
> it should" or even "X doesn't work." If you have a constructive
> argument for how you think it should work that can be implemented in a
> way that doesn't break compatibility with other people's code, feel
> free to propose that and discuss it. But spinning around about how
> "wrong" the behavior is currently doesn't help anybody.

What's with all the hostility here? I've heard about this from others.

> ...constructive argument...

Your thesis about the semantics of suggesting features is more
constructive?

Suggesting an idea here gets you just about the same as joining an
elementary school hide-and-go-seek game and trying to change the rules.

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

Re: Problem with ``Model.objects.create``

[Marty Alchin]

On Tue, Jan 4, 2011 at 3:10 PM, Yo-Yo Ma  wrote:
> Simple question (A or B): Would you rather A) have a
> SomeDjangoException come up where you don't expect it and a visitor
> see a 500 page, or B) have your data ruined by a developer mistake?

Developer mistakes can ruin your data. Full stop.

That has nothing to do with Django, its ORM or the create() method
being discussed here. A developer mistake *always* has the potential
to severely cripple a website or much, much worse. Sure, we could
argue all day about whether this one particular method could add some
extra protections, but please don't try to kid yourself (or any of us)
into thinking that "fixing" create() will somehow make websites safe
from mistakes.

The fact of the matter is this: create() has a particular behavior,
and that behavior is documented. Sure, the documentation *could* be
more clear, but if we wanted to call out every potentially disastrous
mistake in bold with flashing lights and sirens, the vast majority of
the documentation would look like that, and nobody would ever read any
of it. Worse yet, it still couldn't possibly cover the full range of
possible mistakes, so anybody who did bother to read it would still be
wide open to a whole range of problems. It's our responsibility as
developers to understand the way our tools work and use them
accordingly. No amount of framework design will ever substitute for a
well-informed developer using it.

> Your data is ruined when your code's logic (the view) can no
> longer assume that the data's interface (the ORM model) is still valid.

That's just it: the data's interface (the ORM model) *is* still valid.
It's as valid as it's documented to be. An ORM is a device that
communicates between a database and an object. As long as there's
enough information for those two sides to talk to each other, a
conversation can take place. Anything that needs to happen beyond that
is, as you mentioned, your code's logic. You can encapsulate some of
that logic in a full_clean() method and call it separately to make
sure your objects are valid according your code's logic, but all the
ORM itself cares about is whether objects are valid according to the
database requirements.

Unfortunately, this is one of the many issues where "X doesn't work
the way I think it should" gets confused with "X doesn't work the way
it should" or even "X doesn't work." If you have a constructive
argument for how you think it should work that can be implemented in a
way that doesn't break compatibility with other people's code, feel
free to propose that and discuss it. But spinning around about how
"wrong" the behavior is currently doesn't help anybody.

-Marty

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

Re: Problem with ``Model.objects.create``

[Yo-Yo Ma]

>> ...*before* writing to the db. Therefore, don't use 
>> Person.objects.create()
>> ...it does strike me as being a little odd that there is no way to validate 
>> your data...

Let me get this straight:

I just shouldn't "use Person.objects.create()", if I ever want to
to take advantage of any protection that the ORM provides since there
is "no way to validate" my data? Then, remove ``create()`` from the
ORM. It's not part of the ORM, if that's the case. It's a unintended
booby trap for developers who to accidentally ruin their data because
of naive data input assumptions or faulty validation logic somewhere
along the way, as I did (fortunately during development). It still
provides SQL injection protection (ie, not just "writing to the db"),
so why not basic model integrity protection?

Simple question (A or B): Would you rather A) have a
SomeDjangoException come up where you don't expect it and a visitor
see a 500 page, or B) have your data ruined by a developer mistake?
That's not a loaded question. That's the exact issue I'm speaking
about. Your data is ruined when your code's logic (the view) can no
longer assume that the data's interface (the ORM model) is still valid.

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

Re: Problem with ``Model.objects.create``

[Waylan Limberg]

On Tue, Jan 4, 2011 at 10:54 AM, Yo-Yo Ma  wrote:
[snip]
> The difference in Django is that instantiation doesn't represent
> "creation". Saving to the database does, and since the ORM is an
> abstraction of the database, you don't care that the DB is ok with an
> empty VARCHAR value. You only care about your model's required value.
> I'm suggesting this:
>
> class Person(Model):
>    name = CharField(max_length=50)
>
>
 Person()  # Should work fine (assign attributes later, etc)
 Person.objects.create()
> ... Should raise some kind of exception before allowing your model's
> "INTEGRITY" to be violated.
>

No it shouldn't as no data validation has been run. Remember, like
save(), create() does not run validation on the instance before
writing to the db.  As Russ pointed out, the actual data written to
the db is valid as far as the db is concerned. Therefore, you get no
errors. If you want to ensure the data is valid (as defined in your
python code - not per the db) then you need to validate it in python
*before* writing to the db. Therefore, don't use
Person.objects.create()

That being said, it does strike me as being a little odd that there is
no way to validate your data when using create() or get_or_create().
In fact, the docs [1] describe both those methods as shortcuts. But if
you're writing an app that always needs to validate your data, then
you will never use those shortcuts which makes them rather useless. Of
course, they existed long before (the current) model validation
mechanism did, so I wonder if it would be reasonable to propose that
they (at least optionally) be updated to run validation before saving.

Or perhaps a warning in the docs that create() and get_or_create() do
not run validation before writing to the db may be appropriate.

[1]: http://docs.djangoproject.com/en/dev/ref/models/querysets/#create

-- 

\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

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

Re: Problem with ``Model.objects.create``

[Yo-Yo Ma]

> duplicate key, etc." [1] Since the creation of a model instance
> doesn't affect the database, it should definitely not raise an

This isn't correct. Model instantiation doesn't affect the database.
Model creation (ie, the use of ``Model.create()`` does. I'm not
arguing that instantiation should raise an exception. I'm arguing that
saving it to the database should (ie, using ``create()``, or
explicitly ``save()``).

Put simply: In general, you cannot "create" a Foo that isn't exactly a
Foo. If it isn't exactly a Foo, it isn't a Foo at all. This is
undeniable logic, no?

Python Example:

class MyClass(object):
def __init__(self, name):
self.name = name

>>> instance = MyClass()
...
TypeError: __init__() takes exactly 2 arguments (1 given)


I don't have to do this to find out I screwed up:

>>> instance = MyClass()
>>> instance.is_messed_up()
TypeError: __init__() takes exactly 2 arguments (1 given)


The difference in Django is that instantiation doesn't represent
"creation". Saving to the database does, and since the ORM is an
abstraction of the database, you don't care that the DB is ok with an
empty VARCHAR value. You only care about your model's required value.
I'm suggesting this:

class Person(Model):
name = CharField(max_length=50)


>>> Person()  # Should work fine (assign attributes later, etc)
>>> Person.objects.create()
... Should raise some kind of exception before allowing your model's
"INTEGRITY" to be violated.

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

Re: Problem with ``Model.objects.create``

[Stephen Burrows]

Just to clarify, an IntegrityError is raised if "the relational
integrity of the database is affected, e.g. a foreign key check fails,
duplicate key, etc." [1] Since the creation of a model instance
doesn't affect the database, it should definitely not raise an
IntegrityError. Additionally, blank=True doesn't have anything to do
with database structure: it's purely for validation django-side. The
database doesn't care whether something is blank or not, so saving an
object (or using Foo.objects.create()) with a blank value in a
required field will also not raise an IntegrityError.
That being said, if a model has a blank value in a required field, a
ValidationError should be raised by the full_clean method, and if
that's not happening, it's a bug. If you're creating a model instance
and want to run validation before you it's saved to the database,
you'll want to do the following:

>>> obj = Foo(xyz='Hello')
>>> obj.full_clean()
(Here a ValidationError will be raised. In actual code you would want
to use try/except.)
>>> obj.spam = "w/e"
>>> obj.full_clean() # since the model instance will now validate, this won't 
>>> raise an exception.
>>> obj.save()

If the ValidationError is being raised correctly, then this might be a
topic more for django-users than django-developers.

Best,
Stephen

[1] http://code.djangoproject.com/wiki/IntegrityError

On Jan 3, 12:10 am, Yo-Yo Ma  wrote:
> Oh, sorry for the confusion, and thanks for the explaination. I
> thought that Django raised an IntegrityError in this case, and when it
> didn't happen I figured it was a bug.
>
> I will make a recommendation (observation). To provide a blank value a
> a model and have it validate with full_clean, you have to specify
> blank=True. I would suggest that to maintain integrity between your
> applications logic and the database, Django should raise an
> IntegrityError, if blank=False.
>
> On Jan 2, 6:53 pm, Russell Keith-Magee 
> wrote:
>
> > On Mon, Jan 3, 2011 at 7:46 AM, Yo-Yo Ma  wrote:
> > > I apologize ahead of time, if this bug is rather a user error.
>
> > > If you have a model:
>
> > > class Foo(Model):
> > >    spam= CharField(max_length=30)
> > >    xyz= CharField(max_length=30)
>
> > >    def __unicode__(self):
> > >        return self.xyz
>
> > > and you use it in the shell like this:
>
> >  Foo.objects.create(xyz="Hello")
> > > 
>
> > > No IntegrityError was raised, even though ``spam`` is a required field.
>
> > Yes, 'spam' is a required field. And if you investigate a little
> > closer, you'll see that it has a value -- the empty string.
>
> > You'll note that the following also works, and is entirely consistent
> > with get_or_create():
>
> > >>> obj = Foo(xyz='Hello')
> > >>> obj.save()
>
> > For reasons of historical significance, the default value for all
> > fields (CharField or otherwise) is "", unless:
> >  * a default is provided by the user, or
> >  * You've overridden get_default, or
> >  * You're using Oracle (which has it's own special difficulties with "" vs 
> > None)
>
> > Yours,
> > Russ Magee %-)

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

Re: Problem with validating ModelForm

[Shawn Milochik]

Please post your question to the django-users mailing list. This list is for 
developers of Django itself.


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

Re: Problem with ``Model.objects.create``

[Yo-Yo Ma]

Oh, sorry for the confusion, and thanks for the explaination. I
thought that Django raised an IntegrityError in this case, and when it
didn't happen I figured it was a bug.

I will make a recommendation (observation). To provide a blank value a
a model and have it validate with full_clean, you have to specify
blank=True. I would suggest that to maintain integrity between your
applications logic and the database, Django should raise an
IntegrityError, if blank=False.


On Jan 2, 6:53 pm, Russell Keith-Magee 
wrote:
> On Mon, Jan 3, 2011 at 7:46 AM, Yo-Yo Ma  wrote:
> > I apologize ahead of time, if this bug is rather a user error.
>
> > If you have a model:
>
> > class Foo(Model):
> >    spam= CharField(max_length=30)
> >    xyz= CharField(max_length=30)
>
> >    def __unicode__(self):
> >        return self.xyz
>
> > and you use it in the shell like this:
>
>  Foo.objects.create(xyz="Hello")
> > 
>
> > No IntegrityError was raised, even though ``spam`` is a required field.
>
> Yes, 'spam' is a required field. And if you investigate a little
> closer, you'll see that it has a value -- the empty string.
>
> You'll note that the following also works, and is entirely consistent
> with get_or_create():
>
> >>> obj = Foo(xyz='Hello')
> >>> obj.save()
>
> For reasons of historical significance, the default value for all
> fields (CharField or otherwise) is "", unless:
>  * a default is provided by the user, or
>  * You've overridden get_default, or
>  * You're using Oracle (which has it's own special difficulties with "" vs 
> None)
>
> Yours,
> Russ Magee %-)

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

Re: Problem with ``Model.objects.create``

[Russell Keith-Magee]

On Mon, Jan 3, 2011 at 7:46 AM, Yo-Yo Ma  wrote:
> I apologize ahead of time, if this bug is rather a user error.
>
> If you have a model:
>
> class Foo(Model):
>    spam= CharField(max_length=30)
>    xyz= CharField(max_length=30)
>
>    def __unicode__(self):
>        return self.xyz
>
> and you use it in the shell like this:
>
 Foo.objects.create(xyz="Hello")
> 

>
> No IntegrityError was raised, even though ``spam`` is a required field.

Yes, 'spam' is a required field. And if you investigate a little
closer, you'll see that it has a value -- the empty string.

You'll note that the following also works, and is entirely consistent
with get_or_create():

>>> obj = Foo(xyz='Hello')
>>> obj.save()

For reasons of historical significance, the default value for all
fields (CharField or otherwise) is "", unless:
 * a default is provided by the user, or
 * You've overridden get_default, or
 * You're using Oracle (which has it's own special difficulties with "" vs None)

Yours,
Russ Magee %-)

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

Re: Problem with ``Model.objects.create``

[nasp]

This is a user error, validation checks are performed on 
model.clean()
.

This mailing list is for development purpose, please use 
django-usersmailing 
list or #django 
irc .  

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

Re: problem to run server

[NavaTux]

python manage.py syncdb also shows this error only.import django in python 
shell works; i am using postgres every thing is fine it seems in postgres.

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

Re: problem to run server

[Łukasz Rekucki]

Hi,

This list for developing Django itself, not developing with Django.
Please move this discussion to django-users. Thanks.

---
Łukasz Rekucki



On 14 December 2010 13:55, Tonton  wrote:
> i presume that in your file you have write
>
> from django*... import  .  is there the trouble ..
> may be in your settings with database
>
> does your manage.py syncdb has work ?
>
> On Tue, Dec 14, 2010 at 8:16 AM, NavaTux  wrote:
>>
>> I want to test django application so when i created the project
>> "django-admin.py start project testp" and i created application python
>> manage.py startapp testapp
>>
>> then i added in settings.py (database
>> postgresql_psycopg2,name,username,password) as well as i am running in
>> virtualenv,installed fine of(psycopg2,django 1.1)
>>
>> when i ran a server i got the error
>>
>> " (test)hire...@hirelex-laptop:~/test/testp$ python manage.py
>> runserver
>> Validating models...
>> Unhandled exception in thread started by > 0x9f266bc>
>> Traceback (most recent call last):
>>  File "/usr/local/lib/python2.6/dist-packages/django/core/management/
>> commands/runserver.py", line 48, in inner_run
>>    self.validate(display_num_errors=True)
>>  File "/usr/local/lib/python2.6/dist-packages/django/core/management/
>> base.py", line 249, in validate
>>    num_errors = get_validation_errors(s, app)
>>  File "/usr/local/lib/python2.6/dist-packages/django/core/management/
>> validation.py", line 22, in get_validation_errors
>>    from django.db import models, connection
>>  File "/usr/local/lib/python2.6/dist-packages/django/db/__init__.py",
>> line 77, in 
>>    connection = connections[DEFAULT_DB_ALIAS]
>>  File "/usr/local/lib/python2.6/dist-packages/django/db/utils.py",
>> line 91, in __getitem__
>>    backend = load_backend(db['ENGINE'])
>>  File "/usr/local/lib/python2.6/dist-packages/django/db/utils.py",
>> line 22, in load_backend
>>    module = import_module('.base', 'django.db.backends.%s' %
>> backend_name)
>>  File "/usr/local/lib/python2.6/dist-packages/django/utils/
>> importlib.py", line 35, in import_module
>>    __import__(name)
>> ValueError: Empty module name
>>
>> "
>>
>> May i know the problem ?please suggest me
>>
>> pip freeze
>>
>> " Brlapi==0.5.4
>> CouchDB==0.6
>> Django==1.2.3
>> GnuPGInterface==0.3.2
>> Mako==0.2.5
>> PAM==0.4.2
>> PIL==1.1.7
>> PyOpenGL==3.0.0
>> Pygments==1.2.2
>> Twisted-Core==10.0.0
>> Twisted-Names==10.0.0
>> Twisted-Web==10.0.0
>> adium-theme-ubuntu==0.1
>> apturl==0.4.1ubuntu4
>> command-not-found==0.1
>> configglue==0.2dev
>> cups==1.0
>> distribute==0.6.10
>> django-tagging==0.3.1
>> docutils==0.6
>> egenix-mx-base==3.1.3
>> fstab==1.4
>> gdata.py==1.2.4
>> gnome-app-install==0.4.2ubuntu2
>> hgview==1.1.3
>> httplib2==0.6.0
>> human-theme==0.39
>> jockey==0.5.8
>> launchpadlib==1.6.0
>> lazr.restfulclient==0.9.11
>> lazr.uri==1.0.2
>> louis==1.7.0
>> lxml==2.2.4
>> mercurial==1.4.3
>> nvidia-common==0.0.0
>> oauth==1.0a
>> onboard==0.93.0
>> papyon==0.4.8
>> pexpect==2.3
>> protobuf==2.2.0
>> psycopg2==2.3.1
>> pyOpenSSL==0.10
>> pycrypto==2.0.1
>> pycurl==7.19.0
>> pyinotify==0.8.9
>> pyserial==2.3
>> python-apt==0.7.94.2ubuntu6.2
>> python-debian==0.1.14ubuntu2
>> python-launchpad-bugs==0.3.6
>> pyusb==0.4.2
>> pyxdg==0.18
>> rdflib==2.4.2
>> screen-resolution-extra==0.0.0
>> simplejson==2.0.9
>> smbc==1.0
>> speechd==0.3
>> speechd-config==0.0
>> system-service==0.1.6
>> ubuntu-gdm-themes==0.33
>> ubuntuone-storage-protocol==1.2.0
>> ufw==0.30pre1-0ubuntu2
>> unattended-upgrades==0.1
>> usb-creator==0.2.22
>> vboxapi==1.0
>> virtkey==0.01
>> virtualenv==1.4.5
>> wadllib==1.1.4
>> wsgiref==0.1.2
>> xkit==0.0.0
>> zope.interface==3.5.3
>> (test)hire...@hirelex-laptop:~/test/testp$
>>  "
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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

Re: problem to run server

[Tonton]

i presume that in your file you have write

from django*... import  .  is there the trouble ..
may be in your settings with database

does your manage.py syncdb has work ?

On Tue, Dec 14, 2010 at 8:16 AM, NavaTux  wrote:

> I want to test django application so when i created the project
> "django-admin.py start project testp" and i created application python
> manage.py startapp testapp
>
> then i added in settings.py (database
> postgresql_psycopg2,name,username,password) as well as i am running in
> virtualenv,installed fine of(psycopg2,django 1.1)
>
> when i ran a server i got the error
>
> " (test)hire...@hirelex-laptop:~/test/testp$ python manage.py
> runserver
> Validating models...
> Unhandled exception in thread started by  0x9f266bc>
> Traceback (most recent call last):
>  File "/usr/local/lib/python2.6/dist-packages/django/core/management/
> commands/runserver.py", line 48, in inner_run
>self.validate(display_num_errors=True)
>  File "/usr/local/lib/python2.6/dist-packages/django/core/management/
> base.py", line 249, in validate
>num_errors = get_validation_errors(s, app)
>  File "/usr/local/lib/python2.6/dist-packages/django/core/management/
> validation.py", line 22, in get_validation_errors
>from django.db import models, connection
>  File "/usr/local/lib/python2.6/dist-packages/django/db/__init__.py",
> line 77, in 
>connection = connections[DEFAULT_DB_ALIAS]
>  File "/usr/local/lib/python2.6/dist-packages/django/db/utils.py",
> line 91, in __getitem__
>backend = load_backend(db['ENGINE'])
>  File "/usr/local/lib/python2.6/dist-packages/django/db/utils.py",
> line 22, in load_backend
>module = import_module('.base', 'django.db.backends.%s' %
> backend_name)
>  File "/usr/local/lib/python2.6/dist-packages/django/utils/
> importlib.py", line 35, in import_module
>__import__(name)
> ValueError: Empty module name
>
> "
>
> May i know the problem ?please suggest me
>
> pip freeze
>
> " Brlapi==0.5.4
> CouchDB==0.6
> Django==1.2.3
> GnuPGInterface==0.3.2
> Mako==0.2.5
> PAM==0.4.2
> PIL==1.1.7
> PyOpenGL==3.0.0
> Pygments==1.2.2
> Twisted-Core==10.0.0
> Twisted-Names==10.0.0
> Twisted-Web==10.0.0
> adium-theme-ubuntu==0.1
> apturl==0.4.1ubuntu4
> command-not-found==0.1
> configglue==0.2dev
> cups==1.0
> distribute==0.6.10
> django-tagging==0.3.1
> docutils==0.6
> egenix-mx-base==3.1.3
> fstab==1.4
> gdata.py==1.2.4
> gnome-app-install==0.4.2ubuntu2
> hgview==1.1.3
> httplib2==0.6.0
> human-theme==0.39
> jockey==0.5.8
> launchpadlib==1.6.0
> lazr.restfulclient==0.9.11
> lazr.uri==1.0.2
> louis==1.7.0
> lxml==2.2.4
> mercurial==1.4.3
> nvidia-common==0.0.0
> oauth==1.0a
> onboard==0.93.0
> papyon==0.4.8
> pexpect==2.3
> protobuf==2.2.0
> psycopg2==2.3.1
> pyOpenSSL==0.10
> pycrypto==2.0.1
> pycurl==7.19.0
> pyinotify==0.8.9
> pyserial==2.3
> python-apt==0.7.94.2ubuntu6.2
> python-debian==0.1.14ubuntu2
> python-launchpad-bugs==0.3.6
> pyusb==0.4.2
> pyxdg==0.18
> rdflib==2.4.2
> screen-resolution-extra==0.0.0
> simplejson==2.0.9
> smbc==1.0
> speechd==0.3
> speechd-config==0.0
> system-service==0.1.6
> ubuntu-gdm-themes==0.33
> ubuntuone-storage-protocol==1.2.0
> ufw==0.30pre1-0ubuntu2
> unattended-upgrades==0.1
> usb-creator==0.2.22
> vboxapi==1.0
> virtkey==0.01
> virtualenv==1.4.5
> wadllib==1.1.4
> wsgiref==0.1.2
> xkit==0.0.0
> zope.interface==3.5.3
> (test)hire...@hirelex-laptop:~/test/testp$
>  "
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Problem with randrange in django/middleware/csrf.py

[DanEE]

After all it was a misconfiguration of my system and not a problem of
Python or Django.

Somehow the special files /dev/random and /dev/urandom got screwed up.
I suppose it was the outcome of a bad update of the udev package on my
Archlinux system.
When I recreated the node of /dev/urandom manually the
random.SystemRandom().randrange returned all numbers instantly

Thank you for pointing me to the right direction.
Daniel

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

Re: Problem with randrange in django/middleware/csrf.py

[Ramiro Morales]

On Thu, Jul 8, 2010 at 4:09 PM, DanEE  wrote:
> The problems with randrange also occur when I run it directly from a
> normal python prompt.
>
>[...]
> So it doesn't seem to be a django problem, but it still is very
> annoying.
>
>> If the host has not enough entropy, Django shouldn't fix it, an
>> administrator should.
> Are there any suggestions how I could fix it? I don't even know where
> to start looking...

If you are using Linux, try a:

$ find /

http://burtonini.com/blog/computers/cups-2006-08-14-18-00

Longer term solutions for production servers might involve implementing
a hardware assisted RNG like the Entropy Key already
mentioned or randomsound:

http://packages.debian.org/search?keywords=randomsound

Regards,

-- 
Ramiro Morales  |  http://rmorales.net

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

Re: Problem with randrange in django/middleware/csrf.py

[DanEE]

The problems with randrange also occur when I run it directly from a
normal python prompt.

>>> random.randrange(0, 2<<63)
instantly returns me the random numbers.

whereas
>>> random.SystemRandom().randrange(0, 2<<63)
Takes forever to run. I cancelled the execution after about 10
minutes.

As an interesting side notice:
>>> random.SystemRandom().randrange(0, 2<<51)
works fine and returns instantly with a random number

>>> random.SystemRandom().randrange(0, 2<<52)
however seems to run forever without any result...

So it doesn't seem to be a django problem, but it still is very
annoying.

> If the host has not enough entropy, Django shouldn't fix it, an
> administrator should.
Are there any suggestions how I could fix it? I don't even know where
to start looking...

PS:
>>> random.SystemRandom().randrange(0, 2<<63)
works without any problems on my windows machine and on another hosted
linux server where I have access to.

Daniel

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

Re: Problem with randrange in django/middleware/csrf.py

[stefanw]

> >> By playing around in a python session it seems that the call to the
> >> system randrange with random.SystemRandom().randrange(0,
> >> _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30
> >> minutes) whereas a call to the "normal" randrange with randrange(0,
> >> _MAX_CSRF_KEY) happily returns the desired random number.

This sounds like python is unable to get a secure random number from
the OS.
The OS can run out of entropy, it may even happen faster on shared
systems.

http://www.entropykey.co.uk/ says (and they probably know):
"Applications that require random data, [...] read from this pool. The
problem is that the pool is of fixed size (just 4kB) and as standard
has limited entropy input. If an application tries to read from the
pool, and there is not enough data to satisfy its request, the
application is frozen in limbo until enough entropy has been collected
to fill the pool to the point of being able to satisfy the request,
leading to delays in the delivery of services."

Sounds like what happened to you.

> I'm unclear on why we even allow this code to work with the "default"
> random implementation, which is based on a Messrne Twister, and
> (quoting the Python docs here), "is completely unsuitable for
> cryptographic purposes".  To my understand that's how we're trying to
> use it, and if I'm wrong here I wonder why we give preference to the
> system random at all?

If DEBUG=False, there shouldn't be a fallback to non-secure random
numbers, maybe there shouldn't even be a fallback at all.
If the host has not enough entropy, Django shouldn't fix it, an
administrator should.

Cheers
Stefan

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

Re: Problem with randrange in django/middleware/csrf.py

[Alex Gaynor]

On Thu, Jul 8, 2010 at 8:39 AM, Russell Keith-Magee
 wrote:
> On Thu, Jul 8, 2010 at 3:17 PM, DanEE  wrote:
>> Hello
>>
>> I posted this already in django-user. But because it is rather an
>> internal django/python problem I will repost it here
>>
>> I experienced a strange behaviour with my django application when I
>> wanted to deploy and test on my apache instance on my virtual server.
>> I could successfully deploy my application but when I wanted to access
>> any view the browser just took forever to load and it never showed the
>> view. Accessing any non existing view gave the correct debug error
>> view.
>>
>> After a long debugging session I could locate the problem to be in
>> django/middleware/csrf.py. The call which actually took a very long
>> time was the call to randrange(0, _MAX_CSRF_KEY).
>>
>> By playing around in a python session it seems that the call to the
>> system randrange with random.SystemRandom().randrange(0,
>> _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30
>> minutes) whereas a call to the "normal" randrange with randrange(0,
>> _MAX_CSRF_KEY) happily returns the desired random number.
>> The problem seems to depend on the size of the argument.
>> random.SystemRandom().randrange happily returns the random values if
>> the arguments are significantly lower. (I just deleted some number
>> from the _MAX_CSRF_KEY and then it worked)
>>
>> I had to manully set the line "randrange = random.randrange" instead
>> of the if/else logic which checks for the system random generator to
>> make my app work on my virtual host.
>>
>> Now it seems that is not a django problem per se. But I am wondering
>> what I should to with this kind of error as I had to manually fiddle
>> around in the django-code to be able to successfully host my
>> application.
>
> This is concerning, but I can't reproduce anything like it -- on every
> platform I have available for testing, randrange() returns almost
> instantaneously.
>
> If you call randrange from a normal python prompt, do you see the same
> sort of delays? What about if you call randrange() in a simple Django
> view? (i.e., start a new project with a simple view with no forms, and
> call randrange() in that view?). Do you get similar lockups if you run
> the CSRF tests in the Django test suite?
>
> If you can find the source of this problem, we will be only too happy
> to fix it -- but until we can narrow down the specific set of
> circumstances that causes the problem, there's not much we can do.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

I'm unclear on why we even allow this code to work with the "default"
random implementation, which is based on a Messrne Twister, and
(quoting the Python docs here), "is completely unsuitable for
cryptographic purposes".  To my understand that's how we're trying to
use it, and if I'm wrong here I wonder why we give preference to the
system random at all?

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

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

Re: Problem with randrange in django/middleware/csrf.py

[Russell Keith-Magee]

On Thu, Jul 8, 2010 at 3:17 PM, DanEE  wrote:
> Hello
>
> I posted this already in django-user. But because it is rather an
> internal django/python problem I will repost it here
>
> I experienced a strange behaviour with my django application when I
> wanted to deploy and test on my apache instance on my virtual server.
> I could successfully deploy my application but when I wanted to access
> any view the browser just took forever to load and it never showed the
> view. Accessing any non existing view gave the correct debug error
> view.
>
> After a long debugging session I could locate the problem to be in
> django/middleware/csrf.py. The call which actually took a very long
> time was the call to randrange(0, _MAX_CSRF_KEY).
>
> By playing around in a python session it seems that the call to the
> system randrange with random.SystemRandom().randrange(0,
> _MAX_CSRF_KEY) never stops (or doesn't seem to stop in less than 30
> minutes) whereas a call to the "normal" randrange with randrange(0,
> _MAX_CSRF_KEY) happily returns the desired random number.
> The problem seems to depend on the size of the argument.
> random.SystemRandom().randrange happily returns the random values if
> the arguments are significantly lower. (I just deleted some number
> from the _MAX_CSRF_KEY and then it worked)
>
> I had to manully set the line "randrange = random.randrange" instead
> of the if/else logic which checks for the system random generator to
> make my app work on my virtual host.
>
> Now it seems that is not a django problem per se. But I am wondering
> what I should to with this kind of error as I had to manually fiddle
> around in the django-code to be able to successfully host my
> application.

This is concerning, but I can't reproduce anything like it -- on every
platform I have available for testing, randrange() returns almost
instantaneously.

If you call randrange from a normal python prompt, do you see the same
sort of delays? What about if you call randrange() in a simple Django
view? (i.e., start a new project with a simple view with no forms, and
call randrange() in that view?). Do you get similar lockups if you run
the CSRF tests in the Django test suite?

If you can find the source of this problem, we will be only too happy
to fix it -- but until we can narrow down the specific set of
circumstances that causes the problem, there's not much we can do.

Yours,
Russ Magee %-)

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

Re: problem in modeladmin response_action

[Karen Tracey]

On Mon, Mar 1, 2010 at 9:47 AM, Luca Sbardella wrote:

> Hi there,
>
> I just switch from 1.2 beta 1 to svn version and the
> ModelAdmin.response_action is not working as before


Yes, this has been reported at least twice in the tracker (see
http://code.djangoproject.com/ticket/12962) and at least once before on this
list.

Karen

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

Re: problem with spatial data in sqlite

[Vladimir Sidorenko]

Hi

You have to reinstall pysqlite2 with specific flag:
http://geodjango.org/docs/install.html#pysqlite2

31 янв. 2010, в 09:48, Alexis Selves написал(а):

> Hello,
> I have serious problem with my geodjango and spatial data in DB. I
> create my models and then I want to sync my db and  it doesn't work.
> I have following output on terminal:
> traceback (most recent call last):
>  File "manage.py", line 11, in 
>execute_manager(settings)
>  File "/usr/lib/pymodules/python2.6/django/core/management/
> __init__.py", line 362, in execute_manager
>utility.execute()
>  File "/usr/lib/pymodules/python2.6/django/core/management/
> __init__.py", line 303, in execute
>self.fetch_command(subcommand).run_from_argv(self.argv)
>  File "/usr/lib/pymodules/python2.6/django/core/management/base.py",
> line 195, in run_from_argv
>self.execute(*args, **options.__dict__)
>  File "/usr/lib/pymodules/python2.6/django/core/management/base.py",
> line 222, in execute
>output = self.handle(*args, **options)
>  File "/usr/lib/pymodules/python2.6/django/core/management/base.py",
> line 286, in handle
>app_output = self.handle_app(app, **options)
>  File "/usr/lib/pymodules/python2.6/django/core/management/commands/
> sqlall.py", line 10, in handle_app
>return u'\n'.join(sql_all(app, self.style)).encode('utf-8')
>  File "/usr/lib/pymodules/python2.6/django/core/management/sql.py",
> line 157, in sql_all
>return sql_create(app, style) + sql_custom(app, style) +
> sql_indexes(app, style)
>  File "/usr/lib/pymodules/python2.6/django/core/management/sql.py",
> line 28, in sql_create
>tables = connection.introspection.table_names()
>  File "/usr/lib/pymodules/python2.6/django/db/backends/__init__.py",
> line 490, in table_names
>cursor = self.connection.cursor()
>  File "/usr/lib/pymodules/python2.6/django/db/backends/__init__.py",
> line 81, in cursor
>cursor = self._cursor()
>  File "/usr/lib/pymodules/python2.6/django/db/backends/sqlite3/
> base.py", line 175, in _cursor
>connection_created.send(sender=self.__class__)
>  File "/usr/lib/pymodules/python2.6/django/dispatch/dispatcher.py",
> line 166, in send
>response = receiver(signal=self, sender=sender, **named)
>  File "/usr/lib/pymodules/python2.6/django/contrib/gis/db/backend/
> spatialite/__init__.py", line 26, in initialize_spatialite
>connection.connection.enable_load_extension(True)
> AttributeError: 'pysqlite2.dbapi2.Connection' object has no attribute
> 'enable_load_extension'
> peta...@petarda-desktop:~/Skola/Django/mysite$ python manage.py sqlall
> maps
> Traceback (most recent call last):
>  File "manage.py", line 11, in 
>execute_manager(settings)
>  File "/usr/lib/pymodules/python2.6/django/core/management/
> __init__.py", line 362, in execute_manager
>utility.execute()
>  File "/usr/lib/pymodules/python2.6/django/core/management/
> __init__.py", line 303, in execute
>self.fetch_command(subcommand).run_from_argv(self.argv)
>  File "/usr/lib/pymodules/python2.6/django/core/management/base.py",
> line 195, in run_from_argv
>self.execute(*args, **options.__dict__)
>  File "/usr/lib/pymodules/python2.6/django/core/management/base.py",
> line 222, in execute
>output = self.handle(*args, **options)
>  File "/usr/lib/pymodules/python2.6/django/core/management/base.py",
> line 286, in handle
>app_output = self.handle_app(app, **options)
>  File "/usr/lib/pymodules/python2.6/django/core/management/commands/
> sqlall.py", line 10, in handle_app
>return u'\n'.join(sql_all(app, self.style)).encode('utf-8')
>  File "/usr/lib/pymodules/python2.6/django/core/management/sql.py",
> line 157, in sql_all
>return sql_create(app, style) + sql_custom(app, style) +
> sql_indexes(app, style)
>  File "/usr/lib/pymodules/python2.6/django/core/management/sql.py",
> line 28, in sql_create
>tables = connection.introspection.table_names()
>  File "/usr/lib/pymodules/python2.6/django/db/backends/__init__.py",
> line 490, in table_names
>cursor = self.connection.cursor()
>  File "/usr/lib/pymodules/python2.6/django/db/backends/__init__.py",
> line 81, in cursor
>cursor = self._cursor()
>  File "/usr/lib/pymodules/python2.6/django/db/backends/sqlite3/
> base.py", line 175, in _cursor
>connection_created.send(sender=self.__class__)
>  File "/usr/lib/pymodules/python2.6/django/dispatch/dispatcher.py",
> line 166, in send
>response = receiver(signal=self, sender=sender, **named)
>  File "/usr/lib/pymodules/python2.6/django/contrib/gis/db/backend/
> spatialite/__init__.py", line 26, in initialize_spatialite
>connection.connection.enable_load_extension(True)
> AttributeError: 'pysqlite2.dbapi2.Connection' object has no attribute
> 'enable_load_extension'
> 
> I guess I need to compile my sqlite, but I don't know how..
> 
> Please help me..
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to 

Re: problem with spatial data in sqlite

[Karen Tracey]

Please post questions about using Django to django-users.  django-developers
is for discussion of developing Django itself.

Karen

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

Re: Problem with history view in admin page

[Mario Briggs]

>
> I'm not sure what you're asking me. "Blockers" of what?
>

I meant, for sure we know that the backend can switch the lookup to
the hidden column (from the original column) by overriding -
'field_cast_sql(self, db_type):'

The backend also needs to execute the SQL to create the hidden column
during Django's index creation process. Rahul hasnt yet started
digging where to add that. The 'Blocker' question was if uphead anyone
knew that would be problematic for the backend to do ?

regards
Mario
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Thu, Jan 7, 2010 at 2:02 PM, Mario Briggs  wrote:
> Russ,
>
> The indexing that Oracle is supporting is 'index-on-expression'. DB2
> also supports that, but it isnt enabled for character long columns,
> since they hadnt had a request for that. I talked to the DB2 server
> folks about these use-cases and they have agreed to support this via
> index-on-expression shortly. For the immediate needs, Rahul is going
> to look at supporting this via 'hidden' columns -  Whenever there is a
> text field with an index specified, the backend will create a hidden
> and generated column (poplated with first X chars of the text field).
> The index will be created on this hidden column. When there is a
> lookup by value, the backend will actually do the lookup on the hidden
> indexed column. - you see any blockers to this ?

I'm not sure what you're asking me. "Blockers" of what?

I know almost nothing about DB2; I know only slightly more about
Oracle. I can only advise you on what Django does. In this case, the
code tells you everything you need to know: Django needs to be able to
issue the following query:

action_list = LogEntry.objects.filter(
object_id = object_id,
content_type__id__exact =
ContentType.objects.get_for_model(model).id
).select_related().order_by('action_time')

As long as you can satisfy that requirement, you've done everything
you need to do.

> BTW, index is not turned ON on LogEntry.object_id. Do you feel this
> use-case usage is low to warrant that ?

I can't say the lack of an index on that field has been a performance
problem on any site I've managed, and I don't recall seeing any
reports on the mailing list or Trac that indicate that it has caused a
problem for anyone else.

Yours,
Russ Magee %-)
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Problem with history view in admin page

[Mario Briggs]

Russ,

The indexing that Oracle is supporting is 'index-on-expression'. DB2
also supports that, but it isnt enabled for character long columns,
since they hadnt had a request for that. I talked to the DB2 server
folks about these use-cases and they have agreed to support this via
index-on-expression shortly. For the immediate needs, Rahul is going
to look at supporting this via 'hidden' columns -  Whenever there is a
text field with an index specified, the backend will create a hidden
and generated column (poplated with first X chars of the text field).
The index will be created on this hidden column. When there is a
lookup by value, the backend will actually do the lookup on the hidden
indexed column. - you see any blockers to this ?


BTW, index is not turned ON on LogEntry.object_id. Do you feel this
use-case usage is low to warrant that ?

regards
Mario
-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Problem with history view in admin page

[Mario Briggs]

> The *only* reason that we are even talking about adding this field is
> because DB2 can't index on the datatype that is the natural match for
> a length-unlimited TextField.
>  Oracle's indexing imposes an
> implicit limit of 4000 characters; that sounds to me like as good a
> number as any.

Russ,
When i saw Karen's post about the cast to 4k in the adapter, i assumed
that it was not backed by an index in the database. Your above 'text'
made me go and search this in Oracle and i found that u can actually
index the first 4k characters in an Oracle NCLOB. The fact that one
can index it, changes things and let me relook at the needs here

regards
Mario

--

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

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Wed, Dec 9, 2009 at 8:17 PM, Mario Briggs  wrote:
> I was too harsh on the GenericKeyField. How about GenericKeyField
> (length=x). I think the reason i put length in there is obvious, but i
> can explain if need be.

Well, you may have to, because the reason that it doesn't need a
length is also obvious, and I've already explained it. To clarify:

The *only* reason that we are even talking about adding this field is
because DB2 can't index on the datatype that is the natural match for
a length-unlimited TextField.

That means that the DB2 backend needs to be able to differentiate
between text fields that are actually storing length-unlimited text,
and text fields that are being used as a generic key store.

Now, a field is either a generic key field, or it isn't. If it is, it
needs to be able to store as generic a key as the backend will allow.
Ideally, that would be an length-unlimited text field, and on SQLite,
MySQL, Postgres and Oracle, it will be. However, this isn't possible
on DB2; but given that text fields aren't used as primary keys in
practice, a suitably long character limitation will suffice.

How long? Pick a number. It doesn't matter what number you pick - DB2
is the only database that will be affected, and whatever N you pick, I
will be able to produce a model with a CharField primary key with
length N+1 that will break it. You just need to pick an N such that
all practical use cases will be covered. Oracle's indexing imposes an
implicit limit of 4000 characters; that sounds to me like as good a
number as any.

As far as I can make out, there is absolutely no use case for
specifying a length in GenericKeyField. Feel free to let me know the
flaw in my reasoning.

Yours,
Russ Magee %-)

--

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

Re: Problem with history view in admin page

[Mario Briggs]

I was too harsh on the GenericKeyField. How about GenericKeyField
(length=x). I think the reason i put length in there is obvious, but i
can explain if need be.

In post #14 on this thread you suggested - " I'm not wild about the
idea of having underlying datatypes change based on attributes in a
field definition. To date, Django has maintained a clear mapping
between Field type and database type."

I am not suggesting that backends change the type in the DB based on
the 'length'. They should use 1 fixed type for GenericKeyField

regards
Mario




--

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

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Thu, Dec 3, 2009 at 12:59 PM, Mario Briggs  wrote:
> Russ,
>
> I dont agree to the *it works* theory here - Ian rightly said 'If you
> ask me,
> anybody foolish enough to use a TextField as a primary key deserves
> what they get' and you agreed  'Your comment about foolishness is
> definitely correct '

I can point at countless Django installations that have perfectly
functioning admin interfaces. I'm sorry to break this to you, but that
means that Django's admin works.

Django assumes that it is possible to do a lookup on a TextField. This
behavior is implemented and usable on SQLite, Postgres, MySQL and
Oracle. Oracle has a slight caveat (4k character limit) on this
capability, but that doesn't place any practical limitations on the
unconventional way that Django uses TextField in the admin.

If the DB2 backend doesn't support lookups on TextFields, then that is
a problem with the DB2 backend, not Django.

> Putting it in context, this is in the 'user control area' and the fact
> that one can go ahead and change the type in the LogEntry definition
> like Helgi did means it not a blockade

I'm not sure what you mean by "user control area", but if you want to
propose manual table modification as a solution to this problem,
that's between you and your userbase.

>  (though it would be good if
> Django got i right first time).

Django *did* get it right first time. I've already explained why the
code is the way it is. *None* of the officially supported Django
backends have any problem with this usage. To my reading, this is
*entirely* a problem with the DB2 backend.

Now, if you want to propose a modification to Django that will make it
easier for you to implement the DB2 backend, I'm open to suggestions.
I've already made one such suggestion, which based on your reaction,
you don't like. Now it's your turn to make a counterproposal.

> I have another question though but that is due to my lack of wide
> usage of Django - so you mentioned that u were scared to make the
> changes becuase of problems with migrations - once Helgi makes that
> change and the next time he is upgrading to the a higher version of
> Django, is there anything he needs to do ?

Once Django has rolled out a table, it doesn't try to recreate or
validate that the table is the same at the database level. As long as
the database-level table definition is functionally compatible with
the model definition, you shouldn't have any problems.

Yours,
Russ Magee %-)

--

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

Re: Problem with history view in admin page

[Mario Briggs]

Russ,

I dont agree to the *it works* theory here - Ian rightly said 'If you
ask me,
anybody foolish enough to use a TextField as a primary key deserves
what they get' and you agreed  'Your comment about foolishness is
definitely correct '

Putting it in context, this is in the 'user control area' and the fact
that one can go ahead and change the type in the LogEntry definition
like Helgi did means it not a blockade (though it would be good if
Django got i right first time).

I have another question though but that is due to my lack of wide
usage of Django - so you mentioned that u were scared to make the
changes becuase of problems with migrations - once Helgi makes that
change and the next time he is upgrading to the a higher version of
Django, is there anything he needs to do ?

cheers
Mario

--

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

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Fri, Nov 27, 2009 at 3:22 PM, Yuri Baburov  wrote:
> Hi Russell,
>
> On Thu, Nov 26, 2009 at 1:47 PM, Russell Keith-Magee
>  wrote:
>> On Wed, Nov 25, 2009 at 4:24 PM, Yuri Baburov  wrote:
>>> Hi Russell,
>>>
>>> is it possible to introduce some new field type
>>> ShortTextField for that purpose, that will be by default
>>> `varchar(4000)` on Oracle and DB2 who supports long varchars, and
>>> `text` on other backends like it was before, excepting 'smalltext'
>>> instead of 'longtext' for mysql?
>>
>> I can see that this approach doesn't have any backward compatibility
>> issues. However, from a documentation point of view, explaining the
>> difference between a ShortTextField and a TextField requires a leaky
>> abstraction (i.e., you have to know about implementation details in
>> order for the explanation to make sense).
>>
>> With a different coat of paint, it might be more palatable. A name
>> like ShortTextField presupposes the storage implementation, but tells
>> you nothing about the appropriate usage. However, a different name -
>> something like GenericKeyField tells you nothing about the storage,
>> but does tell you  when it might be appropriate to use it.
>>
>> Of course GenericKeyField has the problem of being easy to confuse
>> with GenericForeignKey. For that reason, I'm not sold on
>> GenericKeyField as a name - any suggestions in this general vein are
>> welcome.
> First, since we have a lot of fields already like
> PositiveIntegerField, there is no problem to add one more specific
> field. It's not new kind of fields distinction, it's just one more
> specie of them.

PostiveIntegerField isn't a good example here - in fact, it reinforces
my point. PositiveIntegerField tells you nothing concrete about the
underlying storage - all it describes is a validation condition.

> But then much more general problem arises: use of CLOB instead of
> varchar2 where 255 To support Oracle, all Django programmers should now be aware of this
> Oracle-specific data type distinction, should know that SmallTextField
> is better than TextField for some situations, etc.
> That's awful.

Agreed. That's why I don't like the idea of adding
(Short|Small)TextField. However, if you step away from calling it a
TextField, and give it a semantic purpose - storing a Generic Key -
then it isn't confusing at all. If you want to store a generic key,
use a GenericKeyField. If you want to store text, use a TextField.

> So the enhanced idea appears:
> TextField(max_length=x) where x<=4000 to be treated as varchar2(x) in Oracle.
> TextField with greater length and TextField without length to be
> treated as NCLOB.
>
> LogEntry.object_id rewritten as TextField(max_length=4000).
> Documented as a restriction by design, that prevents bad usages.
>
> This should be documented in Oracle backend docs on data types in bold.

I'm not wild about the idea of having underlying datatypes change
based on attributes in a field definition. To date, Django has
maintained a clear mapping between Field type and database type.

> Am I correct that varchar2 is always preferred to NCLOB where appropriate?

On this point I would need to defer to our friendly community Oracle experts.

>>> I think this is a point where "TextField is accessed by value"
>>> abstraction breaks, and better separation between long string and
>>> referenced object should be introduced.
>>
>> Agreed.
>>
>>> I assume we have not much Oracle & DB2 users yet, and nothing will
>>> change for them unless they already suffer from this problem and they
>>> will not anymore. Migration script is single "alter table" command,
>>> and that needs to be documented.
>>
>> I'm always a little nervous about upgrading instructions, and doubly
>> so about those that include database migrations. History has shown us
>> that it doesn't matter how well we write upgrading notes - backwards
>> incompatible changes cause problems. Unless there is a particularly
>> compelling reason to change the existing Oracle implementation, I'd
>> rather not force that change.
> Yes, they are always a pain, but in such situation I'm feeling like in
> a surgeon.
> I tend to prefer to do surgery once instead of living with constant pain.
> For this problem, pain is not strong, but surgery is quick, and those who use
> newer Django won't even know about that pain.

Django has a very firm backwards compatibility guarantee. We are very
careful that when we roll out a new version, it doesn't break any
existing installations because of changes in  documented interfaces.
Even if you take one of the biggest changes in Django's post 1.0
history - CSRF support - it has been added in such a way that any
existing installation shouldn't be affected by upgrading from 1.1 to
trunk.

Unfortunately, absent of a schema migration system built into Django,
there simply isn't any way to handle changes to model definitions for
existing Django tables in 

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Fri, Nov 27, 2009 at 4:21 PM, Mario Briggs  wrote:
> Russ,
>
>> With a different coat of paint, it might be more palatable. A name
>> like ShortTextField presupposes the storage implementation, but tells
>> you nothing about the appropriate usage. However, a different name -
>> something like GenericKeyField tells you nothing about the storage,
>> but does tell you  when it might be appropriate to use it.
>>
>
> GenericKeyField  - Its hard for me to see that a end-user would not be
> interested in the specific type of his column at the database
> especially if its a key field.

Depends on the focus of the developer. DB-focussed developers or
developers looking to optimize query performance might care about the
underlying storage. However, developers working at a higher level just
want their data to be stored. The exact database type is irrelevant as
long as queries using that field work in reasonable time.

Django currently uses a TextField is currently storing a
string-serialized form of the key of an arbitrary object. What is
being stored in any given row can be determined by looking at the
content_type of the row (or rather, the primary key type of the model
that the content type refers to). It is used to create log entries
that point at arbitrary objects in the database. From a pure DBA,
third-normal-form perspective, it isn't an especially efficient data
structure - but it *works* for the situation in which it used. At the
end of the day, that's what really matters.

Yours,
Russ Magee %-)

--

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

Re: Problem with history view in admin page

[Mario Briggs]

Richard,

> I don't know why a user should have .filter(object_id='1')
> fail, as that breaks the ORM abstraction. Maybe that's not what you're
> suggesting?

I am saying exactly what i am saying. So here's my example that does
the same thing in a java ORM

// Here's the model
@Entity
public class ClobTest {
@Id
@Type(type="text")
private String id ;

private String firstName ;
}

// here's the app
ClobTest c = EntityManager.find(hellojpa.ClobTest.class, "1");

// here's what happens
Exception in thread "main" javax.persistence.PersistenceException:
org.hibernate.exception.SQLGrammarException: could not load an entity:
[hellojpa.ClobTest#1]
at
org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException
(AbstractEntityManagerImpl.java:637)
at org.hibernate.ejb.AbstractEntityManagerImpl.find
(AbstractEntityManagerImpl.java:202)
Caused by: com.ibm.db2.jcc.b.nm: DB2 SQL Error: SQLCODE=-401,
SQLSTATE=42818,
SQL0401N -   The data types of the operands for the operation
"" are not compatible.

I am certain i would get the same exception if i used Oracle as the
DB. So i cant see why the Django Oracle Adapter should cover this.
Russ,

> With a different coat of paint, it might be more palatable. A name
> like ShortTextField presupposes the storage implementation, but tells
> you nothing about the appropriate usage. However, a different name -
> something like GenericKeyField tells you nothing about the storage,
> but does tell you  when it might be appropriate to use it.
>

GenericKeyField  - Its hard for me to see that a end-user would not be
interested in the specific type of his column at the database
especially if its a key field.

thanks
Mario

--

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

Re: Problem with history view in admin page

[Yuri Baburov]

Hi Russell,

On Thu, Nov 26, 2009 at 1:47 PM, Russell Keith-Magee
 wrote:
> On Wed, Nov 25, 2009 at 4:24 PM, Yuri Baburov  wrote:
>> Hi Russell,
>>
>> is it possible to introduce some new field type
>> ShortTextField for that purpose, that will be by default
>> `varchar(4000)` on Oracle and DB2 who supports long varchars, and
>> `text` on other backends like it was before, excepting 'smalltext'
>> instead of 'longtext' for mysql?
>
> I can see that this approach doesn't have any backward compatibility
> issues. However, from a documentation point of view, explaining the
> difference between a ShortTextField and a TextField requires a leaky
> abstraction (i.e., you have to know about implementation details in
> order for the explanation to make sense).
>
> With a different coat of paint, it might be more palatable. A name
> like ShortTextField presupposes the storage implementation, but tells
> you nothing about the appropriate usage. However, a different name -
> something like GenericKeyField tells you nothing about the storage,
> but does tell you  when it might be appropriate to use it.
>
> Of course GenericKeyField has the problem of being easy to confuse
> with GenericForeignKey. For that reason, I'm not sold on
> GenericKeyField as a name - any suggestions in this general vein are
> welcome.
First, since we have a lot of fields already like
PositiveIntegerField, there is no problem to add one more specific
field. It's not new kind of fields distinction, it's just one more
specie of them.

But then much more general problem arises: use of CLOB instead of
varchar2 where 255> I think this is a point where "TextField is accessed by value"
>> abstraction breaks, and better separation between long string and
>> referenced object should be introduced.
>
> Agreed.
>
>> I assume we have not much Oracle & DB2 users yet, and nothing will
>> change for them unless they already suffer from this problem and they
>> will not anymore. Migration script is single "alter table" command,
>> and that needs to be documented.
>
> I'm always a little nervous about upgrading instructions, and doubly
> so about those that include database migrations. History has shown us
> that it doesn't matter how well we write upgrading notes - backwards
> incompatible changes cause problems. Unless there is a particularly
> compelling reason to change the existing Oracle implementation, I'd
> rather not force that change.
Yes, they are always a pain, but in such situation I'm feeling like in
a surgeon.
I tend to prefer to do surgery once instead of living with constant pain.
For this problem, pain is not strong, but surgery is quick, and those who use
newer Django won't even know about that pain.
If we'll settle on a good enough solution, of course.

-- 
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

--

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

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Wed, Nov 25, 2009 at 4:24 PM, Yuri Baburov  wrote:
> Hi Russell,
>
> is it possible to introduce some new field type
> ShortTextField for that purpose, that will be by default
> `varchar(4000)` on Oracle and DB2 who supports long varchars, and
> `text` on other backends like it was before, excepting 'smalltext'
> instead of 'longtext' for mysql?

I can see that this approach doesn't have any backward compatibility
issues. However, from a documentation point of view, explaining the
difference between a ShortTextField and a TextField requires a leaky
abstraction (i.e., you have to know about implementation details in
order for the explanation to make sense).

With a different coat of paint, it might be more palatable. A name
like ShortTextField presupposes the storage implementation, but tells
you nothing about the appropriate usage. However, a different name -
something like GenericKeyField tells you nothing about the storage,
but does tell you  when it might be appropriate to use it.

Of course GenericKeyField has the problem of being easy to confuse
with GenericForeignKey. For that reason, I'm not sold on
GenericKeyField as a name - any suggestions in this general vein are
welcome.

> I think this is a point where "TextField is accessed by value"
> abstraction breaks, and better separation between long string and
> referenced object should be introduced.

Agreed.

> I assume we have not much Oracle & DB2 users yet, and nothing will
> change for them unless they already suffer from this problem and they
> will not anymore. Migration script is single "alter table" command,
> and that needs to be documented.

I'm always a little nervous about upgrading instructions, and doubly
so about those that include database migrations. History has shown us
that it doesn't matter how well we write upgrading notes - backwards
incompatible changes cause problems. Unless there is a particularly
compelling reason to change the existing Oracle implementation, I'd
rather not force that change.

Yours,
Russ Magee %-)

--

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

Re: Problem with history view in admin page

[Richard Laager]

On Tue, 2009-11-24 at 20:54 -0800, Mario Briggs wrote:
> Instead we will let users run into errors when they do a '=' compare
> of a Django Text type, and then let them ponder whether they need that
> column as a CLOB in the backend.

Shouldn't something be changing that = into a LIKE (and escaping LIKE
metacharacters in the parameter)?

I don't know why a user should have .filter(object_id='1')
fail, as that breaks the ORM abstraction. Maybe that's not what you're
suggesting?

Richard


signature.asc
Description: This is a digitally signed message part

Re: Problem with history view in admin page

[Mario Briggs]

Russell,

> >> Well, Django doesn't make the decision to use CLOB - that's in the
> >> hands of your backend. In the same circumstances, SQLite and Postgres
> >> use 'text'. MySQL uses 'longtext'. Oracle uses 'NCLOB'

I understand that the decision to what 'Text' should be mapped to is
the choice of the backend. Given the examples you gave what the DB2
adapter is doing is right.

IMHO during DB design, choosing a column' type  as CLOB when it really
wont be varcharXXX doesnt cut it from multiple angles.

If the DB2 backend did the same hack as Karen mentioned, we would be
guilty of abetting bad database design. Therefore we will not do that.
Instead we will let users run into errors when they do a '=' compare
of a Django Text type, and then let them ponder whether they need that
column as a CLOB in the backend.

Mario

--

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

Re: Problem with history view in admin page

[Karen Tracey]

On Tue, Nov 24, 2009 at 7:09 PM, Russell Keith-Magee  wrote:

> This is a slightly moot point, though; Django defines the admin log
> object_id using a TextField, and changing this would be a big
> backwards incompatibility.
>
>
Also I believe there's at least one other place in Django that does similar
-- the object_pk in the base contrib.comments model is also a TextField.  I
suspect any DB backend that  has trouble with the admin history view is also
going to run into trouble with comments.

Karen

--

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

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Wed, Nov 25, 2009 at 1:25 AM, Ian Kelly  wrote:
> On Mon, Nov 23, 2009 at 11:00 PM, Russell Keith-Magee
>  wrote:
>> On Tue, Nov 24, 2009 at 1:07 PM, Mario Briggs  
>> wrote:
>>> I agree that INTEGER is not the right choice, but then so too is CLOB.
>>> How long is this string-serialized representation going to be? greater
>>> than 4000 characters ? Varchar(X)  where X is > 4000 or something is
>>> then the right choice. This is validated by what Karen says is the
>>> Oracle fix.
>>
>> Well, Django doesn't make the decision to use CLOB - that's in the
>> hands of your backend. In the same circumstances, SQLite and Postgres
>> use 'text'. MySQL uses 'longtext'. Oracle uses 'NCLOB'
>
> The decision is based on the field type, not on the individual field.
> If it were possible within the Oracle backend to override this
> particular field to VARCHAR2, we would happily do it.  But TextFields
> in general need to be LOBs.
>
>> In theory, the contents of the object_id field could be anything -
>> including a string of arbitrary length (i.e., a TextField). However,
>> in practice, I would be surprised to see 4000+ characters for
>> object_id - most primary keys are going to be integers, and the ones
>> that aren't are likely to be short strings or string-like datatypes.
>
> Due to the hackish way the Oracle backend implements lookups on LOBs,
> it will still fail if the object_id is actually longer than 4000
> characters.  It might even raise an error (I haven't tried it).  So at
> least in Oracle we gain nothing by making this a TextField rather than
> a CharField(max_length=4000).  Plus, if it were a CharField, we would
> be able to index it.
>
> Correct me if I'm wrong, but I think the only way to get an object_id
> so large that it won't fit inside a backend-dependent CharField is if
> the primary key of the model is itself a TextField.  If you ask me,
> anybody foolish enough to use a TextField as a primary key deserves
> what they get.  Oracle won't even allow it.

Your comment about foolishness is definitely correct :-) As for the
CharField point -  following this logic, we could define object_id as
a CharField(max_length=N), for some large N. However, in the general
case, we can't specify an N that is greater than all N's that
end-users might use. Therefore, we use a TextField, which is unbound.

This is a slightly moot point, though; Django defines the admin log
object_id using a TextField, and changing this would be a big
backwards incompatibility.

Yours
Russ Magee %-)

--

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

Re: Problem with history view in admin page

[Ian Kelly]

On Mon, Nov 23, 2009 at 11:00 PM, Russell Keith-Magee
 wrote:
> On Tue, Nov 24, 2009 at 1:07 PM, Mario Briggs  wrote:
>> I agree that INTEGER is not the right choice, but then so too is CLOB.
>> How long is this string-serialized representation going to be? greater
>> than 4000 characters ? Varchar(X)  where X is > 4000 or something is
>> then the right choice. This is validated by what Karen says is the
>> Oracle fix.
>
> Well, Django doesn't make the decision to use CLOB - that's in the
> hands of your backend. In the same circumstances, SQLite and Postgres
> use 'text'. MySQL uses 'longtext'. Oracle uses 'NCLOB'

The decision is based on the field type, not on the individual field.
If it were possible within the Oracle backend to override this
particular field to VARCHAR2, we would happily do it.  But TextFields
in general need to be LOBs.

> In theory, the contents of the object_id field could be anything -
> including a string of arbitrary length (i.e., a TextField). However,
> in practice, I would be surprised to see 4000+ characters for
> object_id - most primary keys are going to be integers, and the ones
> that aren't are likely to be short strings or string-like datatypes.

Due to the hackish way the Oracle backend implements lookups on LOBs,
it will still fail if the object_id is actually longer than 4000
characters.  It might even raise an error (I haven't tried it).  So at
least in Oracle we gain nothing by making this a TextField rather than
a CharField(max_length=4000).  Plus, if it were a CharField, we would
be able to index it.

Correct me if I'm wrong, but I think the only way to get an object_id
so large that it won't fit inside a backend-dependent CharField is if
the primary key of the model is itself a TextField.  If you ask me,
anybody foolish enough to use a TextField as a primary key deserves
what they get.  Oracle won't even allow it.

Regards,
Ian

--

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

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Tue, Nov 24, 2009 at 1:07 PM, Mario Briggs  wrote:
>>>
> What is stored in this field is a string-serialized representation of
> the
> primary key value.
> <<
>
> I agree that INTEGER is not the right choice, but then so too is CLOB.
> How long is this string-serialized representation going to be? greater
> than 4000 characters ? Varchar(X)  where X is > 4000 or something is
> then the right choice. This is validated by what Karen says is the
> Oracle fix.

Well, Django doesn't make the decision to use CLOB - that's in the
hands of your backend. In the same circumstances, SQLite and Postgres
use 'text'. MySQL uses 'longtext'. Oracle uses 'NCLOB'

In theory, the contents of the object_id field could be anything -
including a string of arbitrary length (i.e., a TextField). However,
in practice, I would be surprised to see 4000+ characters for
object_id - most primary keys are going to be integers, and the ones
that aren't are likely to be short strings or string-like datatypes.

I can't comment on what would be an appropriate datatype for DB2 in
this context.

Yours,
Russ Magee %-)

--

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

Re: Problem with history view in admin page

[Mario Briggs]

>>
What is stored in this field is a string-serialized representation of
the
primary key value.
<<

I agree that INTEGER is not the right choice, but then so too is CLOB.
How long is this string-serialized representation going to be? greater
than 4000 characters ? Varchar(X)  where X is > 4000 or something is
then the right choice. This is validated by what Karen says is the
Oracle fix.

Note: the original workaround provided to Helgi was to use varchar
(3000) and if willing to be more adventurous then try INTEGER

thanks
Mario

--

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

Re: Problem with history view in admin page

[Karen Tracey]

Note Oracle had the same problem:

http://code.djangoproject.com/ticket/5087

I can't actually read Oracle but I think the fix involves adding a cast that
extracts the first 4000 chars of data from the field for comparison.  They
override the field_cast_sql method in the Oracle DatabaseOperations to add
the cast to any field type that ends with LOB.

Karen

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=.

Re: Problem with history view in admin page

[Russell Keith-Magee]

On Mon, Nov 23, 2009 at 9:12 PM, Rahul  wrote:
> Hi All,
>
> There is a problem reported for history view in admin page.
> For history view there is a sql query generated, which trying to do
> exact look-up on OBJECT_ID column (LogEntry model, DJANGO_ADMIN_LOG
> table).
>
> "TextField" is responsible for handling large text and in DB2
> "TextField" is mapped to CLOB.
> DB2 doesn't support exact look-up with CLOB datatype.
>
> When I checked the values for this OBJECT_ID column in the database,
> it only contains integer (1, 2, 3, etc.).
>
> Now the question arises: Why "OBJECT_ID" defined as "TextField" type?
> In most of the cases "XXX_ID" field is expected to be INTEGER.
>
> Is there any specific reason why "OBJECT_ID" defined as "TextField" in
> LogEntry model in "django\contrib\admin\models.py".

Yes.

The reason is that while *most* objects will use an integer as the
primary key, not *all* objects use an integer as a primary key. A
TextField is the most generic storage that can be  provided to store
*any* kind of primary key - integer, char, or otherwise. What is
stored in this field is a string-serialized representation of the
primary key value.

LogEntry.get_edited_object then issues the query to find the actual
object that is associated with the id; this relies on the fact that
Django queries will coerce string input into an appropriate data type
for a primary key lookup.

Yours
Russ Magee %-)

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=.

Re: Problem with admin after moving to another machine

[diogobaeder]

Russ: yes, I must be out of my mind. Yes, I will post in the other
group.

Sorry for this unbrained programmer... I'll try to drink less Coca-
Cola and see if my attention comes back... :-P

Thanks! And congrats for the great support! :-)

Diogo



On Jul 7, 11:58 pm, Russell Keith-Magee 
wrote:
> On Wed, Jul 8, 2009 at 10:16 AM, Diogo Baeder wrote:
>
> > Hi there,
>
> > I started to have this error:
> >http://dpaste.com/64355/
> > while trying to access my admin site, after I moved my website from one
> > machine (my desktop) to the other (my laptop). I already restored my
> > PostgreSQL database, and recreated the superuser (while trying to solve
> > this problem), but I still cannot access the admin page... can it be
> > something with the recent actions log? If so, how do I purge it? I don't
> > need this log...
>
> Like I told you yesterday, Django-developers is for discussing the
> development of Django itself. "How do I" questions should be directed
> to django-users.
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Problem with admin after moving to another machine

[Russell Keith-Magee]

On Wed, Jul 8, 2009 at 10:16 AM, Diogo Baeder wrote:
>
> Hi there,
>
> I started to have this error:
> http://dpaste.com/64355/
> while trying to access my admin site, after I moved my website from one
> machine (my desktop) to the other (my laptop). I already restored my
> PostgreSQL database, and recreated the superuser (while trying to solve
> this problem), but I still cannot access the admin page... can it be
> something with the recent actions log? If so, how do I purge it? I don't
> need this log...

Like I told you yesterday, Django-developers is for discussing the
development of Django itself. "How do I" questions should be directed
to django-users.

Yours,
Russ Magee %-)

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

Re: problem django admin

[Russell Keith-Magee]

On Wed, Jan 21, 2009 at 12:14 PM, Karen Tracey  wrote:
> On Tue, Jan 20, 2009 at 10:08 PM, Harryanto Ie 
> wrote:
>>
>> [snip]
>>
>> File
>> "c:\python25\Lib\site-packages\django\db\backends\sqlite3\base.py",
>> line 167, in execute
>> return Database.Cursor.execute(self, query, params)
>>
>> OperationalError: no such table: django_session
>>
>> i've put django.contrib.session into INSTALLEDD_APPS
>> and when i syncdb, table django_session has created.
>> what should i do?
>
> You should post this question on django-users:
>
> http://groups.google.com/group/django-users
>
> where it belongs.  This list is for development of Django itself, not user
> questions, as you have been told several times.  Please try to use the
> correct list.  Thank you.

I would add that this is the second time in two days you have been
reminded about the purpose of Django-developers. You were also warned
- twice - on the 16th of January.

If you persist in posting user queries to the developers mailing list,
we will be forced to ban you from the developers list.

I would also like to use this opportunity to _beg_ you - again - to
_please_ trim your signature.

Yours,
Russ Magee %-)

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

Re: problem django admin

[Karen Tracey]

On Tue, Jan 20, 2009 at 10:08 PM, Harryanto Ie wrote:

> [snip]

File
> "c:\python25\Lib\site-packages\django\db\backends\sqlite3\base.py",
> line 167, in execute
> return Database.Cursor.execute(self, query, params)
>
> OperationalError: no such table: django_session
>
> i've put django.contrib.session into INSTALLEDD_APPS
> and when i syncdb, table django_session has created.
> what should i do?


You should post this question on django-users:

http://groups.google.com/group/django-users

where it belongs.  This list is for development of Django itself, not user
questions, as you have been told several times.  Please try to use the
correct list.  Thank you.

Karen

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

Re: Problem with ORM

[Malcolm Tredinnick]

On Fri, 2009-01-16 at 00:38 +0100, Sebastian Bauer wrote:
> I think ORM supposed to have save insert and update:
> 
> save(force_insert=False,force_update=False)
> update() == save(force_update=True)
> insert() == save(force_insert=True)

There was a long discussion a couple of years ago about whether to add
method names like that or not. In the end, it was my decision and I
decided not to. There were reasonable arguments in favour of both
alternatives, but the decisive issue for me is that since "insert" and
"update" are both common words, introducing new methods with those names
in the model method namespace had a reasonable chance of colliding with
existing methods that people may have on their models (which would hide
the Django versions). I, for one, don't like introducing even small
backwards incompatibilities, particularly ones that would fail
effectively silently, when we don't have to, and that was a guiding
consideration in the API design even prior to Django 1.0.

Even now, although adding these methods wouldn't strictly break our
policy, it does run the risk of name collision with methods people have
on their own models. Adding new names to the heavily used namespace
(every single Model subclass uses that namespace) of Model should be
done with extreme caution.

> in that situation we could have clean code and we know that update is
> realy update on DB

Just like  we already know that force_update=True means "force an
update". You have to really try hard to misinterpret a save() call that
uses that parameter. It's as explicit as can be. "Clean" isn't a unique
condition: some piece of code can appear cleaner to one person than
another piece, but it doesn't mean the latter is unclean. It just means
you have a preference. The distinction is important.

> i now we can have save(force_update=True) but update() looks better
> and we have insert() already

No, Model.insert() doesn't exist already.

Whether you prefer update() to save(force_update=True) is stylistic and
opinions will vary. As noted above, there is the namespace pollution
issue to consider and that is the reason we don't have it. There's no
harm done by omitting it. As noted, if you want it on your models, add
it as part of a standard base class. You'll be happy and other people's
code still won't break in mysterious ways.

> IMHO save() is only wrapper for save_base()

You've misunderstood things, in that case. Have a look at the method
signatures. The save() provides the public API, whereas save_base() is
the more internal API (and is something we can add parameters to, if
required, without breaking the API stability guarantee).

Regards,
Malcolm


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

Re: Problem with ORM

[Sebastian Bauer]

W dniu 16.01.2009 16:34, varikin pisze:
>
> On Jan 15, 5:38 pm, Sebastian Bauer  wrote:
>
>> I think ORM supposed to have save insert and update:
>>
>> save(force_insert=False,force_update=False)
>> update() == save(force_update=True)
>> insert() == save(force_insert=True)
>>
>> in that situation we could have clean code and we know that update is
>> realy update on DB
>>
>> i now we can have save(force_update=True) but update() looks better and
>> we have insert() already
>>
>> IMHO save() is only wrapper for save_base()
>>
>>  
>
> Those look like great methods to have, but since Django has already
> hit 1.0 with a statement about API stability, I don't want the core
> developers changing it on me. I don't think the ORM is wrong, just
> designed differently than other ORMs.
>
I now Django 1.0.x have stable API but 1.1 is still in develop so it 
could be add

another function i waiting for is select_for_update() ticket #2705 is 
small but important for me and i realy want it in trunk :)

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

Re: Problem with ORM

[varikin]

On Jan 15, 5:38 pm, Sebastian Bauer  wrote:
> I think ORM supposed to have save insert and update:
>
> save(force_insert=False,force_update=False)
> update() == save(force_update=True)
> insert() == save(force_insert=True)
>
> in that situation we could have clean code and we know that update is
> realy update on DB
>
> i now we can have save(force_update=True) but update() looks better and
> we have insert() already
>
> IMHO save() is only wrapper for save_base()
>

Those look like great methods to have, but since Django has already
hit 1.0 with a statement about API stability, I don't want the core
developers changing it on me. I don't think the ORM is wrong, just
designed differently than other ORMs.

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

Re: Problem with ORM

[Jacob Kaplan-Moss]

> Because I deleted that object. Delete method should be non-reversible
> (except in transactions) like "del" statement in Python. Or anybody
> knows any reason, why it should be reversible?

You didn't delete the object. That'd be spelled ``del instance``. You
called a method called ``delete`` on an instance of a ``Model``
object. This is documented as deleting the row in the database that
the object represents. You then called a method named ``save`` on a
``Model`` instance. This is documented as performing an insert if the
row in question does not exist.

If it doesn't behave the way you want it to, I'm sorry. But this is
"correct" behavior: it matches the documentation, and both of them
match the design.

Jacob

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

Re: Problem with ORM

[Sebastian Bauer]

I think ORM supposed to have save insert and update:

save(force_insert=False,force_update=False)
update() == save(force_update=True)
insert() == save(force_insert=True)

in that situation we could have clean code and we know that update is 
realy update on DB

i now we can have save(force_update=True) but update() looks better and 
we have insert() already

IMHO save() is only wrapper for save_base()

W dniu 16.01.2009 00:15, Jan Bednařík pisze:
> On Thu, Jan 15, 2009 at 11:11 PM, Collin Grady  wrote:
>
>> On Thu, Jan 15, 2009 at 2:09 PM, Jan Bednařík  wrote:
>>  
>>> That should not happen.
>>>
>>> instance.delete()
>>> instance.save()
>>>
>>> should raise ObjectDoesNotExist exception. Any other behavior is bug.
>>>
>> Why? You have a perfectly valid object instance, and you're then saving it.
>>  
>
> Because I deleted that object. Delete method should be non-reversible
> (except in transactions) like "del" statement in Python. Or anybody
> knows any reason, why it should be reversible?
>
> If I try to call save() or any other method on deleted object, than
> it's just and only my mistake and I should get exceptions. But quiet
> undelete effect of save() method can cause lot of "hard to find" bugs
> in final app. Especially if probably nobody is expecting something
> like that.
>
> Jan
>
> >
>
>

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

Re: Problem with ORM

[Jan Bednařík]

On Thu, Jan 15, 2009 at 11:11 PM, Collin Grady  wrote:
> On Thu, Jan 15, 2009 at 2:09 PM, Jan Bednařík  wrote:
>> That should not happen.
>>
>> instance.delete()
>> instance.save()
>>
>> should raise ObjectDoesNotExist exception. Any other behavior is bug.
>
> Why? You have a perfectly valid object instance, and you're then saving it.

Because I deleted that object. Delete method should be non-reversible
(except in transactions) like "del" statement in Python. Or anybody
knows any reason, why it should be reversible?

If I try to call save() or any other method on deleted object, than
it's just and only my mistake and I should get exceptions. But quiet
undelete effect of save() method can cause lot of "hard to find" bugs
in final app. Especially if probably nobody is expecting something
like that.

Jan

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

Re: Problem with ORM

[Collin Grady]

On Thu, Jan 15, 2009 at 2:09 PM, Jan Bednařík  wrote:
> That should not happen.
>
> instance.delete()
> instance.save()
>
> should raise ObjectDoesNotExist exception. Any other behavior is bug.

Why? You have a perfectly valid object instance, and you're then saving it.

Just like if you had instantiated it.

If you want it to fail if the object is gone, use force_update=True as
you were told before.

This is not an ORM bug, no matter how much you would like it to act otherwise.

-- 
Collin Grady

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

Re: Problem with ORM

[Jan Bednařík]

2009/1/15 Ian Kelly :
> On Thu, Jan 15, 2009 at 1:58 AM, Jan Bednařík  wrote:
>>
>> On Wed, Jan 14, 2009 at 6:51 PM, Sebastian Bauer  wrote:
>>>
>>> Hi
>>>
>>> I think it's a bug, but maybe im wrong:
>>>
>>>
>>> print Categories.objects.count()
>>>  >>0
>>> new_obj = Categories.objects.create(name="test")
>>> instance_1  = Categories.objects.get(pk=new_obj.pk)
>>> instance_2 = Categories.objects.get(pk=new_obj.pk)
>>>
>>> instance_1.delete()
>>> print Kategorie.objects.count()
>>>  >>0
>>> instance_2.save()
>>> print Kategorie.objects.count()
>>>  >>1
>>>
>>> how orm can save second instance of the same row when its deleted?
>>>
>>> i have 2 options to solve this problem:
>>>
>>> 1. create method of Model instance to check if row exists and let users
>>> to handle it by own
>>> or
>>> 2. throw exception ex. models.DoesNotExist
>>>
>>> what you think about this problem?
>>
>> Hi,
>>
>> this is happening, because Django ORM is not working as what you
>> expect from ORM.
>>
>> In real ORM, this:
>>
>> instance_1 = Categories.objects.get(pk=new_obj.pk)
>> instance_2 = Categories.objects.get(pk=new_obj.pk)
>>
>> will make only one instance with two pointers on it.
>
> No, it's just the behavior of the save method.  You can perform the
> operations above with a single instance and still get the same result
> - the row is deleted and then reinserted.

That should not happen.

instance.delete()
instance.save()

should raise ObjectDoesNotExist exception. Any other behavior is bug.

Jan

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

Re: Problem with ORM

[Ian Kelly]

On Thu, Jan 15, 2009 at 1:58 AM, Jan Bednařík  wrote:
>
> On Wed, Jan 14, 2009 at 6:51 PM, Sebastian Bauer  wrote:
>>
>> Hi
>>
>> I think it's a bug, but maybe im wrong:
>>
>>
>> print Categories.objects.count()
>>  >>0
>> new_obj = Categories.objects.create(name="test")
>> instance_1  = Categories.objects.get(pk=new_obj.pk)
>> instance_2 = Categories.objects.get(pk=new_obj.pk)
>>
>> instance_1.delete()
>> print Kategorie.objects.count()
>>  >>0
>> instance_2.save()
>> print Kategorie.objects.count()
>>  >>1
>>
>> how orm can save second instance of the same row when its deleted?
>>
>> i have 2 options to solve this problem:
>>
>> 1. create method of Model instance to check if row exists and let users
>> to handle it by own
>> or
>> 2. throw exception ex. models.DoesNotExist
>>
>> what you think about this problem?
>
> Hi,
>
> this is happening, because Django ORM is not working as what you
> expect from ORM.
>
> In real ORM, this:
>
> instance_1 = Categories.objects.get(pk=new_obj.pk)
> instance_2 = Categories.objects.get(pk=new_obj.pk)
>
> will make only one instance with two pointers on it.

No, it's just the behavior of the save method.  You can perform the
operations above with a single instance and still get the same result
- the row is deleted and then reinserted.

Ian

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

Re: Problem with ORM

[James Bennett]

On Thu, Jan 15, 2009 at 2:58 AM, Jan Bednařík  wrote:
> this is happening, because Django ORM is not working as what you
> expect from ORM.
>
> In real ORM, this:

No... I don't think you mean "real ORM", I think you mean
"identity-mapping ORM". Those terms are not the same.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

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

Re: Problem with ORM

[Jan Bednařík]

On Wed, Jan 14, 2009 at 6:51 PM, Sebastian Bauer  wrote:
>
> Hi
>
> I think it's a bug, but maybe im wrong:
>
>
> print Categories.objects.count()
>  >>0
> new_obj = Categories.objects.create(name="test")
> instance_1  = Categories.objects.get(pk=new_obj.pk)
> instance_2 = Categories.objects.get(pk=new_obj.pk)
>
> instance_1.delete()
> print Kategorie.objects.count()
>  >>0
> instance_2.save()
> print Kategorie.objects.count()
>  >>1
>
> how orm can save second instance of the same row when its deleted?
>
> i have 2 options to solve this problem:
>
> 1. create method of Model instance to check if row exists and let users
> to handle it by own
> or
> 2. throw exception ex. models.DoesNotExist
>
> what you think about this problem?

Hi,

this is happening, because Django ORM is not working as what you
expect from ORM.

In real ORM, this:

instance_1 = Categories.objects.get(pk=new_obj.pk)
instance_2 = Categories.objects.get(pk=new_obj.pk)

will make only one instance with two pointers on it.

This features are in progress, see
http://code.djangoproject.com/wiki/DjangoSpecifications/Core/SingleInstance
and we can hope, that they will be finished soon.

Jan

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

Re: Problem with ORM

[Karen Tracey]

On Wed, Jan 14, 2009 at 12:51 PM, Sebastian Bauer wrote:

>
> Hi
>
> I think it's a bug, but maybe im wrong:
>
>
> print Categories.objects.count()
>  >>0
> new_obj = Categories.objects.create(name="test")
> instance_1  = Categories.objects.get(pk=new_obj.pk)
> instance_2 = Categories.objects.get(pk=new_obj.pk)
>
> instance_1.delete()
> print Kategorie.objects.count()
>  >>0
> instance_2.save()
> print Kategorie.objects.count()
>  >>1
>
> how orm can save second instance of the same row when its deleted?
>
> i have 2 options to solve this problem:
>
> 1. create method of Model instance to check if row exists and let users
> to handle it by own
> or
> 2. throw exception ex. models.DoesNotExist
>
> what you think about this problem?
>

If you want to make sure a save() only updates an existing row and never
inserts a new row, pass in force_update=True on the save:

http://docs.djangoproject.com/en/dev/ref/models/instances/#forcing-an-insert-or-update

Karen

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

Re: Problem with ORM

[Collin Grady]

On Wed, Jan 14, 2009 at 9:51 AM, Sebastian Bauer  wrote:
> how orm can save second instance of the same row when its deleted?

Deleting an object won't magically remove all references to it - the
instance_2 variable still has a perfectly valid object, so saving it
just reinserts a new copy of it.

This is not a bug, as everything is working as intended :)

-- 
Collin Grady

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

Re: Problem while writing new backend support

[Ramiro Morales]

On Mon, Jan 5, 2009 at 11:08 AM, Ambrish Bhargava
 wrote:
>
> Hi Ian,
>
> I have created new CustomQueryClass to over ride as_sql function and
> got LIMIT/OFFSET problem solved. But at the same time I am getting
> PicklingError.
>
> PicklingError: Can't pickle  'django.db.backends.db2.operations.DB2QueryClass'>: it's not found as
> django.db.backends.db2.operations.DB2QueryClass

You will need to implement something similar to what Malcolm has done
in [1]r9272.

In django-pyodbc we  did it at [2]r9 (just with a slight variation).

HTH,

-- 
 Ramiro Morales

1. http://code.djangoproject.com/changeset/9272
2. http://code.google.com/p/django-pyodbc/source/detail?r=92

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