Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Peter Melvyn]

On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:

>  (2) provide a way to manually disable and re-enable integrity checks. If
>  someone with more MySQL-fu than me knows how to do either of these

It should work:

SET FOREIGN_KEY_CHECKS = 0;

... imported data ...

mysql> SET FOREIGN_KEY_CHECKS = 1;

###

Cite: This allows you to import the tables in any order if the dump
file contains tables that are not correctly ordered for foreign keys.
It also speeds up the import operation. Setting FOREIGN_KEY_CHECKS to
0 can also be useful for ignoring foreign key constraints during LOAD
DATA and ALTER TABLE operations. However, even if
FOREIGN_KEY_CHECKS=0, InnoDB does not allow the creation of a foreign
key constraint where a column references a non-matching column type.

Peter

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Russell Keith-Magee]

On Thu, Jun 19, 2008 at 9:04 PM, Peter Melvyn <[EMAIL PROTECTED]> wrote:
>
> On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
>>  (2) provide a way to manually disable and re-enable integrity checks. If
>>  someone with more MySQL-fu than me knows how to do either of these
>
> It should work:
>
> SET FOREIGN_KEY_CHECKS = 0;

Yes - the ticket for this problem (#3615) already has a patch that
uses this technique.

However, I was under the impression that this has the effect of
disabling, not just deferring key checks - that is, if you disable
checks, load bad data, then re-enable checks, no errors will be
raised. We don't want to be responsible for breaking the referential
integrity of a database, so this isn't a viable solution.

If I've misunderstood the behaviour of SET FOREIGN_KEY_CHECKS, or you
have any other suggestions, let me know - I'd very much like to put
this bug behind us.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Michael Glassford]

Russell Keith-Magee wrote:
> On Thu, Jun 19, 2008 at 3:44 AM, Michael Glassford <[EMAIL PROTECTED]> wrote:
> 
>>> from what that says I'd guess you are using the InnoDB MySQL storage 
>>> backend,
>> Right you are. That limitation is a bit of a pain.
> 
> Yes, it is. Unfortunately, the best way to fix this is for MySQL to
> either (1) implement transaction level key integrity checks, or (2)
> provide a way to manually disable and re-enable integrity checks. If
> someone with more MySQL-fu than me knows how to do either of these
> things, let me know and we can put this bug to bed.

Maybe I'm missing something, but isn't the SET FOREIGN_KEY_CHECKS = 0 
used by http://code.djangoproject.com/ticket/3615, which you mentioned 
in another message in the django.user list earlier today, the same as 
#2? Or is there some problem with that statement that makes it unsuitable?

> There is one thing _we_ could do - drop all the constraints before
> loading a fixture, then re-create the constraints after loading the
> fixture. However, this would require a lot of work to implement. I'm
> not particularly interested in doing this work myself (it's an itch I
> just don't have), but if someone else wants to take the lead, they
> would be warmly received.
> 
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Russell Keith-Magee]

On Thu, Jun 19, 2008 at 9:23 PM, Michael Glassford <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee wrote:
>> Yes, it is. Unfortunately, the best way to fix this is for MySQL to
>> either (1) implement transaction level key integrity checks, or (2)
>> provide a way to manually disable and re-enable integrity checks. If
>> someone with more MySQL-fu than me knows how to do either of these
>> things, let me know and we can put this bug to bed.
>
> Maybe I'm missing something, but isn't the SET FOREIGN_KEY_CHECKS = 0
> used by http://code.djangoproject.com/ticket/3615, which you mentioned
> in another message in the django.user list earlier today, the same as
> #2? Or is there some problem with that statement that makes it unsuitable?

Our replies appear to have crossed in the mail - I just responded to
this exact point in a message to Peter Melvyn.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Peter Melvyn]

On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:

>  However, I was under the impression that this has the effect of
>  disabling, not just deferring key checks - that is, if you disable
>  checks, load bad data, then re-enable checks, no errors will be
>  raised. We don't want to be responsible for breaking the referential
>  integrity of a database, so this isn't a viable solution.

Yes, you are right. Cite:

Deviation from SQL standards: Like MySQL in general, in an SQL
statement that inserts, deletes, or updates many rows, InnoDB checks
UNIQUE and FOREIGN KEY constraints row-by-row. According to the SQL
standard, the default behavior should be deferred checking. That is,
constraints are only checked after the entire SQL statement has been
processed. Until InnoDB implements deferred constraint checking, some
things will be impossible, such as deleting a record that refers to
itself via a foreign key.

Peter

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Karen Tracey]

On Thu, Jun 19, 2008 at 9:21 AM, Russell Keith-Magee <[EMAIL PROTECTED]>
wrote:

