Re: Exceptions documention - #6842
The precise location is probably in ref/ although perhaps jacob could give a better answer. More importantly the way links are done has been changed, check out this: http://docs.djangoproject.com/en/dev/internals/documentation/ for more info, also look at other docs for examples, or ask here or in IRC. Thanks for your work On Aug 27, 9:54 pm, varikin <[EMAIL PROTECTED]> wrote: > Hi, > > I grabbed ticket #6842 and added a patch that has some documentation > for the exceptions Django raises since I needed some of this info:) > The file I added, exceptions.txt is not in the right folder after the > docs refactor landed between my starting the patch last week and > today. I don't know where to put it with the new layout, but moving > it is trivial. Also, all the information in it may not be perfect, I > did the best I could. > > This is my first contribution to Django and I am very happy to find a > place to help. So I would really appreciate any constructive > criticism on the patch. > > BTW, I am sorry about the timing. I expect this to be post-1.0, I > just wanted to get this email out while it was still fresh in my mind. > > Thanks, > John > > http://code.djangoproject.com/ticket/6842 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Exceptions documention - #6842
Hi, I grabbed ticket #6842 and added a patch that has some documentation for the exceptions Django raises since I needed some of this info:) The file I added, exceptions.txt is not in the right folder after the docs refactor landed between my starting the patch last week and today. I don't know where to put it with the new layout, but moving it is trivial. Also, all the information in it may not be perfect, I did the best I could. This is my first contribution to Django and I am very happy to find a place to help. So I would really appreciate any constructive criticism on the patch. BTW, I am sorry about the timing. I expect this to be post-1.0, I just wanted to get this email out while it was still fresh in my mind. Thanks, John http://code.djangoproject.com/ticket/6842 --~--~-~--~~~---~--~~ 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: Composite Primary Keys
Well for one thing, if one of the columns happens to be named "ID", we should use that for the relatedfields lookup column and that is that. (BTW, does your approach allow the Django supplied ID field to be combined with some other field(s) to make a multi-column key? This would be bang up for future partitioning support.) Next I would suggest adding a meta model column designation like "id_field" to specify a field to use for related classes. This might be a good "80/20" solution that could serve for an initial test version. On Aug 27, 5:27 pm, "David Cramer" <[EMAIL PROTECTED]> wrote: > Really I'm stuck at an architectural point. > > I have database validation and synchronization done, and the admin is > working. > > What is left is more or less handling relatedfield lookups. The issue is, > that field's are designed to reference more than one field, so it's a tough > design deicision to make on how that should be approached. > --~--~-~--~~~---~--~~ 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: Composite Primary Keys
What I had briefly discussed with malcom was using ordered tuples but
switching up the defaults to use actualy field lookups.
MyModel.objects.get(pk=(1, 2)) or MyModel.objects.get(foo=1, bar=2)
If we could come up with some design for multi-column fields I'm wiling to
put in the work.
On Wed, Aug 27, 2008 at 6:15 PM, Alberto García Hierro <[EMAIL PROTECTED]>wrote:
>
>
> El 28/08/2008, a las 0:27, David Cramer escribió:
>
> > Really I'm stuck at an architectural point.
> >
> > I have database validation and synchronization done, and the admin
> > is working.
> >
> > What is left is more or less handling relatedfield lookups. The
> > issue is, that field's are designed to reference more than one
> > field, so it's a tough design deicision to make on how that should
> > be approached.
>
> I think the best (and the only one right) solution involves adding
> multicolumn fields to Django and doing lookups with some syntax like
> Model.objects.get(pk=('foo', 1)). There are other hackish approaches,
> like using hash(tuple(pk[0], pk[1], ..., pk[n])) as foreign key, that
> could work. However, I won't rely on them, since I'm not sure if
> hash() implementation is guaranteed to be kept as is.
>
> On other related point, what's the status of multicolumn fields?
>
> Regards,
> Alberto
>
> >
>
--
David Cramer
Director of Technology
iBegin
http://www.ibegin.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: Composite Primary Keys
El 28/08/2008, a las 0:27, David Cramer escribió:
> Really I'm stuck at an architectural point.
>
> I have database validation and synchronization done, and the admin
> is working.
>
> What is left is more or less handling relatedfield lookups. The
> issue is, that field's are designed to reference more than one
> field, so it's a tough design deicision to make on how that should
> be approached.
I think the best (and the only one right) solution involves adding
multicolumn fields to Django and doing lookups with some syntax like
Model.objects.get(pk=('foo', 1)). There are other hackish approaches,
like using hash(tuple(pk[0], pk[1], ..., pk[n])) as foreign key, that
could work. However, I won't rely on them, since I'm not sure if
hash() implementation is guaranteed to be kept as is.
On other related point, what's the status of multicolumn fields?
Regards,
Alberto
--~--~-~--~~~---~--~~
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: Composite Primary Keys
Really I'm stuck at an architectural point. I have database validation and synchronization done, and the admin is working. What is left is more or less handling relatedfield lookups. The issue is, that field's are designed to reference more than one field, so it's a tough design deicision to make on how that should be approached. On Wed, Aug 27, 2008 at 5:23 PM, Rock <[EMAIL PROTECTED]> wrote: > > Any progress on this patch David? I would be happy to take a look at > whatever you have and perhaps help out with completing the patch. > > > > -- David Cramer Director of Technology iBegin http://www.ibegin.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: Composite Primary Keys
Any progress on this patch David? I would be happy to take a look at whatever you have and perhaps help out with completing the patch. --~--~-~--~~~---~--~~ 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: Policy regarding security support for 0.96
On Wed, Aug 27, 2008 at 11:43 AM, David Spreen <[EMAIL PROTECTED]> wrote: > As you might know, 1.0 will come too late for Debian Lenny (unless we > will get a freeze exception which at this time seems rather unlikely). > Since Security is important to Debian, I wondered if there is a policy > as to how long old stable releases (in this case 0.96) will receive > security support. First, we'll release security fixes at least until the 1.2 release, and possibly longer if someone is interested enough to volunteer to help us backport fixes. This'll probably happen; it's not a large amount of work. However: is there anything we can do to get an exception for 1.0 in Lenny? I know bupkiss about the Debian process, but obviously getting 1.0 into Lenny would be pretty sweet for us. If there's anything I can do to help make that happen, please point me in the right direction! 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: Policy regarding security support for 0.96
On Wed, Aug 27, 2008 at 12:43 PM, David Spreen <[EMAIL PROTECTED]> wrote: > > Hello, > > I am a member of the Debian Python Modules Team and have been heavily > involved in the transition to Django 1.0 in Debian (1.0~beta2 is about > to be uploaded to experimental). > > As you might know, 1.0 will come too late for Debian Lenny (unless we > will get a freeze exception which at this time seems rather unlikely). > Since Security is important to Debian, I wondered if there is a policy > as to how long old stable releases (in this case 0.96) will receive > security support. > > It says here: http://www.djangoproject.com/documentation/contributing/#reporting-security-issues security fixes will be developed for current and 2 previous releases. So 0.96 will certainly still get security fixes even after 1.0 is released. I believe that means fixes go into trunk, current latest release, and the 2 previous. That is at any rate what was done for the last announced security fix: http://groups.google.com/group/django-announce/browse_thread/thread/903d7c2af239ec42 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 -~--~~~~--~~--~--~---
Policy regarding security support for 0.96
Hello, I am a member of the Debian Python Modules Team and have been heavily involved in the transition to Django 1.0 in Debian (1.0~beta2 is about to be uploaded to experimental). As you might know, 1.0 will come too late for Debian Lenny (unless we will get a freeze exception which at this time seems rather unlikely). Since Security is important to Debian, I wondered if there is a policy as to how long old stable releases (in this case 0.96) will receive security support. All my best, David Spreen P.S.: I do not speak on behalf of the Debian Project or the Debian Python Modules Team. All opinions expressed in this post are my own. --~--~-~--~~~---~--~~ 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: The last push to 1.0
We are *NOW* in complete and total feature freeze? Regards On Aug 27, 9:41 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > "We're not in complete and total feature freeze. " > > I assume you mean the opposite of this. > > On Aug 27, 9:15 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> > wrote: > > > Hi folks -- > > > Right, so this is it. > > > We've got about a week until the scheduled release of Django 1.0, and > > the milestone shows 86 open tickets. It's time to put our heads down > > and get this release out. A few notes: > > > We're not in complete and total feature freeze. This means that the > > only things we should be working on for the next week are fixing true, > > verified bugs. This also means that if you report a feature request, > > it'll get automatically pushed to post-1.0 regardless of the merits. > > > We're also in string freeze so that translators have the next week to > > get their translations as complete as possible. Any string marked for > > translation cannot be changed. This means that if you're working on a > > patch that touches translated strings, we'll ask you to write around > > them. > > > Don't expect to see much activity from the core developers on the > > community lists and channels. If there's something that needs > > attention from one of us, make a note and repost in about two weeks if > > we've not gotten back to you by then. I, at least, am going to pretty > > much ignore the mailing lists for the next weekish while we get this > > release out. > > > Finally, keep in mind that although "1.0" seems huge -- mostly since > > we've been working on it for so long -- it's only the *first* of what > > I expect to be an increasingly awesome set of releases. 1.0 will be > > missing quite a few things we've had to put off, but 1.1 will be even > > better, and 1.2 will kick the crap out of 1.1. > > > So let's do the best we can, but remember that it'll only get better from > > here! > > > 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: The last push to 1.0
pls forgive me. didn't see Jacob's reply. was replying to alex.gaynor. the exact phrasing was a coincidance, though.. lol On Aug 27, 10:51 pm, Sean <[EMAIL PROTECTED]> wrote: > We are *NOW* in complete and total feature freeze? > > Regards > > On Aug 27, 9:41 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > wrote: > > > "We're not in complete and total feature freeze. " > > > I assume you mean the opposite of this. > > > On Aug 27, 9:15 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> > > wrote: > > > > Hi folks -- > > > > Right, so this is it. > > > > We've got about a week until the scheduled release of Django 1.0, and > > > the milestone shows 86 open tickets. It's time to put our heads down > > > and get this release out. A few notes: > > > > We're not in complete and total feature freeze. This means that the > > > only things we should be working on for the next week are fixing true, > > > verified bugs. This also means that if you report a feature request, > > > it'll get automatically pushed to post-1.0 regardless of the merits. > > > > We're also in string freeze so that translators have the next week to > > > get their translations as complete as possible. Any string marked for > > > translation cannot be changed. This means that if you're working on a > > > patch that touches translated strings, we'll ask you to write around > > > them. > > > > Don't expect to see much activity from the core developers on the > > > community lists and channels. If there's something that needs > > > attention from one of us, make a note and repost in about two weeks if > > > we've not gotten back to you by then. I, at least, am going to pretty > > > much ignore the mailing lists for the next weekish while we get this > > > release out. > > > > Finally, keep in mind that although "1.0" seems huge -- mostly since > > > we've been working on it for so long -- it's only the *first* of what > > > I expect to be an increasingly awesome set of releases. 1.0 will be > > > missing quite a few things we've had to put off, but 1.1 will be even > > > better, and 1.2 will kick the crap out of 1.1. > > > > So let's do the best we can, but remember that it'll only get better from > > > here! > > > > 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: The last push to 1.0
On Wed, Aug 27, 2008 at 9:56 AM, Jacob Kaplan-Moss < [EMAIL PROTECTED]> wrote: > > On Wed, Aug 27, 2008 at 8:41 AM, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > "We're not in complete and total feature freeze. " > > > > I assume you mean the opposite of this. > > Sigh. > > Proofread, Jacob, proofread. > > We're *NOW* in complete and total feature freeze. > Freudian typo. It's hard to commit to a feature freeze, even for just a week. --~--~-~--~~~---~--~~ 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: The last push to 1.0
On Wed, Aug 27, 2008 at 8:41 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > "We're not in complete and total feature freeze. " > > I assume you mean the opposite of this. Sigh. Proofread, Jacob, proofread. We're *NOW* in complete and total feature freeze. 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: The last push to 1.0
"We're not in complete and total feature freeze. " I assume you mean the opposite of this. On Aug 27, 9:15 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Hi folks -- > > Right, so this is it. > > We've got about a week until the scheduled release of Django 1.0, and > the milestone shows 86 open tickets. It's time to put our heads down > and get this release out. A few notes: > > We're not in complete and total feature freeze. This means that the > only things we should be working on for the next week are fixing true, > verified bugs. This also means that if you report a feature request, > it'll get automatically pushed to post-1.0 regardless of the merits. > > We're also in string freeze so that translators have the next week to > get their translations as complete as possible. Any string marked for > translation cannot be changed. This means that if you're working on a > patch that touches translated strings, we'll ask you to write around > them. > > Don't expect to see much activity from the core developers on the > community lists and channels. If there's something that needs > attention from one of us, make a note and repost in about two weeks if > we've not gotten back to you by then. I, at least, am going to pretty > much ignore the mailing lists for the next weekish while we get this > release out. > > Finally, keep in mind that although "1.0" seems huge -- mostly since > we've been working on it for so long -- it's only the *first* of what > I expect to be an increasingly awesome set of releases. 1.0 will be > missing quite a few things we've had to put off, but 1.1 will be even > better, and 1.2 will kick the crap out of 1.1. > > So let's do the best we can, but remember that it'll only get better from > here! > > 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: MultiDb status ?
On Wed, Aug 27, 2008 at 9:08 AM, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > That branch is totally dead, there is some external work attempting to > add multi-db support, I don't know the status of it though. > I believe that project is here: http://hg.woe-beti.de/multi-db/ 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 -~--~~~~--~~--~--~---
The last push to 1.0
Hi folks -- Right, so this is it. We've got about a week until the scheduled release of Django 1.0, and the milestone shows 86 open tickets. It's time to put our heads down and get this release out. A few notes: We're not in complete and total feature freeze. This means that the only things we should be working on for the next week are fixing true, verified bugs. This also means that if you report a feature request, it'll get automatically pushed to post-1.0 regardless of the merits. We're also in string freeze so that translators have the next week to get their translations as complete as possible. Any string marked for translation cannot be changed. This means that if you're working on a patch that touches translated strings, we'll ask you to write around them. Don't expect to see much activity from the core developers on the community lists and channels. If there's something that needs attention from one of us, make a note and repost in about two weeks if we've not gotten back to you by then. I, at least, am going to pretty much ignore the mailing lists for the next weekish while we get this release out. Finally, keep in mind that although "1.0" seems huge -- mostly since we've been working on it for so long -- it's only the *first* of what I expect to be an increasingly awesome set of releases. 1.0 will be missing quite a few things we've had to put off, but 1.1 will be even better, and 1.2 will kick the crap out of 1.1. So let's do the best we can, but remember that it'll only get better from here! 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: MultiDb status ?
That branch is totally dead, there is some external work attempting to add multi-db support, I don't know the status of it though. On Aug 27, 4:40 am, Romain Gaches <[EMAIL PROTECTED]> wrote: > Hi, > > Thinking about switching from a homemade framework to django, I took a > look a the MultiDatabaseSupport stuff > (http://code.djangoproject.com/wiki/MultipleDatabaseSupport > ). > The related code seems to be 2 years old, is this branch still in > development ? > > I also noticed that the DB parameters are "statically" defined in the > settings. I'm actually looking for the ability to connect to a > database "on the fly" according to session-related data; would it be > possible without too much adapting work ? > > The aim is to have a separate database (with the same schema) for each > customer account in my app, the customer id being extracted from a > session variable. > > I'm currently using my own db manager: attaching & detaching databases > (SQLite, MySQL), cross-db requests, etc... but django's models are so > amazing I'd like to lighten my app with it :) > > -- > Romain --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
forms.BooleanField(widget=forms.HiddenInput) broken on MySQL
Hi, In a quest to save us from a brown-paper-bag bug[1] I want to draw your attention to the following issue (just confirmed it with 1.0-beta2). Since it was decided that Django on MySQL may return in stead of for models.BooleanField (Ticket #7190 closed: wontfix) I want to reiterate that this breaks hidden boolean form fields a.k.a forms.BooleanField(widget=forms.HiddenInput, required=False). When you do a form POST based on a retrieved boolean field which is False/0 and update the object based on the form it becomes True/1. On Postgreql things works fine: # python simple/views.py created False retrieved False (POST value b False) updated based on form retrieved False On MySQL things go painfully wrong: # python simple/views.py created False retrieved 0 (POST value b 0) updated based on form retrieved 1 Check out http://dpaste.com/hold/74190/ Time to open a new issue which focuses solely on the Hidden Boolean issue in stead of #7190? Ps: I still feel that exposing the fact that MySQL does not support booleans is a mistake exactly because it creates two new paths in Django. One where booleans are mapped to and one where they are mapped to . There have been problems with the tests on MySQL because of this too. Besides it feels like python < 2.3 ;) Pim. [1] http://catb.org/jargon/html/B/brown-paper-bag-bug.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
MultiDb status ?
Hi, Thinking about switching from a homemade framework to django, I took a look a the MultiDatabaseSupport stuff (http://code.djangoproject.com/wiki/MultipleDatabaseSupport ). The related code seems to be 2 years old, is this branch still in development ? I also noticed that the DB parameters are "statically" defined in the settings. I'm actually looking for the ability to connect to a database "on the fly" according to session-related data; would it be possible without too much adapting work ? The aim is to have a separate database (with the same schema) for each customer account in my app, the customer id being extracted from a session variable. I'm currently using my own db manager: attaching & detaching databases (SQLite, MySQL), cross-db requests, etc... but django's models are so amazing I'd like to lighten my app with it :) -- Romain --~--~-~--~~~---~--~~ 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: contrib.auth tests
On Wed, Aug 27, 2008 at 9:20 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Tue, 2008-08-26 at 18:09 -0700, Cam MacRae wrote: >> contrib.auth view tests fail if required templates aren't found. This >> seems a sensible default in line with Russell's post [1] > > The problem with that original position is that it overloads testing to > include both testing the auth app's implementation and testing the > user's configuration when they're using the auth app. So there are > definitely two legitimate sides to that opinion. > > I much prefer self-contained unittests. I read Russell's mail as > preferring to trade that for installation/configuration testing. I don't > particularly agree with that, but I could live with it if we decide it's > the way we want to go. I suppose this just serves to highlight that there are two types of testing that need to be performed - application tests and integration tests. While the unittest framework is certainly well suited to application testing, in a (semi) controlled environment like a Django project it can also be quite useful for integration testing. In a complete system, both forms of testing are required, which means a complete reusable application should have two tests: 1) a test that the views work as expected when a known correct template is provided 2) a test that the view works as expected with the template that has been provided by the project (which is also a test that the required templates are available). The self-contained approach to testing is essentially case (1). This is fine, but you still need to write a test for (2). A well written 'template external' test _should_ validate both cases when it passes. There are some weakness to this argument - if you get a failure, it doesn't help you narrow down if the problem is your template or the application logic, and there is the outside possibility that a bad template could somehow cause the test to pass (although I can't think of an easy way that this would happen) - but as a general argument, it should hold. The failure case isn't that bad, though, because there are two people that will run the test - * The application developer * The end user The application developer should have a good set of templates in their test harness (such as Django's templates in the system test folder), and if a failure is observed, the app developer is in the best position to sort out the source of the failure. End users should be able to trust their app providers to be testing and tagging releases only when tests pass; if an end user is seeing a failure, it's a reasonable assumption that the failure is template related. As a side note, if the end user trusts their provider, there is almost no reason for the end user to run type (1) application tests (case in point - how often do non-core devs run the Django test suite? How often to Django core devs run the MySQL test suite?) Of course, the ideal solution would be a good answer for the problem of supporting both application and integration tests, but that's part of a much bigger discussion. >> but rev 8497 >> introduces a test only template directory [2] which >> >> a) causes the tests to pass in the absence of an actual login template >> (the provided template is not a default template, it's a test >> template); > > It also means the tests pass as a self-contained bundle to test the auth > app, rather than requiring a user using the auth app to have to set up > all these templates even if they're not using a particular piece of the > auth app just to have the tests pass. That's not a trivial concern. The missing piece here is something that I have raised in the discussion around #7611 - there will be tests that should be skipped as part of the suite if the feature they are testing isn't actually deployed in a project. For example, if you're not deploying the password change view you don't need to run tests that check that the password change view work is working correctly. Devin Naquin (from Disqus) did some initial work in this area around ticket #4788; I haven't had a chance to look into his patches yet, but it's on my todo list once we get 1.0 finished. > There is a middle ground here, which is that those auth-app templates > get moved to the Django's main test directory so that they're available > only to runtests. That doesn't feel particularly self-contained and > again, for me, violates the intuitive meaning of the word unittest, but > it's the way we've gone with the new comment tests and the admin tests, > for example. Might be a trend to follow. To my mind, moving the templates to the django test directory is the right solution in this case. The Django system tests need to validate that the auth system works when the right templates are available, so it needs to provide those templates. Unfortunately, this means that the auth tests will fail for users that aren't providing auth templates. I realize that this isn't an ideal outcome, but my gut
ANN: Django 1.0 beta 2 released
As part of the run up to the final Django 1.0 release (scheduled for next week!), tonight we've pushed out Django 1.0 beta 2, including the final new features for 1.0 (mainly a refactoring of django.contrib.comments). As a beta release, we of course don't recommend it for production use, but if you'd like to test it and help us squash bugs for the final release, feel free to grab a copy and pitch in. Release notes: http://docs.djangoproject.com/en/dev/releases/1.0-beta-2/ Download: http://www.djangoproject.com/download/ -- "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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MySQL and Autocommit
On Sat, 2008-08-23 at 11:00 -0700, David Cramer wrote: > Recently I noticed a bunch of queries I was executing by hand (one's > which the ORM didn't support) were not being committed. > > I dug into the docs, and it clearly states that the default > transaction mode is autocommit, and mysql's default transaction mode > is autocommit. > > So, my question is, what's going on? > > I ended up doing set autocommit=1 at the beginning of the queries, but > this is a pretty big gotcha. I just twigged to what you were saying here. There's no gotcha. You were just forgetting to check the requirements for one piece between you and the database. If you're going to do low-level Python database work (at the level of MySQLdb), the important thing to read is PEP 249. Without that, it's just a bunch of guesses. This behaviour is documented there. Auto-commit must initially be off for Python DB-API-2.0-compliant modules. This is consistent behaviour across all Python database wrappers. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
