Re: Any reason for Field subclasses calling super on get_db_prep_save?
Today it may be empty, but tomorrow there can appear some useful code. So I think its better to follow that style. On May 29, 12:57 am, "Leo Soto M." <[EMAIL PROTECTED]> wrote: > I see that almost all Field subclasses which implements > get_db_prep_save end calling Field.get_db_prep_save anyway. That's > curious, because Field.get_db_prep_save is a no-op. > > Is it just some OOP style which we want to keep? > > -- > Leo Soto M.http://blog.leosoto.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: Any reason for Field subclasses calling super on get_db_prep_save?
And rewrite it in every project?! No, thanks. I'd like to write it now and have no troubles in future at all. On Jun 2, 9:12 am, "Leo Soto M." <[EMAIL PROTECTED]> wrote: > On Wed, May 28, 2008 at 5:08 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > > On May 29, 12:57 am, "Leo Soto M." <[EMAIL PROTECTED]> wrote: > >> I see that almost all Field subclasses which implements > >> get_db_prep_save end calling Field.get_db_prep_save anyway. That's > >> curious, because Field.get_db_prep_save is a no-op. > > >> Is it just some OOP style which we want to keep? > > > Today it may be empty, but tomorrow there can appear some useful code. > > So I think its better to follow that style. > > Maybe, but looking at the source code and documentation[1] such > super() call is not clearly required. OTOH, if tomorrow a useful code > appears, the super() could be added tomorrow. > > [1]http://www.djangoproject.com/documentation/custom_model_fields/ > -- > Leo Soto M.http://blog.leosoto.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: Django releases
I think that it is better way to write code and produce 1.0 as soon as possible then to write tons of text that doesn't help in it. --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
It is not a problem. Just skip non-English posts at all. English is international language of cource but not the one. On Jun 13, 7:58 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > The Django community aggregator includes non-English posts, which are > unfortunately pure noise for those of us who don't understand other > languages. Can we either restrict the aggregator to English posts, or > at least create sub-feeds for English and non-English posts? > > I don't mean to tread on the toes of those making non-English posts, > but English is the lingua franca of most open-source development > (including Django); non-English posts are of dubious usefulness to the > Django community at-large. By no means do I suggest that these > individuals cease posting; I only question whether those posts belong > in the aggregator. --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
And when does author write in number of languages? On Jun 13, 8:41 pm, Jeff Anderson <[EMAIL PROTECTED]> wrote: > siudesign wrote: > >http://www.djangobrasil.org/< Not in English. > > > Huge -1 > > > If people want to post in their own language they can. Having a feed > > split up by languages might be an option, but it really isn't that > > hard to ignore. Personally, I know those of us who speak multiple > > languages actually appreciate having everything in one place. > > One way to implement a solution would simply to be to attach a language > to each source. Those of us that speak English and Spanish could > subscribe to a feed of English and Spanish posts. :) Those of you who > only speak English could subscribe to a feed that only includes English, > etc... > > The current URL (firehose feed) could give the same result after this > feature is added to the aggregator so it won't disrupt anyone's current > subscription to the feed. > > I think it would be beneficial to give the option as to what one can > subscribe to. That's in harmony with one of the major philosophies of > open source... freedom. :) > > Jeff Anderson > > signature.asc > 1KDownload --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
There is existing multi-lingual aggregator http://djangosearch.com/ On Fri, Jun 13, 2008 at 9:07 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > This whole thing reminds me of something I've had rattling around in > my head for a while, and maybe now's the time to bring it to the > group. In addition to the language of blog posts, I've often had a > hard time tracking down information from past conversations that have > happened in the community. > > There's an aggregator, IRC log, various mailing list archives, wiki > articles, ticket comments, localized community sites, the list goes on > and on. In the spirit of community-oriented sites (like djangosites, > djangosnippets, etc), I'd like to propose djangochatter, a site > dedicated to aggregated, managing and distributing communication > taking place in the Django community. > > Essentially, it could pull together information from *all* those > various sources, index it for searching, provide feeds for various > tags and keywords (users would have to tag entries manually). In light > of this discussion, I expect it could also reasonably auto-detect the > text's language, so users could sign up for a feed for whatever > language(s) they can understand. > > Ideally it would also have a complete (or as near as possible) archive > of *past* chatter as well. Pull together all the existing feed > history, mailing list discussions, IRC logs, wiki history, existing > ticket comments, and make them all available in a single place all at > once. > > Basically, while I feel the existing aggregator is quite useful, and > has served the community well, I think there's more that can be done, > and there's no need to require the "official" site to handle it. In > fact, I would think that once djangochatter.(com|net|org) is up and > running, the existing aggregator could just redirect over to the > appropriate page and feed URLs and be done with it. > > I don't have time to head this up, but I think it would be extremely > useful for everybody. I know I've spoken with a few people about this > in the past, but is anybody interested in heading this up? I'd love to > see it happen, and I'm more than willing to take part in discussions, > but I just can't dedicate myself too much to it at the moment. > > -Gul > > > > --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
-100 Non-English post isn't noise! Some English posts has more less profit then non-English ones. On Fri, Jun 13, 2008 at 9:07 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 13, 2008 at 12:02 PM, Arien <[EMAIL PROTECTED]> wrote: > > > > The non-English posts are clearly useful to the Django community as a > > whole, as it appears that the majority of its members don't speak > > English as their native tongue. > > I'm totally fine with non-English feeds being available. > > > >> Having *only* a [language-agnostic] firehose feed, as we do now, is a > problem. > > > > Why? > > Because, as I've mentioned earlier: users effectively get noise in > their feeds. For any post in a language other than English, *the vast > majority* of the Django community won't be able to read it. I'm not > only talking about native English speakers here; why should we expect > that a native Portuguese speaker will be able to read a Russian post? > > > > --~--~-~--~~~---~--~~ 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: QuerySetPaginator object_list type check?
Regular `Paginator` is for any sequence of object (it calls `len` for count). `QuerySetPaginator` is for `QuerySet` objects. Find the right choice must developer itself. Its easy:) On Jun 29, 4:54 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I just spent a while chasing my tail because I was passing the results > of get_list_or_404 to the QuerySetPaginator, not realizing that it > returns a list and not a QuerySet object. > > When I tried to get the count, it raised the exception: "TypeError: > count() takes exactly one argument (0 given)" > > I probably would have realized the stupidity of my error more quickly > if _get_count was making sure that I passed QuerySetPaginator a > QuerySet object and not a list. > > Would there be any merit to checking the type of the object_list > parameter? I'm not sure of the ramifications, so I'm just asking, not > necessarily suggesting :) > > I see that there is an unreviewed ticket that would obviate a type > check:http://code.djangoproject.com/ticket/7478 > > Here's what I saw: > > >>> from django.core.paginator import Paginator, QuerySetPaginator > >>> from django.contrib.auth.models import User > >>> from django.shortcuts import get_list_or_404 > > >>> ul1 = User.objects.all() > >>> ul2 = get_list_or_404(User.objects.all()) > > >>> pp = Paginator(ul1, 2) > >>> pp.count > 1 > >>> qp = QuerySetPaginator(ul2, 2) > >>> qp.count > > Traceback (most recent call last): > File "", line 1, in > File "/home2/tbo/webapps/django_wsgi/django/core/paginator.py", line > 70, in _get_count > TypeError: count() takes exactly one argument (0 given) --~--~-~--~~~---~--~~ 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: Some ideas about AUTH_PROFILE_MODULE (tickets: #7584, #7592 and #7400)
May be better way to use ``OneToOneField`` with proper ``related_name`` like "profile" for example. Than profile can be accessed very simple ``user.pofile``. and its creation machinery leave to profile app author? On Jul 2, 12:38 pm, David Danier <[EMAIL PROTECTED]> wrote: > This basically started as a ticket suggesting adding some way to create > a default profile for users which don't have one, moving the need to > catch DoesNotExist-exceptions out of the applications using get_profile(). > ->http://code.djangoproject.com/ticket/7584 > > julien did suggest some alternatives, which all bring some drawbacks > with them and finally closed the ticket, as #7592 got closed, too. After > some discussion he suggested bringing the topic up here. > > My current idea is to add the possibility to provide a > get_for_user()-method in the profile manager, this would fix #7584, > #7592 and even #7400...and would possible add room for more ideas, hence > make the whole get_profile()-stuff more flexible. > Patch:http://code.djangoproject.com/attachment/ticket/7584/django-profile-m... > > So, about the alternatives: > > 1. Use signals (#7584, comment:1) > Might work, but does not support on demand creation of profiles for > legacy-users. There may be more use-cases where post_save is not enough. > Still need to catch the exception, as you can't guarantee the existence > of a profile. > > 2. Importing AUTH_PROFILE_MODULE yourself (#7592) > Not really possible, think about templates for example. Even if only > needed in views this duplicates code. > > 3. Own profile-module with appropriate manager (#7584, comment:3) > Like importing AUTH_PROFILE_MODULE yourself, but with cleaner code. > Still no easy support in templates. Does not work if application needs > to be reusable (on some other website with different profiles). > > 4. Overwrite get() on profile-manager (#7584, comment:4) > Possible, but seems rather hackish. Additionally nothing someone new to > django might do or want to do. > > So is there any reason not to support creating profiles on demand? The > patch is only three new lines and should not cause any trouble I think. > Of course docs are missing so far. > > Greetings, David Danier --~--~-~--~~~---~--~~ 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: post_save signal triggered twice
You register same handler twiсe. Check the way you import your modules. On Jul 25, 6:10 pm, "Alex Rades" <[EMAIL PROTECTED]> wrote: > Hi, > is there a non-obvious reason for signals like post_save being > triggered twice for each save? --~--~-~--~~~---~--~~ 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: Denormalisation, magic, and is it really that useful?
Hi, guys! For a long time I have thoughts to make composition/denormalisation a little bit easier and reusable. But I have no time to implement my ideas. Inspired by Anrew's blog post and its thread I recently wrote some code. And I think that it really may be useful and cover most of denormalisation use cases in Django. And this is an example of Anrew's code but with my CompositionField: class Picture(models.model): user = models.ForeignKey(User) user_username = CompositionField( native=models.CharField(max_length=150), trigger=dict( sender_model=User, field_holder_getter=lambda user: user.picture_set.all(), do=lambda picture, user, signal: user.username ) ) image = models.ImageField(upload_to="foo") title = models.CharField(max_length=100) Its more verbose but very generic and can be customized. And free bonus - auto-generated `update_user_username` method. The code available here [1]. Its very generic but allows to write more high-level subclasses with some introspection. Today I've written the blog post about it and my future suggestions. It is in Russian[2], here is a google-translated version [3] (but with broken code blocks) that I think can help to understand some concepts. And it holds more usage examples. I have many new ideas of how my solution can be improved and I what to hear you opinions about it. Thanks. [1]: http://svn.turbion.org/turbion/trunk/turbion/utils/composition.py [2]: http://webnewage.org/post/2008/9/26/krasivaya-kompozitsiya/ [3]: http://translate.google.com/translate?u=http%3A%2F%2Fwebnewage.org%2Fpost%2F2008%2F9%2F26%2Fkrasivaya-kompozitsiya%2F%23comment_720&hl=en&ie=UTF-8&sl=ru&tl=en On Sep 23, 12:03 am, Andrew Godwin <[EMAIL PROTECTED]> wrote: > So, hello everyone. I figure this list is the best place to ask this, > but please feel free to deride me if not... > > After all the talk of multiple databases, and non-relational databases > (bigtable, couchdb, etc.) that went on at DjangoCon and afterward,I've > been thinking about denormali[s/z]ation and how to make it easier in > Django; previously, I had thought denormalisation was something you did > to ruin your database, but I can now see it can be additive as well. > > In this vein, last weekend I decided to see how easy it would be to > write a magical DenormalisationField which handled all the synchronising > of data from the relevant tables given a normal ForeignKey relationship; > the results are athttp://www.aeracode.org/2008/9/14/denormalisation-follies/ > > Basically, yes, it is possible, and a lot of people (eight! for my blog, > that's a lot) seem to like the idea; it certainly saves having to write > that replicate-on-save logic that otherwise goes with this kind of > schema design. > > Given the fact that it seems like a reasonably common thing to do in > large-scale applications, I'd like to know what people think about > adding this kind of thing into core (while I have a standalone > implementation, that needs some hacks I'd like to see gone). My main > issues with this idea are: > > 1) It relies on having a ForeignKey pointing to the other model, so this > might not work for non-relational databases (well, unless ForeignKeys > are still allowed in that case, but they just perform expensive SELECTs > as well as possibly printing abusive messages to stderr). > > 2) I'm not sure how common a use case this is; it sounds like it might > be verging into the long tail a bit. > > 3) People also want other things denormalised - count()s, aggregate > queries, etc. Of course, writing fields for these too is similar, and > I'd be happy to do it, but it might mean that even if the case for > denormalisation is good this is only a piece of the puzzle. > > So, I'd love people's opinions about where I should take this - to a > dark corner and hide it, to a separate app like django-extensions (which > involves keeping the horrid hacks in there), into a separate app but > with patches to core to make it less hackish (i.e. more signals), or add > it as my 1.1 pony with the proviso that I'm happy to write all the code. > > Andrew --~--~-~--~~~---~--~~ 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: Denormalisation, magic, and is it really that useful?
Hi, Erik. The main purpose is to have declarative form of composition field calculation definition. Not to write imperative actions/signal connection/etc. I've made only flexible generic solution. In future I plan to write high-level subclasses that will can with minimal input parameters make all work very comfortable for developers. And then there will be no need to write all denormalisation functionality once again and again, from project to project. On Sep 26, 8:56 pm, Erik Allik <[EMAIL PROTECTED]> wrote: > I was just wondering.. Why all this abstraction? > > Why do we need a separate field for denormalization? Can't we just use > regular fields and simply set up denormalization in a procedural way > in the constructor? All that needs to be done to create a denormalized > field is connect a few signals maybe or do some expensive compuation > after modifying a field. But maybe I'm missing something crucial. > > Erik > --~--~-~--~~~---~--~~ 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: Static vs variable test fixtures
After `testFOO` method call test case flushes all data in database. So if you want to add some logic at this stage - flushing procedure may take a lot of time and you will get no speed improvements. On Oct 14, 5:18 am, Simon Litchfield <[EMAIL PROTECTED]> wrote: > Reloading of fixtures for each test gets painful when the fixtures get > big. > > Maybe we could continue to have TestCase.fixtures as a list of > 'variable' fixtures that do definitely need to be reloaded for each > test... and add a new optional attribute, TestCase.static_fixtures, > which would be a list of fixtures that only need to be loaded at the > start of the TestCase. > > I've run into this problem a few times now and this simple improvement > would make tests so much nicer :-) --~--~-~--~~~---~--~~ 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: Improving Errors from manage.py
Try to use `--traceback` switch that prints exception's traceback On Tue, Nov 18, 2008 at 00:41, David Cramer <[EMAIL PROTECTED]> wrote: > > I've been trying to dump some data to fixtures for the last couple > days, and I've ran into various problems each time. It's been quite > difficult each time to determine the problems, as there's no useful > tracebacks on the error messages: > > [EMAIL PROTECTED]:~/Development/iplatform] ./manage.py dumpdata > businesses > data > Error: Unable to serialize database: Category matching query does not > exist. > > > While this is great and all (it beats the "recursive error" that > appeared in previous revisions with the same models), it would be much > more useful if some of the commands would give more detailed > information so that you can actually diagnose problems :) > > > --~--~-~--~~~---~--~~ 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: New Patterns Idea
And what are the benefits? On Wed, Nov 26, 2008 at 16:36, Alexander Lyabah <[EMAIL PROTECTED]>wrote: > > I am already posted it on Django Snippets > http://www.djangosnippets.org/snippets/1218/ > > I want to introduce my idea about url resolving in Django. > > It can be useful for using object-oriented includes in common patter. > > It can be useful for created function which will be running only > before functions inside his include object. > > I am using it now and it is very helpful for me. > > What do you think about it? > > > > --~--~-~--~~~---~--~~ 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: Admin Site
Something wrong with your code (maybe ib site.site_app.view) or third-party code that you use. Django has no entity with name `activeAccount`. On Wed, Dec 17, 2008 at 20:26, samira wrote: > > I renamed my project, but no diffrent. it seems something is wrong in > admin templates. > > On Dec 17, 8:17 pm, "Jeremy Dunck" wrote: > > On Wed, Dec 17, 2008 at 11:14 AM, samira wrote: > > > > > I active admin site for Django 1.0.2, it is correct on my local, but I > > > see below error on server: > > > > > emplateSyntaxError at /site/admin/ > > > > > Caught an exception while rendering: Tried activateAccount in module > > > site.site_app.views. Error was: 'module' object has no attribute > > > 'activateAccount' > > > > > can anu body knows about activeAccount attribute? > > > > This is a question for the django-users mailing list. > > django-developers is for development *of* Django rather than > > development *with* Django. > > > > But your problem is likely that you named your site module "site", > > which is a standard-library module critical to python's library > > loading functions. > > > > Rename "site" to anything else, and it should work. > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Order of models metaclass __new__ dict
I can write a short overview:
Each model field(or form field) is marked by special counter while
model(or form) is loading. Then in metaclass fields are sorted by that
counter.
I've recently written the blog post about this staff but its in
Russian language. Overwise you can look at code snippet(first and
second ones) that exists there:
http://webnewage.org/2009/1/10/prinuzhdenie-k-poryadku/
On Mon, Jan 12, 2009 at 12:19 AM, dauerbaustelle wrote:
>
> Hi there,
>
> I'm writing some python stuff using metaclasses. I use declarative
> syntax like django's db.models.Model and the dict is catched by some
> metaclass __init__ method. My Problem is, that, unfortunately, the
> order of the variables I get is not the same as the order the
> variables I set:
>
> class FooBar(Parent):
>foo = blah
>bar = blubb
>bizz = peng
>buzz = pumm
>
> will end in something like
> {'bizz' : peng, 'bar' : blubb, 'foo' : blah, 'buzz' : pumm}
>
> As I can see, django's models.Model metaclass manages the vars in the
> right order (as one can see at the admin webinterface) - this is
> confusing me... dict's aren't sorted types, so who do you do this?
>
> Would be nice to know ;-)
>
> - dauerbaustelle
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: User Authentication without password
You have to write your own authentication backend [1] with any credentials you need. [1]: http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend On Tue, Feb 24, 2009 at 6:52 AM, dannyr wrote: > > > Is there a way to force authentication for a user without a password > (= authenticate(username=test...))? I'm developing an app that allows > a user to login either via Facebook Connect or the normal login. > > Thanks. > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: User Authentication without password
And of course this topic is for django-users@ not developers. On Tue, Feb 24, 2009 at 10:33 AM, Alex Koshelev wrote: > You have to write your own authentication backend [1] with any credentials > you need. > > [1]: > http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend > > On Tue, Feb 24, 2009 at 6:52 AM, dannyr wrote: > >> >> >> Is there a way to force authentication for a user without a password >> (= authenticate(username=test...))? I'm developing an app that allows >> a user to login either via Facebook Connect or the normal login. >> >> Thanks. >> >> >> >> >> > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Why the request.get_full_path() returns empty string
Because this method overloaded in subclasses of HttpRequest On 10 дек, 12:52, David Reynolds <[EMAIL PROTECTED]> wrote: > On 10 Dec 2007, at 5:35 am, Eratothene wrote: > > > Don't bother I have just figured out why. > > Can you say why, just for completeness of the archives? > > Thanks, > > David > > -- > David Reynolds > [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: Generic Relation: Alter Table
See CREATE sql statements for example On 20 дек, 15:52, madhav <[EMAIL PROTECTED]> wrote: > as a part of using generic relations, i got struck up at one point, > where i need to run the sql to have a field: > summary = generic.GenericRelation(Summary) > > where Summary is a class defined as: > class Summary(models.Model): > id = models.AutoField(primary_key=True) > content_type = models.ForeignKey(ContentType) > content_object = generic.GenericForeignKey() > created_on = models.DateTimeField(auto_now_add= True) > modified_on = models.DateTimeField(auto_now= True) > > And I am using a class called Book which will be having the summary > field mentioned above. So to alter the Book model at the database > level, i need to run the alter table for Book. I dont know the > equivalent sql to create a generic relation column in the table. > Please help me. > Thanks in advance. --~--~-~--~~~---~--~~ 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: Generic Relation: Alter Table
It's normal behaviour:) GenericRelation is just "fake" field that doesn't produce real table field On 20 дек, 16:23, madhav <[EMAIL PROTECTED]> wrote: > I did it, but its not showing up the new field(which is "summary" in > my case) in the Create Statement, nor is at the Alter table part. > > On Dec 20, 5:59 pm, "Patryk Zawadzki" <[EMAIL PROTECTED]> wrote: > > > 2007/12/20, madhav <[EMAIL PROTECTED]>: > > > > as a part of using generic relations, i got struck up at one point, > > > where i need to run the sql to have a field: > > > summary = generic.GenericRelation(Summary) > > > > where Summary is a class defined as: > > > class Summary(models.Model): > > > id = models.AutoField(primary_key=True) > > > content_type = models.ForeignKey(ContentType) > > > content_object = generic.GenericForeignKey() > > > created_on = models.DateTimeField(auto_now_add= True) > > > modified_on = models.DateTimeField(auto_now= True) > > > > And I am using a class called Book which will be having the summary > > > field mentioned above. So to alter the Book model at the database > > > level, i need to run the alter table for Book. I dont know the > > > equivalent sql to create a generic relation column in the table. > > > Just run ./manage.py sql and see the output. > > > -- > > Patryk Zawadzki > > PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Should manage.py startapp create a urls.py file?
No, only startproject creates project-wide urls.py On 4 фев, 20:53, "Rob Hudson" <[EMAIL PROTECTED]> wrote: > If it's common advice to make apps portable and bundle urls along with > an app, shouldn't manage.py startapp also drop in a default urls.py > file? > > I realize it's simple to create a skeleton file yourself, but if > manage.py did it, it's one less thing to think about and do, and also > promotes good url bundling. > > -- > kthnxbye, > -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: Adding InnoDB table engine to sql.py create table statements
Hi, ro60
There is no need in such setting. Just now you can set table engine to
entire database or in settings.py per-connection with
DATABASE_OPTIONS = {"init_command": "SET storage_engine=INNODB" }
On Mar 25, 5:37 am, ro60 <[EMAIL PROTECTED]> wrote:
> Wanted to see what everyone thinks about the idea of adding a patch to
> allow for a setting that will automatically append a table engine type
> to the create table statements generated by
> django.core.management.sql.
>
> I created a patch for my local sql.py and it seems to work well. It
> consists of adding a DATABASE_TABLE_ENGINE = 'InnoDB' variable to my
> project's settings.py and then checking for that setting in
> sql_model_create and many_to_many_sql_for_model and if it's there
> appending on the table engine to the create table output.
>
> I can imagine a few reasons why this may not fly but for someone who
> uses mysql as their db this is really helpful. Anyway would love to
> hear your thoughts on the approach and the idea. Also if anyone is
> interested here is a svn diff for the changes I made to my local
> sql.py.
>
> http://www.ninjacipher.com/wp-content/uploads/2008/03/table-engine-sq...
--~--~-~--~~~---~--~~
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 proposition - djangosearch backend
Do you see: - http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer - http://code.google.com/p/djapian/ - http://code.google.com/p/django-sphinx/ ? On Mar 31, 8:39 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hi, > > My name is Grzegorz Swierad and I am interested in participating in > Google Summer of Code for Django. I study in University of Zielona > Gora in Poland. I have more than one year experience with Django. I > create sites:http://mines20.comorhttp://plom.pl. > > I wish to create a Xapian backend for djangosearch. Eventually, it can > be other search engine, but Xapian is more important for me, becouse I > use it in my new project. > > What do you thing about this, and who is interested in mentoring it? > > Thanks, > Grzegorz --~--~-~--~~~---~--~~ 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: Middleware class vs decorators (proposal?)
Hi, Amit! Check this utils function: http://code.djangoproject.com/browser/django/trunk/django/utils/decorators.py#L9 On Apr 13, 3:05 pm, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote: > Hi, > > I was wondering about the reason that middleware classes were used instead > of decorators to implement middleware functionality. One of the use cases > that lead me into thinking about it is that I was looking for a way to have > middleware apply only to views of one particular app [facebook app for > example]. The MiddlewareNotUsed exception that is used by DebugMiddleware is > very limited, vs if it was a decorator, the decorator would have the view > passed and it could have taken a decision based on the module path of the > view. > > The other use case I thought of was: on my site, there are some background > processes running intermittently, and the load my mysql server, and abt > 20-30 times a day on my site we get an error abt mysql server not > responding. I imagined writing a middleware that will catch this exception, > and sleep for a few secs and then call the view again, but I realized the > current design of middleware does not allow that, and the only way to do > this would be to send a http302 or something, which would be useless for > POST requests and would be dangerous if website is loaded due to some reason > [it will lead to recursive 302, adding up lot of load on the website]. With > middleware I would have passed the actual view, and I would have caught the > exception and in excpetion handler trying to call the view one more time > before giving up. > > This is roughly how a middleware decorator would look like: > > def my_middleware(view): > if not shud_apply_on_this_view(view): return view # this is part of > __init__ currently, without access to view. > def decorated(request, *args, **kw): > x, y, z = get_xyz_from_request(request) # this is process_request > phase, without access to args, kw etc. > try: >resp = view(*args, **kw) > except TheExceptionIAmInterestedIn: >do_something_with_it() ># this is process_exception, but much more natural python, > than to do if isinstance(ex, MyExcp) ># plus i can call view again if i feel like. > do_something_with_xyz(x, y, z) # this is process_response, having > access to x, y, z is more natural than to attach them to self before and > after the call of view > return resp > return decorated > > -- > Amit Upadhyay > Vakow!www.vakow.com > +91-9820-295-512 --~--~-~--~~~---~--~~ 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: Want to have unit tests in multiple files
No. Not `tests.py`, but `tests` module - that can be a package of many other modules/files On May 7, 12:21 am, Steve <[EMAIL PROTECTED]> wrote: > Hi, we're just getting started using Django unit tests, and it looks > like the documentation says you can only have unit tests in two files: > models.py and tests.py. We would prefer to put our unit tests in many > different files, with, say, each main-line .py file having a > corresponding unit-test file. Is there a convenient way to do this in > 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 -~--~~~~--~~--~--~---