>
> On Thu, Jun 19, 2008 at 9:04 PM, Peter Melvyn <[EMAIL PROTECTED]>
> wrote:
> >
> > On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> >
> >>  (2) provide a way to manually disable and re-enable integrity checks.
> If
> >>  someone with more MySQL-fu than me knows how to do either of these
> >
> > It should work:
> >
> > SET FOREIGN_KEY_CHECKS = 0;
>
> Yes - the ticket for this problem (#3615) already has a patch that
> uses this technique.
>
> However, I was under the impression that this has the effect of
> disabling, not just deferring key checks - that is, if you disable
> checks, load bad data, then re-enable checks, no errors will be
> raised. We don't want to be responsible for breaking the referential
> integrity of a database, so this isn't a viable solution.
>
> If I've misunderstood the behaviour of SET FOREIGN_KEY_CHECKS, or you
> have any other suggestions, let me know - I'd very much like to put
> this bug behind us.
>

You are correct about how SET FOREIGN_KEY_CHECKS works, there is a note in
the doc (http://dev.mysql.com/doc/refman/5.0/en/set-option.html) that
mentions this:

Setting FOREIGN_KEY_CHECKS to 1 does not trigger a scan of the existing
table data. Therefore, rows added to the table while
FOREIGN_KEY_CHECKS=0will not be verified for consistency.
Here's a tool I found that checks for violated foreign key constraints that
may have been introduced while FOREIGN_KEY_CHECKS was set to 0:

http://forge.mysql.com/tools/tool.php?id=11

Maybe someone could take a look at that and get some ideas about beefing up
the patch for #3615 to include a foreign key check/scan after re-enabling
the checking.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Errors in django/tests/regressiontests/model_inheritance_regress/models.py

[Michael Glassford]

I'm still trying to run the Django unit tests for the first time. I've 
worked through most of the errors--all of them so far proved to be 
caused by the MySQL/InnoDB ordering problem when deserializing objects 
that I asked about in another thread. However, I have one more set of 
errors that appear to have a different cause: it appears that, at least 
when fetching values using Model.objects.values(), a BooleanField isn't 
converting the value 1 to True. Is this a familiar problem? Hopefully it 
won't be another MySQL limitation!

The errors are below:


> $ python runtests.py --settings=django_regression_settings 
> model_inheritance_regress
> ==
> FAIL: Doctest: 
> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
> --
> Traceback (most recent call last):
>   File 
> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/test/_doctest.py",
>  line 2180, in runTest
> raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for 
> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>   File 
> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
> line unknown line number, in API_TESTS
> 
> --
> File 
> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
> line ?, in regressiontests.model_inheritance_regress.models.__test__.API_TESTS
> Failed example:
> [sorted(d.items()) for d in dicts]
> Expected:
> [[('name', u"Guido's House of Pasta"), ('serves_hot_dogs', True)]]
> Got:
> [[('name', u"Guido's House of Pasta"), ('serves_hot_dogs', 1)]]
> --
> File 
> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
> line ?, in regressiontests.model_inheritance_regress.models.__test__.API_TESTS
> Failed example:
> [sorted(d.items()) for d in dicts]
> Expected:
> [[('name', u"Guido's House of Pasta"), ('serves_gnocchi', True), 
> ('serves_hot_dogs', True)]]
> Got:
> [[('name', u"Guido's House of Pasta"), ('serves_gnocchi', 1), 
> ('serves_hot_dogs', 1)]]
> --
> File 
> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
> line ?, in regressiontests.model_inheritance_regress.models.__test__.API_TESTS
> Failed example:
> [sorted(d.items()) for d in dicts]
> Expected:
> [[('name', u"Guido's All New House of Pasta"), ('serves_hot_dogs', 
> False)]]
> Got:
> [[('name', u"Guido's All New House of Pasta"), ('serves_hot_dogs', 0)]]
> --
> File 
> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
> line ?, in regressiontests.model_inheritance_regress.models.__test__.API_TESTS
> Failed example:
> [sorted(d.items()) for d in dicts]
> Expected:
> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', False), 
> ('serves_hot_dogs', False)]]
> Got:
> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 0), 
> ('serves_hot_dogs', 0)]]
> --
> File 
> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
> line ?, in regressiontests.model_inheritance_regress.models.__test__.API_TESTS
> Failed example:
> [sorted(d.items()) for d in dicts]
> Expected:
> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', False), 
> ('serves_hot_dogs', False)]]
> Got:
> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 0), 
> ('serves_hot_dogs', 0)]]
> 
> 
> --
> Ran 1 test in 0.057s


Mike


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Steve Holden]

Russell Keith-Magee wrote:
> On Thu, Jun 19, 2008 at 9:04 PM, Peter Melvyn <[EMAIL PROTECTED]> wrote:
>   
>> On 6/19/08, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>>
>> 
>>>  (2) provide a way to manually disable and re-enable integrity checks. If
>>>  someone with more MySQL-fu than me knows how to do either of these
>>>   
>> It should work:
>>
>> SET FOREIGN_KEY_CHECKS = 0;
>> 
>
> Yes - the ticket for this problem (#3615) already has a patch that
> uses this technique.
>
> However, I was under the impression that this has the effect of
> disabling, not just deferring key checks - that is, if you disable
> checks, load bad data, then re-enable checks, no errors will be
> raised. We don't want to be responsible for breaking the referential
> integrity of a database, so this isn't a viable solution.
>
> If I've misunderstood the behaviour of SET FOREIGN_KEY_CHECKS, or you
> have any other suggestions, let me know - I'd very much like to put
> this bug behind us.
>   
Well I guess the obvious (time consuming, painful) way would be to 
validate the semantic integrity from Django in the back end. That could, 
if automated, get horrendously time-consuming for even quite small 
changes to the database.

Would there be any way to analyze which constraints could be affected by 
the SQL executed while checks were disabled, so automated checks could 
be limited to those?

Otherwise I'd guess you end up saying "Tough, MySQL is currently 
broken/less capable". Maybe we could talk to Ted Leung about that?

regards
 Steve


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/model_inheritance_regress/models.py

[Karen Tracey]

On Thu, Jun 19, 2008 at 9:57 AM, Michael Glassford <[EMAIL PROTECTED]>
wrote:

>
> I'm still trying to run the Django unit tests for the first time. I've
> worked through most of the errors--all of them so far proved to be
> caused by the MySQL/InnoDB ordering problem when deserializing objects
> that I asked about in another thread. However, I have one more set of
> errors that appear to have a different cause: it appears that, at least
> when fetching values using Model.objects.values(), a BooleanField isn't
> converting the value 1 to True. Is this a familiar problem? Hopefully it
> won't be another MySQL limitation!
>

It is:

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

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Introducing ModelView, a RESTful class-based view of your resources

[tifosi]

Hi David,

Thank for your code and the repository, I use the django-rest-interface and
it's good news, that someone continue the job.

I would like to get nested resources (e.g.: /articles/1/comments/ or
/user/username/jobs/) and the problem is that you have to pass statically
the queryset. I think I can use a decorator but I don't know how I can do
this. Do you have a suggestion?

Regards

Clément

(Sorry for my English, I'm French)

-- 
View this message in context: 
http://www.nabble.com/Introducing-ModelView%2C-a-RESTful-class-based-view-of-your-resources-tp17718460p18009510.html
Sent from the django-developers mailing list archive at Nabble.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-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/model_inheritance_regress/models.py

[Pim Van Heuven]

Hi Michael,

Can you apply this patch and run the tests again?
I have been running Django with this patch for a long time but never
got around to submitting it.

Pim.



Michael Glassford wrote:
> I'm still trying to run the Django unit tests for the first time. I've 
> worked through most of the errors--all of them so far proved to be 
> caused by the MySQL/InnoDB ordering problem when deserializing objects 
> that I asked about in another thread. However, I have one more set of 
> errors that appear to have a different cause: it appears that, at least 
> when fetching values using Model.objects.values(), a BooleanField isn't 
> converting the value 1 to True. Is this a familiar problem? Hopefully it 
> won't be another MySQL limitation!
>
> The errors are below:
>
>
>   
>> $ python runtests.py --settings=django_regression_settings 
>> model_inheritance_regress
>> ==
>> FAIL: Doctest: 
>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>> --
>> Traceback (most recent call last):
>>   File 
>> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/test/_doctest.py",
>>  line 2180, in runTest
>> raise self.failureException(self.format_failure(new.getvalue()))
>> AssertionError: Failed doctest test for 
>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>>   File 
>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
>> line unknown line number, in API_TESTS
>>
>> --
>> File 
>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
>> line ?, in 
>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>> Failed example:
>> [sorted(d.items()) for d in dicts]
>> Expected:
>> [[('name', u"Guido's House of Pasta"), ('serves_hot_dogs', True)]]
>> Got:
>> [[('name', u"Guido's House of Pasta"), ('serves_hot_dogs', 1)]]
>> --
>> File 
>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
>> line ?, in 
>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>> Failed example:
>> [sorted(d.items()) for d in dicts]
>> Expected:
>> [[('name', u"Guido's House of Pasta"), ('serves_gnocchi', True), 
>> ('serves_hot_dogs', True)]]
>> Got:
>> [[('name', u"Guido's House of Pasta"), ('serves_gnocchi', 1), 
>> ('serves_hot_dogs', 1)]]
>> --
>> File 
>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
>> line ?, in 
>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>> Failed example:
>> [sorted(d.items()) for d in dicts]
>> Expected:
>> [[('name', u"Guido's All New House of Pasta"), ('serves_hot_dogs', 
>> False)]]
>> Got:
>> [[('name', u"Guido's All New House of Pasta"), ('serves_hot_dogs', 0)]]
>> --
>> File 
>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
>> line ?, in 
>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>> Failed example:
>> [sorted(d.items()) for d in dicts]
>> Expected:
>> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 
>> False), ('serves_hot_dogs', False)]]
>> Got:
>> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 0), 
>> ('serves_hot_dogs', 0)]]
>> --
>> File 
>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py", 
>> line ?, in 
>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>> Failed example:
>> [sorted(d.items()) for d in dicts]
>> Expected:
>> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 
>> False), ('serves_hot_dogs', False)]]
>> Got:
>> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 0), 
>> ('serves_hot_dogs', 0)]]
>>
>>
>> --
>> Ran 1 test in 0.057s
>> 
>
>
> Mike
>
>
> >
>
>   


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

