multiple-db-support branch
Hi all. Few minutes ago I drop mail to Jason Pellerin and he tolds me that he can't maintain branch due to lack of time. So I have question - what needs to happen for merging this branch into trunk? I read page on wiki (MultipleDatabaseSupport) and examined that all features are completed 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" 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
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 run native Python webserver, it's better to use CherryPy's WSGIServer, which is really good (fast, stable, supports threading). It's not that hard to run it yourself or to find manuals in the internet how to do that. I personally was in need of such thing and composed application [1], which just lets you run CP webserver in backround (production mode) or in foreground with output of all requests on console (debug mode). It's quite useful, especially for developing things, which want to access your project pages from your project code (like pingback). Plus Django's runserver was really unstable for me in some cases (and I didn't found trouble source :\). [1]: http://hg.piranha.org.ua/cpserver/ -- 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
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 -~--~~~~--~~--~--~---
Additionals thoughts on post_create
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 two defects: one is that I need to have 2 signals (you say, DRY? :), second is that if I will set PK by hands, I will not realise that this is new object. Why I need post_create signal? Because I have need to send some alert to user when objects of various types are created and I come to solution with separate model with generic relations and catching pre/post_save to create new Alert. But... In some places I have trouble with manually set PK. Of course, I can set is_new property by hands, but also I can execute my function by hands. This is not clear solution. :( [1]: http://groups.google.com/group/django-developers/browse_thread/thread/4da9ca1f413246ab/762470a3b908b549 -- 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: contrib.auth and User model
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 official way. :) -- 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 -~--~~~~--~~--~--~---
contrib.auth and User model
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 automatically with User object (it can be, but with a lot of code) - you must think about creation of it - (main trouble) if you have absolutely different applications, which use profile for their own purposes, you need to merge their Profile models - trouble is in the updating of this thing (f.e., you have forum, created by someone and integrated in your project, and you definitely want to have updates). I thought a lot about this situation and I think that I see light in the end of tunnel - making User model dynamic and configurable via settings (or whatever). It will be not very hard to implement, it will speed up and simplify (from my point of view) things a lot and I don't see any serious drawbacks. What do you think about this? If this sounds reasonable, I'm happy to open a ticket and create a patch for this. -- 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: contrib.auth and User model
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. Going with the forum example, if your forum > application defines its own profile Model which addresses all of its > specific needs, it doesn't benefit it in any way if it has access to > some kind of merged profile instead - it does, however, introduce the > potential for conflicts. > > Personally, I never rely on the AUTH_PROFILE_MODEL setting and the > User.get_profile method in reusable applications, I only use those in > my main project. It's not a lot of work to add a method to your > application's profile Manager to load and cache a user's > application-specific profile in a manner similar to User.get_profile. > Since I'm actually working on a reusable forum application at the > moment, here's an example of what I mean: But what about if your forum have a field for an Jabber account or ICQ UIN and a blog (whatever) application has the same? Synchronize them using signals? Isn't this not very safe solution? -- 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 -~--~~~~--~~--~--~---
