Re: APPEND_SLASH alternative
I think it would be nice if the process for implementing your own URL dispatcher were more obvious / accessible. I have several friends who have told me they had a want for this, and that it took more effort than it should have. I haven't had to do it myself yet, but I would have if I had known there was an established method for doing 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: Shared memory across processes
On Jun 26, 11:28 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > The biggest hurdle to dbsettings at this point is that it caches > settings in a standard Python module, which only exists within a > single process. This was all well and good while developing it, but > people are now starting to try it under mod_python, which (depending > on the Apache MPM) creates multiple processes, each with their own > dbsettings cache. This is fine except when editing settings, since it > can only update the cache in the current process. Stop me if you've heard this: This is not a bug, it's a feature. Really, though, that's what it is. mod_python is chosen for deployment environments where a person does _NOT_ want a check to occur for updates because it impacts performance, instead choosing to push updates to the server explicitly. An easy way to do this for developers is a command like this: apache[2]ctl graceful|restart Do NOT do your development under mod_python! That is _NOT_ what it's intended for. --~--~-~--~~~---~--~~ 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: Why hardcoded unique and db_index?
On Apr 6, 7:18 am, MS wrote: > The OneToOneField's comment tells that `unique` is hardcoded, but it > sounds more like a definition, not an explanation WHY it's like that. UNIQUE CONSTRAINT If you removed the unique constraint from OneToOneFields, what would you get? You'd get a ForeignKey. Therefore removing the 'unique' constraint makes no sense whatsoever. If you believe you do not want a unique constraint, ask yourself why you desire to use OneToOneField and not ForeignKey. INDEX I can see why you might decide you don't need an index to optimize accesses to the reverse relation.. if you know what you are doing (and please note that I have no reason to believe that you do.) Perhaps the ForeignKey constructor should check kwargs for a preference first? > So - to implement what I want, I replaced the 2 above lines with code > which makes the same values by default, but allows to do a change, > when a programmer wants it. > > Can you tell me if it's a good idea, or I should solve it some other > way Again for clarity: this is a good idea for the index on ForeignKey. This is a bad idea for the unique constraint on OneToOneField. > [snip] > ALTER TABLE `forum_forumthread` ADD CONSTRAINT > forum_id_refs_id_3869a6a3 FOREIGN KEY (`forum_id`) REFERENCES > `forum_forum` (`id`); > [/snip] > > Such 'foreign key' constraints create indexes in database (at least > mysql). Have you "snipped" the SQL that creates indexes? I see no indexes being created here. I see a constraint. Am I missing something? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