diff -ur -x.svn -x.mo -x'*.pyc' /home/pim/software/newforms/newforms-admin-7684/django/db/backends/mysql/base.py django/db/backends/mysql/base.py
--- /home/pim/software/newforms/newfor

Re: Errors in django/tests/regressiontests/model_inheritance_regress/models.py

[Michael Glassford]

Your patch works, thanks. Perhaps you could add it to 
http://code.djangoproject.com/ticket/7190; I tried the patch there, but 
it doesn't work in this case.

Mike


Pim Van Heuven wrote:
> Hi Michael,
> 
> Can you apply this patch and run the tests again?
> I have been running Django with this patch for a long time but never
> got around to submitting it.
> 
> Pim.
> 
> 
> 
> Michael Glassford wrote:
>> I'm still trying to run the Django unit tests for the first time. I've 
>> worked through most of the errors--all of them so far proved to be 
>> caused by the MySQL/InnoDB ordering problem when deserializing objects 
>> that I asked about in another thread. However, I have one more set of 
>> errors that appear to have a different cause: it appears that, at least 
>> when fetching values using Model.objects.values(), a BooleanField isn't 
>> converting the value 1 to True. Is this a familiar problem? Hopefully it 
>> won't be another MySQL limitation!
>>
>> The errors are below:
>>
>>
>>   
>>> $ python runtests.py --settings=django_regression_settings 
>>> model_inheritance_regress
>>> ==
>>> FAIL: Doctest: 
>>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>>> --
>>> Traceback (most recent call last):
>>>   File 
>>> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/test/_doctest.py",
>>>  line 2180, in runTest
>>> raise self.failureException(self.format_failure(new.getvalue()))
>>> AssertionError: Failed doctest test for 
>>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>>>   File 
>>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
>>>  line unknown line number, in API_TESTS
>>>
>>> --
>>> File 
>>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
>>>  line ?, in 
>>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>>> Failed example:
>>> [sorted(d.items()) for d in dicts]
>>> Expected:
>>> [[('name', u"Guido's House of Pasta"), ('serves_hot_dogs', True)]]
>>> Got:
>>> [[('name', u"Guido's House of Pasta"), ('serves_hot_dogs', 1)]]
>>> --
>>> File 
>>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
>>>  line ?, in 
>>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>>> Failed example:
>>> [sorted(d.items()) for d in dicts]
>>> Expected:
>>> [[('name', u"Guido's House of Pasta"), ('serves_gnocchi', True), 
>>> ('serves_hot_dogs', True)]]
>>> Got:
>>> [[('name', u"Guido's House of Pasta"), ('serves_gnocchi', 1), 
>>> ('serves_hot_dogs', 1)]]
>>> --
>>> File 
>>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
>>>  line ?, in 
>>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>>> Failed example:
>>> [sorted(d.items()) for d in dicts]
>>> Expected:
>>> [[('name', u"Guido's All New House of Pasta"), ('serves_hot_dogs', 
>>> False)]]
>>> Got:
>>> [[('name', u"Guido's All New House of Pasta"), ('serves_hot_dogs', 0)]]
>>> --
>>> File 
>>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
>>>  line ?, in 
>>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>>> Failed example:
>>> [sorted(d.items()) for d in dicts]
>>> Expected:
>>> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 
>>> False), ('serves_hot_dogs', False)]]
>>> Got:
>>> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 0), 
>>> ('serves_hot_dogs', 0)]]
>>> --
>>> File 
>>> "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
>>>  line ?, in 
>>> regressiontests.model_inheritance_regress.models.__test__.API_TESTS
>>> Failed example:
>>> [sorted(d.items()) for d in dicts]
>>> Expected:
>>> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 
>>> False), ('serves_hot_dogs', False)]]
>>> Got:
>>> [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 0), 
>>> ('serves_hot_dogs', 0)]]
>>>
>>>
>>> --
>>> Ran 1 test in 0.057s
>>> 
>>
>>
>> Mike
>>
>>
>>
>>
>>   
> 
> 
> > 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more

Support for ON DELETE and ON UPDATE in foreign keys

[Michael Glassford]

Now for one of the reasons that I've been trying to get the Django unit 
tests running: I'm interested in submitting a patch that adds some ON 
DELETE and ON UPDATE support in Django. But first, I want to see what 
interest there is in such a patch. There have been a number of tickets 
about this over the years, but none that I've seen uses this approach. 
For instance:

