d but the docs absent in all. So writing docs
will cause to merging branch or something else prevents from this?
--
Alexander Solovyov
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gr
On Thu, Jun 19, 2008 at 2:58 AM, Jeff Anderson <[EMAIL PROTECTED]> wrote:
> * http://code.djangoproject.com/ticket/4996 - I don't know if it would be a
> good idea to make 'runserver' run as a daemon. Maybe it would be ok of there
> was a warning before forking.
I think that if somebody want to r
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 S
Hi all.
I've read all content of previous thread [1] and saw that it had come
to discussion about pre_create. One solution to resolve trouble with
doing something after creation is proposed by Amit Upadhyay (catch
both pre_ and post_save and set some property - is_new - in pre_save),
but it have
On Nov 8, 2007 1:46 PM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> See if this is of any help:
> http://www.amitu.com/blog/2007/july/django-extending-user-model/
He-he, so you have already done something like my proposal. :) Nice.
But lets' listen what core developers think about making this the
Hi,
Django have known trouble with default User object, which is not
always appropriate for
all applications, when they need additional information. Of course, we
have solution with
user profile and get_profile, but it is not very nice solution and
have imperfections: ;-)
- it is not fetched auto
On Nov 8, 2007 2:21 PM, Jonathan Buchanan <[EMAIL PROTECTED]> wrote:
> On this particular point, from the perspective of the reusable
> applications themselves, you don't need to worry about merging profile
> models, even if you are potentially working with many of them in your
> overall project.
