On Oct 16, 8:29 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
> My idea (implemented in my local version of Django) was to
> modify RegexURLResolver to return the urlpattern that was used, and
> store that (as well as the kwargs) as a property of the request.
>
> Does this seem like a useful patch? O
Hey Steve,
Thanks for the suggestions. Setting aside the matter of using extends
vs. include, or using data-driven menus vs. hardcoded menus, the key
issue is how to figure out which of the links corresponds to the
current page.
>From your code sample, it looks like you're comparing request.path
Amit Upadhyay wrote:
> 1. make sure none of your apps do db writes on GET. [It was the case
> with my entire project already, other than one case, which was trivial
> to work around].
> 2. Use non db session backend.
> 3. Not use auth messages. [This presented some problems for me, but I
> had luc
On Fri, Oct 17, 2008 at 7:10 PM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
>
> Amit Upadhyay wrote:
>> The crux of that solution is the middleware:
>>
>> def process_request(self, request):
>> state = request.method in ['GET', 'HEAD'] and 'slave' or 'master'
>> connection.use_s
How about we raise a validation error on UNIQUE CharField fields
greater than 255 characters for all MySQL 5.0 implementations.
I think the docs should be updated as well telling people that it's
not best practice to use CharField for fields that need more than 255
characters (or at least put a n
Amit Upadhyay wrote:
> The crux of that solution is the middleware:
>
> def process_request(self, request):
> state = request.method in ['GET', 'HEAD'] and 'slave' or 'master'
> connection.use_state(state)
>
> Which is same as what I am talking about.
I feel obliged to corr
On Fri, Oct 17, 2008 at 6:07 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> > I do not understand, when everywhere django tries so very hard in a
> > pragmatic sense to decouple things where it logically makes sense, then why
> > suddenly an ideological outburst of "because we are not violating an
Malcom,
Thanks for the well-explained response. It's a bit more complicated
than that though as this is only an issue if the field uses a UNIQUE
index. It is an issue up through the latest and greatest stable MySQL
(tested on 5.0.45 and no bug fixes at MySQL up through 5.0.67) and "./
manage.py
On Fri, Oct 17, 2008 at 7:10 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> To reiterate, I am proposing: "avoid, and if not possible, document" for DB
> updates in GET, are you really saying you are against this? Is your logical
> position "encourage" or "don't care/document"?
To reiterate, I am
On Fri, Oct 17, 2008 at 4:03 PM, James Bennett <[EMAIL PROTECTED]>wrote:
>
> On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> > Either this becomes a django standard, every code that might update
> database
> > on GET doing something like:
> >
> > connection.use_
On Wed, Oct 15, 2008 at 6:38 PM, Jesse Young <[EMAIL PROTECTED]> wrote:
> * Existing apps might rely on it being a function. But it's not
> documented anywhere, so it doesn't seem like apps should be using it
> directly.
I don't know about *should*, but some apps *are*[0]. This would break
backwa
On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Either this becomes a django standard, every code that might update database
> on GET doing something like:
>
> connection.use_master()
> try:
> ... # something that updates db
> finally
On Wed, Oct 15, 2008 at 9:25 PM, bo <[EMAIL PROTECTED]> wrote:
>
> It seems that what you may want is something like
>
> http://softwaremaniacs.org/soft/mysql_replicated/
The crux of that solution is the middleware:
def process_request(self, request):
state = request.method in ['GE
Good news.
I'm sure there are tickets for this but I see a lot of breakages when
grouping fields into fieldsets. Labels in particular tend to be oddly
spaced and SELECT's often wrap to a different line to their label.
On Oct 16, 9:35 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On Thu, Oc
14 matches
Mail list logo