http://code.djangoproject.com/ticket/28 (closed: duplicate)

http://code.djangoproject.com/ticket/1007 (closed: duplicate)

http://code.djangoproject.com/ticket/2288 (closed: won't fix)

http://code.djangoproject.com/ticket/6108 (new)




Below is an outline of what the patch currently does and what I would 
need to add if there is interest in using it.

* The patch adds on_delete and on_update keyword parameters to 
ForeignKey.__init__.

* Usage looks like this:

 from django.db import models

 class ModelA(models.Model):
 id = models.PositiveIntegerField(primary_key=True)

 class ModelB(models.Model):
 partner = models.ForeignKey(
 ModelA,
 on_delete=models.CASCADE,
 on_update=models.CASCADE
 )

* If settings.DATABASE_HANDLES_ON_DELETE=True, the SQL that is generated 
by manage.py contains ON DELETE clauses where on_delete= is 
specified.

* If settings.DATABASE_HANDLES_ON_UPDATE=True, the SQL that is generated 
by manage.py contains ON UPDATE clauses where on_update= is 
specified.

* The possible values that can be passed for the on_delete and on_update 
parameters are None, RESTRICT, CASCADE, and SET_NULL.

* If settings.DATABASE_HANDLES_ON_DELETE=False, I hope to modify 
Django's code that currently automatically deletes related objects to 
respect the values specified by the on_delete parameter. This is one of 
the things I will probably postpone until I see if there is sufficient 
interest.

* Another thing I need to do is to add Django unit test for the new 
behavior. This is why I've been trying to get the unit tests running.




Mike



--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

[Jason Davies]

Hello,

We have a reasonably high-traffic site, which started intermittently
throwing "ValueError: generator already executing" errors under high
load.  This started happening after updating to a more recent trunk
revision (r7601).

After much digging around, it seems there is a race condition in
ModelChoiceIterator.  See ticket #7475 [1] for a patch and more
details.

I'm not sure there's good way to add a regression test for something
like this, any comments would be appreciated.

Cheers,

Jason

[1]: http://code.djangoproject.com/ticket/7475
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/views/fixtures/testdata.json?

[Jason Davies]

On Jun 19, 3:04 pm, Steve Holden <[EMAIL PROTECTED]> wrote:

> Well I guess the obvious (time consuming, painful) way would be to
> validate the semantic integrity from Django in the back end. That could,
> if automated, get horrendously time-consuming for even quite small
> changes to the database.
>
> Would there be any way to analyze which constraints could be affected by
> the SQL executed while checks were disabled, so automated checks could
> be limited to those?

I'd be in favour of doing something like this, even if it was slow.
After all, slow is better than it not working at all!

Jason
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Support for ON DELETE and ON UPDATE in foreign keys

[Marc Fargas]

El jue, 19-06-2008 a las 11:00 -0400, Michael Glassford escribió:
> * If settings.DATABASE_HANDLES_ON_DELETE=True, the SQL that is generated 
> by manage.py contains ON DELETE clauses where on_delete= is 
> specified.
> 
> * If settings.DATABASE_HANDLES_ON_UPDATE=True, the SQL that is generated 
> by manage.py contains ON UPDATE clauses where on_update= is 
> specified.

That information should be provided by the backend, not in the settings
file (which are supposed to be backend independent).



signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

FREE International Calls sign up free!!!

[dennis greenpard]

FREE International Calls sign up free!!!
Lowest rates, highest quality calls to and from any number in the world
http://www.attphone.co.cc/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Secret Dating Tips !!!

[dennis greenpard]

Secret Dating Tips !!!
http://www.webdatingtips.co.cc/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Experimental Git repository available

[Jacob Kaplan-Moss]

Hi folks --

I've published an experimental Git clone of Django's SVN repository
(created with git-svn). If you're a Git user and want to use this
repository, be my guest. Please still upload patches to Trac for
review, but mention you're using my clone so I can more easily apply
patches from you. Also let me know if you publish your clones
anywhere; I'll add 'em as remotes.

Note that this is in no way official, this is just me fooling around
with new tech. It's entirely possible that this won't actually save
anyone any time, but since I'm fooling with Git I thought I'd give
this a shot. Please don't try to turn this into a "Django should use
Git!" thread; if you do I'll just ignore you. We're not switching from
SVN any time in the foreseeable future.

OK, so the details:

Repository: git://djangoproject.com/django
Gitweb: http://code.djangoproject.com/git/?p=django

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

[Jacob Kaplan-Moss]

On Thu, Jun 19, 2008 at 10:04 AM, Jason Davies <[EMAIL PROTECTED]> wrote:
> After much digging around, it seems there is a race condition in
> ModelChoiceIterator.  See ticket #7475 [1] for a patch and more
> details.

While the patch looks good, as a general principle you should assume
that if your patch contains the phrase "# TODO:", it's not ready for
prime-time.

[Yes, I know there are some places in Django that have TODOs marked.
They shouldn't be there, either.]

Can you clarify what you mean with that TODO? If you can explain to me
what you mean, I might help you DO it :)

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[[EMAIL PROTECTED]]

Is this only going to offer the trunk branch?

On Jun 19, 11:39 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi folks --
>
> I've published an experimental Git clone of Django's SVN repository
> (created with git-svn). If you're a Git user and want to use this
> repository, be my guest. Please still upload patches to Trac for
> review, but mention you're using my clone so I can more easily apply
> patches from you. Also let me know if you publish your clones
> anywhere; I'll add 'em as remotes.
>
> Note that this is in no way official, this is just me fooling around
> with new tech. It's entirely possible that this won't actually save
> anyone any time, but since I'm fooling with Git I thought I'd give
> this a shot. Please don't try to turn this into a "Django should use
> Git!" thread; if you do I'll just ignore you. We're not switching from
> SVN any time in the foreseeable future.
>
> OK, so the details:
>
> Repository: git://djangoproject.com/django
> Gitweb:http://code.djangoproject.com/git/?p=django
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Support for ON DELETE and ON UPDATE in foreign keys

[Michael Glassford]

Marc Fargas wrote:
> El jue, 19-06-2008 a las 11:00 -0400, Michael Glassford escribió:
>> * If settings.DATABASE_HANDLES_ON_DELETE=True, the SQL that is generated 
>> by manage.py contains ON DELETE clauses where on_delete= is 
>> specified.
>>
>> * If settings.DATABASE_HANDLES_ON_UPDATE=True, the SQL that is generated 
>> by manage.py contains ON UPDATE clauses where on_update= is 
>> specified.
> 
> That information should be provided by the backend, not in the settings
> file (which are supposed to be backend independent).
> 

That's what I did originally (in the code that we're using on our 
servers), but for the patch I decided against it because:

a) Settings files aren't really entirely back-end independent: they 
specify what backend to use in settings.DATABASE_ENGINE.

b) With MySQL, the ON UPDATE and ON DELETE clauses are supported on some 
table types and not on others, so just querying the backend isn't good 
enough. If there's a way to query what table type a model will use in 
MySQL (I don't think there is in Django 0.96, which is what we're 
using), I would need to do that.

c) Even for databases with full support, some users will want to use the 
new feature and others will not (for backward compatibility, if for no 
other reason), so there should probably be a way to turn it off even if 
it defaults to on for databases that support it.

However, I'm willing to do whatever consensus recommends.


Mike


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

[[EMAIL PROTECTED]]

It seems to me you can just do:
if self.field.cache_choices:
qs = self.queryset
else:
qs = self.queryset.all()
for obj in qs:
   

On Jun 19, 10:04 am, Jason Davies <[EMAIL PROTECTED]> wrote:
> Hello,
>
> We have a reasonably high-traffic site, which started intermittently
> throwing "ValueError: generator already executing" errors under high
> load.  This started happening after updating to a more recent trunk
> revision (r7601).
>
> After much digging around, it seems there is a race condition in
> ModelChoiceIterator.  See ticket #7475 [1] for a patch and more
> details.
>
> I'm not sure there's good way to add a regression test for something
> like this, any comments would be appreciated.
>
> Cheers,
>
> Jason
>
> [1]:http://code.djangoproject.com/ticket/7475
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Ben Ford]

Hi Jacob,

This sounds like a nice idea... Any plans to do a mercurial repo (a-la the
documentation refactor)? Am I right in thinking that support of SVN <=> HG
is less complete than GIT <=> SVN?

Cheers,
Ben

2008/6/19 [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

>
> Is this only going to offer the trunk branch?
>
> On Jun 19, 11:39 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
> wrote:
> > Hi folks --
> >
> > I've published an experimental Git clone of Django's SVN repository
> > (created with git-svn). If you're a Git user and want to use this
> > repository, be my guest. Please still upload patches to Trac for
> > review, but mention you're using my clone so I can more easily apply
> > patches from you. Also let me know if you publish your clones
> > anywhere; I'll add 'em as remotes.
> >
> > Note that this is in no way official, this is just me fooling around
> > with new tech. It's entirely possible that this won't actually save
> > anyone any time, but since I'm fooling with Git I thought I'd give
> > this a shot. Please don't try to turn this into a "Django should use
> > Git!" thread; if you do I'll just ignore you. We're not switching from
> > SVN any time in the foreseeable future.
> >
> > OK, so the details:
> >
> > Repository: git://djangoproject.com/django
> > Gitweb:http://code.djangoproject.com/git/?p=django
> >
> > Jacob
> >
>


-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+447792598685

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Ariel Mauricio Nunez Gomez]

Something like this?
http://hg.dpaste.com/django/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Jacob Kaplan-Moss]

On Thu, Jun 19, 2008 at 11:55 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Is this only going to offer the trunk branch?

Until I learn more about Git, yes :)

If you know the correct incantation to add other git-svn-created
branches, feel free to school me :)

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Jacob Kaplan-Moss]

On Thu, Jun 19, 2008 at 11:59 AM, Ben Ford <[EMAIL PROTECTED]> wrote:
> This sounds like a nice idea... Any plans to do a mercurial repo (a-la the
> documentation refactor)? Am I right in thinking that support of SVN <=> HG
> is less complete than GIT <=> SVN?

Yeah, hgsvn is one-way, which git-svn has the "dcommit" command
which'll commit back to SVN. I'm really not much of a git fan, but
git-svn makes a better svn than svn does, if you know what I mean.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Tom Tobin]

On Thu, Jun 19, 2008 at 11:39 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> I've published an experimental Git clone of Django's SVN repository
> (created with git-svn). If you're a Git user and want to use this
> repository, be my guest. Please still upload patches to Trac for
> review, but mention you're using my clone so I can more easily apply
> patches from you. Also let me know if you publish your clones
> anywhere; I'll add 'em as remotes.

Noted this on the appropriate wiki page (and cleaned up the section on
DVCS mirrors):

http://code.djangoproject.com/wiki/DjangoBranches

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Alexander Solovyov]

On Thu, Jun 19, 2008 at 8:09 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 19, 2008 at 11:59 AM, Ben Ford <[EMAIL PROTECTED]> wrote:
>> This sounds like a nice idea... Any plans to do a mercurial repo (a-la the
>> documentation refactor)? Am I right in thinking that support of SVN <=> HG
>> is less complete than GIT <=> SVN?
>
> Yeah, hgsvn is one-way,

H

>hg help convert
hg convert [OPTION]... SOURCE [DEST [REVMAP]]

Convert a foreign SCM repository to a Mercurial one.
...
Accepted destination formats:
- Mercurial
- Subversion (history on branches is not preserved)

That's hg 1.0.1

-- 
Alexander

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[dankelley]

You're a gentleman and a scholar, Jacob.

I think you'll find that git is a tool that feels good in the hand.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Waylan Limberg]

On Thu, Jun 19, 2008 at 1:52 PM, Alexander Solovyov
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 19, 2008 at 8:09 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
>> Yeah, hgsvn is one-way,
>
> H
>
>>hg help convert
> hg convert [OPTION]... SOURCE [DEST [REVMAP]]
>
> Convert a foreign SCM repository to a Mercurial one.

True, but that doesn't address pushing changes back to SVN, at least
not practically. Mercurial's own docs [1] admit this is a problem
needing improvement. Compare that with git-svn's dcommit command [2].

[1]: 
http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion#head-15564b76f3172721218d34c912aa0c31e156a94b
[2]: http://www.kernel.org/pub/software/scm/git/docs/git-svn.html


-- 

Waylan Limberg
[EMAIL PROTECTED]

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: List of DDN Tickets

[Collin Grady]

Can I recommend http://code.djangoproject.com/ticket/4102 for the list? :)

-- 
Collin Grady

Bumper sticker:
All the parts falling off this car are of the very finest
British manufacture.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Jeremy Dunck]

I'm just guessing, but I think git-clone doesn't pull in remotes, so
that our clones are getting whatever's your master, hence trunk.
You can make a local copy of a remote branch like so:

git-checkout -b local/branchname branchname

There's no magic in the "local" prefix, it's just to distinguish the
remote branch of the same name.

Plus
 git-update-server-info
may be needed...

On Thu, Jun 19, 2008 at 12:07 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 19, 2008 at 11:55 AM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Is this only going to offer the trunk branch?
>
> Until I learn more about Git, yes :)
>
> If you know the correct incantation to add other git-svn-created
> branches, feel free to school me :)
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Errors in django/tests/regressiontests/model_inheritance_regress/models.py

[Pim Van Heuven]

The lack of boolean type coercion is more serious than it looks like at 
first glance.
(starting from the example at http://code.djangoproject.com/ticket/7190)

In [1]: import django.newforms as forms
In [2]: from django.newforms.models import model_to_dict
In [3]: from simple.models import Simple
In [4]: simple_false = Simple.objects.create(b=False)
In [5]: simple_false_2 = Simple.objects.get(pk=simple_false.pk)

In [6]: class SimpleForm(forms.ModelForm):
   ...: b = forms.BooleanField(widget=forms.HiddenInput)
   ...: class Meta:
   ...: model = Simple
   ...:

In [7]: SimpleForm(data = model_to_dict(simple_false)).as_p()
Out[7]: u''

In [8]: SimpleForm(data = model_to_dict(simple_false_2)).as_p()
Out[8]: u''

When you POST the Out[8] form the value becomes bool("0") = True.
So when you save simple_false_2 based on the form the value is inverted 
from False
to True.
Seems like a critical error...

The mysql.patch solves this issue too.


Pim.


Michael Glassford wrote:
> Your patch works, thanks. Perhaps you could add it to 
> http://code.djangoproject.com/ticket/7190; I tried the patch there, but 
> it doesn't work in this case.
>
> Mike
>
>
> Pim Van Heuven wrote:
>   
>> Hi Michael,
>>
>> Can you apply this patch and run the tests again?
>> I have been running Django with this patch for a long time but never
>> got around to submitting it.
>>
>> Pim.
>>
>>
>>
>> Michael Glassford wrote:
>> 
>>> I'm still trying to run the Django unit tests for the first time. I've 
>>> worked through most of the errors--all of them so far proved to be 
>>> caused by the MySQL/InnoDB ordering problem when deserializing objects 
>>> that I asked about in another thread. However, I have one more set of 
>>> errors that appear to have a different cause: it appears that, at least 
>>> when fetching values using Model.objects.values(), a BooleanField isn't 
>>> converting the value 1 to True. Is this a familiar problem? Hopefully it 
>>> won't be another MySQL limitation!
>>>
>>> The errors are below:
>>>
>>>
>>>   
>>>   
 $ python runtests.py --settings=django_regression_settings 
 model_inheritance_regress
 ==
 FAIL: Doctest: 
 regressiontests.model_inheritance_regress.models.__test__.API_TESTS
 --
 Traceback (most recent call last):
   File 
 "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/test/_doctest.py",
  line 2180, in runTest
 raise self.failureException(self.format_failure(new.getvalue()))
 AssertionError: Failed doctest test for 
 regressiontests.model_inheritance_regress.models.__test__.API_TESTS
   File 
 "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
  line unknown line number, in API_TESTS

 --
 File 
 "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
  line ?, in 
 regressiontests.model_inheritance_regress.models.__test__.API_TESTS
 Failed example:
 [sorted(d.items()) for d in dicts]
 Expected:
 [[('name', u"Guido's House of Pasta"), ('serves_hot_dogs', True)]]
 Got:
 [[('name', u"Guido's House of Pasta"), ('serves_hot_dogs', 1)]]
 --
 File 
 "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
  line ?, in 
 regressiontests.model_inheritance_regress.models.__test__.API_TESTS
 Failed example:
 [sorted(d.items()) for d in dicts]
 Expected:
 [[('name', u"Guido's House of Pasta"), ('serves_gnocchi', True), 
 ('serves_hot_dogs', True)]]
 Got:
 [[('name', u"Guido's House of Pasta"), ('serves_gnocchi', 1), 
 ('serves_hot_dogs', 1)]]
 --
 File 
 "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
  line ?, in 
 regressiontests.model_inheritance_regress.models.__test__.API_TESTS
 Failed example:
 [sorted(d.items()) for d in dicts]
 Expected:
 [[('name', u"Guido's All New House of Pasta"), ('serves_hot_dogs', 
 False)]]
 Got:
 [[('name', u"Guido's All New House of Pasta"), ('serves_hot_dogs', 0)]]
 --
 File 
 "/develop/django/tests/regressiontests/model_inheritance_regress/models.py",
  line ?, in 
 regressiontests.model_inheritance_regress.models.__test__.API_TESTS
 Failed example:
 [sorted(d.items()) for d in dicts]
 Expected:
 [[('name', u"Guido's All New House of Pasta"), ('serves_gnocchi', 
 False), ('serves_hot_dogs', False)]]
 Got:
  

Re: Experimental Git repository available

[Ben Ford]

> Something like this?
> http://hg.dpaste.com/django/ 

Yeah I use that one at the moment, I was getting at a more thing. I'm sure
that's more difficult to do with HG then GIT and like Jacob said, it's a
moot point anyway :-)

Ben

2008/6/19 Ariel Mauricio Nunez Gomez <[EMAIL PROTECTED]>:

>
> 
>
>
> >
>


-- 
Regards,
Ben Ford
[EMAIL PROTECTED]
+447792598685

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

[Jason Davies]

On Jun 19, 5:56 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:

> It seems to me you can just do:
> if self.field.cache_choices:
>     qs = self.queryset
> else:
>     qs = self.queryset.all()
> for obj in qs:
>    

I thought about doing that, but then that would lead to the race
condition again if cache_choices is True.  The other options I can see
are:

1. Utilise Django's cache framework to implement caching of choices
(would need to decide on which cache key to use, and thread-safety
would depend on the cache backend).
2. Utilise simple thread synchronisation mechanisms to control access
to the queryset in question.  This would only need to be done when
cache_choices is True, so in the usual case when it is False there
would be no performance impact.
3. Drop support for cache_choices altogether, as it can be easily
implemented (e.g. using the cache framework) if really necessary.

I feel that #2 is the best choice, what do other people think?

Cheers,

Jason
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Race condition in ModelChoiceIterator (affects ModelChoiceField and ModelMultipleChoiceField)

[Jason Davies]

On Jun 19, 8:49 pm, Jason Davies <[EMAIL PROTECTED]> wrote:

> 2. Utilise simple thread synchronisation mechanisms to control access
> to the queryset in question.  This would only need to be done when
> cache_choices is True, so in the usual case when it is False there
> would be no performance impact.

I found a way to cache the choices without having to use any locks
[1].

Cheers,

Jason

[1]: http://code.djangoproject.com/attachment/ticket/7475/models.3.py.diff
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Michael Elsdörfer]

> Yeah, hgsvn is one-way, which git-svn has the "dcommit" command
> which'll commit back to SVN. I'm really not much of a git fan, but
> git-svn makes a better svn than svn does, if you know what I mean.

FWIW (I'm currently playing around with all three of them), bazaar
appears to support pushing into svn as well.

Michael


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Marc Fargas]

El jue, 19-06-2008 a las 14:03 -0700, Michael Elsdörfer escribió:
> FWIW (I'm currently playing around with all three of them), bazaar
> appears to support pushing into svn as well.

Yes, with bzr-svn. Didn't play too much with that one. But Bazaar is
slow, *really* slow.

-- 
http://www.marcfargas.com -- will be finished some day.


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: Experimental Git repository available

[Tom Tobin]

On Thu, Jun 19, 2008 at 4:27 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> El jue, 19-06-2008 a las 14:03 -0700, Michael Elsdörfer escribió:
>> FWIW (I'm currently playing around with all three of them), bazaar
>> appears to support pushing into svn as well.
>
> Yes, with bzr-svn. Didn't play too much with that one. But Bazaar is
> slow, *really* slow.

I settled on Bazaar after extensively using both Git and Mercurial;
it's *not* that slow, and it keeps getting faster with aggressive
monthly releases.  (But alas, this isn't the right place for DVCS
advocacy.)  ^_^

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: GSOC: More backends for djangosearch

[Ben Firshman]

I'm still in exams unfortunately, so this will be brief, but I'd like  
to hear some thoughts.

Imagine a small site without a great deal of traffic or data, and they  
wish to add search support for a model. Lucene or Xapian are probably  
overkill, and they may not want to invest time into getting it  
running. tsearch2 or MySQL full text indexes seem the obvious  
solution, and I would like to try and implement them, but what about a  
simple built in index that would be backend independent? Much like the  
django-search "simple" backend:

http://code.google.com/p/django-search/source/browse/trunk/search/backends/simple.py

Not that I just want to copy other projects, but it'd would be nice to  
bring together all the best features of all the Django search  
solutions that already exist. It would be ideal if the developers of  
all these projects (django-sphinx in particular seems the most mature)  
would be willing to assist with djangosearch. With their expertise on  
their search backends, we can make it contrib worthy.

Thoughts?

Oh and by the way - by the end of next week I should be able to start  
working. At last!

Ben

On 3 May 2008, at 22:33, Ben Firshman wrote:

>
> Hello all!
>
> A quick introduction: I have been accepted to the GSoC to work on
> Django. I will be working on the djangosearch app 
> (http://code.google.com/p/djangosearch/
> ), in particular adding support for addition search backends, mentored
> by Joseph Kocherhans.
>
> I will spend time getting Lucene and Xapian working well, and I have
> an interest in getting Sphinx working too. The app is lacking
> particularly in documentation, something I hope I can work on too.
>
> Due to exams, I can't begin working properly until mid-June, so all
> the better for getting input from you! I would be very interested in
> hearing what you would like to see from a search application, what
> backends you want/are using and any other comments/suggestions you may
> have.
>
> Thanks!
>
> Ben
>
> >


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Rob Hudson]

On 6/19/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
>  On Thu, Jun 19, 2008 at 11:55 AM, [EMAIL PROTECTED]
>  <[EMAIL PROTECTED]> wrote:
>  > Is this only going to offer the trunk branch?
>
>
> Until I learn more about Git, yes :)
>
>  If you know the correct incantation to add other git-svn-created
>  branches, feel free to school me :)
>
>
>  Jacob

Use the `-T`, `-t`, `-b` flags, or `-s` if the project has a "standard
layout".  This should bring over branches and tags as well.

-Rob
-- 
"ROCK OUT!"  \m/.  .\m/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Rob Hudson]

On 6/19/08, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Use the `-T`, `-t`, `-b` flags, or `-s` if the project has a "standard
>  layout".  This should bring over branches and tags as well.

I forgot to reference the man page (which was in my clipboard):
http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

-Rob

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Jeremy Dunck]

On Thu, Jun 19, 2008 at 5:02 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> On 6/19/08, Rob Hudson <[EMAIL PROTECTED]> wrote:
>> Use the `-T`, `-t`, `-b` flags, or `-s` if the project has a "standard
>>  layout".  This should bring over branches and tags as well.

Oh, er, uh, I didn't notice only trunk was in the published repo-- I
assumed it was a clone problem.

Yeah, what Rob said, except that for sure, django is in the standard
format, so this should work:
 git-svn init -s http://code.djangoproject.com/svn/

But I think that just editing .git/config to add this should work:

[svn-remote "svn"]
   url = http://code.djangoproject.com/svn
   fetch = trunk:refs/remotes/trunk
   branches = branches/*:refs/remotes/*
   tags = tags/*:refs/remotes/tags/*

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Rob Hudson]

On 6/19/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>  Please don't try to turn this into a "Django should use
>  Git!" thread; if you do I'll just ignore you. We're not switching from
>  SVN any time in the foreseeable future.

I hope you are nearsighted and the foreseeable future isn't too distant.  :)



-Rob

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Marc Fargas]

El jue, 19-06-2008 a las 17:14 -0500, Jeremy Dunck escribió:
>  git-svn init -s http://code.djangoproject.com/svn/

git-svn init -s http://code.djangoproject.com/svn/django

Unless you want djangoproject.com also ;)


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: Support for ON DELETE and ON UPDATE in foreign keys

[Russell Keith-Magee]

On Thu, Jun 19, 2008 at 11:00 PM, Michael Glassford
<[EMAIL PROTECTED]> wrote:
>
> Now for one of the reasons that I've been trying to get the Django unit
> tests running: I'm interested in submitting a patch that adds some ON
> DELETE and ON UPDATE support in Django. But first, I want to see what
> interest there is in such a patch.

I'm certainly interested in supporting ON DELETE and ON UPDATE, and
from a surface inspection, you appear to have a reasonable handle on
the topic. I'm not sure if my enthusiasm is shared by the other
developers though. Either way, this would be a big new feature, and it
will require some discussion from the core developers and the rest of
the community.

However, we're currently on a push to get v1.0 out the door, and in
order to get this release out the door, we're deferring discussions on
feature requests that aren't already well established.

I'm not saying you shouldn't work on this - just that you will find it
difficult to get our attention over the next few months. If we want to
get v1.0 out the door, some things have to be sacrificed.

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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Online Career resources study on careerbirds.com

[careerbirds]

20-6-2008 –walkin,IT FRESHER,IT EXP OPENINGS

Online Career resources study on careerbirds.com

  http://www.hotjobseeker.com/
* Oracle Apps Techno Functional Consultant
   http://www.hotjobseeker.com/
 * J2EE TECHNICAL ASSOCIATES AT PROKARMA AT HYDERABAD
http://www.hotjobseeker.com/
* BEA-Weblogic-Application Server Admin
http://www.hotjobseeker.com/
* Datastage Developer -ASAP Infosystems Pvt Ltd
   http://www.hotjobseeker.com/
 * Cognos Developer -ASAP Infosystems Pvt Ltd
http://www.hotjobseeker.com/
* Javascript expert $1600-2600/month, ASP.NET, work remotely at home
   http://www.hotjobseeker.com/
 * Web Developer -Digital Pixel Inc.
   http://www.hotjobseeker.com/
 * My SQL DBA with valid B1 visa (4+ yrs exp)
http://www.hotjobseeker.com/
* AS400 Professionals
http://www.hotjobseeker.com/
* Sr Cognos Professionals
http://www.hotjobseeker.com/
* EAI Developer / EAI Sr.Java Developer - 3 Years to 7 Years
http://www.hotjobseeker.com/
* Oracle,PL/SQL Developers/Consultant
http://www.hotjobseeker.com/
* Sr. PHP Programmers - Immediate Openings
http://www.hotjobseeker.com/
* Oracle Apps -Functional -SCM/HRMS/Financials-Onsite Oppurtunities
http://www.hotjobseeker.com/
* Urgent Opening- Sybase Developers
http://www.hotjobseeker.com/
* Sr. SEO/SEO Executive
http://www.hotjobseeker.com/
* Designers Required at Harbinger Group Pune
http://www.hotjobseeker.com/
* Software Developer - Java/J2EE
http://www.hotjobseeker.com/
* TECH SUPPORT EXECUTIVE
http://www.hotjobseeker.com/
* HR Trainee / HR Coordinator
http://www.hotjobseeker.com/
* Customer Support Executive
http://www.hotjobseeker.com/
* help desk executive -InKnowTech Private Limited
http://www.hotjobseeker.com/
* Sales & Service Engineer (Electronic)
   http://www.hotjobseeker.com/
 * Web Content Writer/Developer
   http://www.hotjobseeker.com/
 * VBA Developer -US Headquartered
   http://www.hotjobseeker.com/
 * RECRUITMENT EXECUTIVES/ RECRUITERS
http://www.hotjobseeker.com/
* Application Software Engg/Php developer
http://www.hotjobseeker.com/
* Tele Calling Executive -Insync
http://www.hotjobseeker.com/
* Operations Support Executive -NETCRADLE INDIA
http://www.hotjobseeker.com/
* (0-1 Years) Walk-In @ "AMBARA SOFTWARE" : CSR : On 25-30 May 2008,
Male Candidates Only
http://www.hotjobseeker.com/
* (FRESHERS & EXPERIENCED) Walk-In @ "TIMESJOBS" : ITES Job Fair : On
24, 25 May 2008
http://www.hotjobseeker.com/
* Walk-In @ "PCS TECHNOLOGY" : Server Support : Chennai : On 24, 26
May 2008
http://www.hotjobseeker.com/
* Walk-In @ "TCS" : Multiple Skills : Kochi / Pune / Hyderabad /
Chennai : On 24, 25 May 2008
http://www.hotjobseeker.com/
* (FRESHERS) Walk-In @ "NATIONAL INSTRUMENTS" : On 6, 7 Jun 2008, BE /
B.Tech : Last Date - 4 Jun 2008
http://www.hotjobseeker.com/
* (FRESHERS) Walk-In @ "LIONBRIDGE TECHNOLOGIES" : From Monday to
Friday
http://www.hotjobseeker.com/
* Artech Infosystems Walk-in for Freshers: Weekdays
http://www.hotjobseeker.com/

NOTE FROM ADMIN:
http://www.hotjobseeker.com/
http://finance.groups.yahoo.com/group/hotjobseeker/
$Some of these requirements may not suit your eligibility
criteria , Do not delete this mail straight way. It may help
few of your friends or classmates who are struggling to find
more opportunities. Kindly forward this mail to them. We want
you to join this revolution by helping fellow job seekers.
Please forward this mail to other groups, Orkut friends,face
book friends,yahoo mailing list,google talk members, College
groups etc...
 http://finance.groups.yahoo.com/group/hotjobseeker/
All of our sections are updated daily with mails .Apply to all
eligible
requirements as soon as possible.

This mail is neither spam nor unsolicited. You received this message
because you are a member of http://www.hotjobseeker.com from the
World's Biggest Job Group.
please send this mail to your mailing list
http://finance.groups.yahoo.com/group/hotjobseeker/







--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Experimental Git repository available

[Gary Wilson Jr.]

Marc Fargas wrote:
> El jue, 19-06-2008 a las 14:03 -0700, Michael Elsdörfer escribió:
>> FWIW (I'm currently playing around with all three of them), bazaar
>> appears to support pushing into svn as well.
> 
> Yes, with bzr-svn.

Be advised, though, that currently bzr-svn will dump out a ton of svn 
properties into your repo [1].  Then, if you say to yourself "what the 
heck just happened!?" and go revert that revision (removing the 
properties), you will not be able to ever branch the repo again using 
bzr-svn until this bug [2] is fixed.  Wish I would have known that 
before I did it :)

Gary

[1] 
http://samba.org/~jelmer/bzr-svn/FAQ.html#bzr-svn-sets-all-kinds-of-file-properties-when-pushing-revisions-into-subversion-is-this-really-necessary
[2] https://bugs.launchpad.net/bzr-svn/+bug/174690

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---