emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-develo
an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/377b
d an
> email to django-developers+unsubscr...@googlegroups.com.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+u
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email
oup and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
ht
Since the admin is turned on by default, should there be a admin.py template
file in the app template as well?
Ryan
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
k, forcing all feature work out to branches. In
>> practice, this meant months-long periods where new features couldn't
>> be merged, and led to some stuff withering on the vine.
>>
>> That's not going to happen this time. Instead, when we release 1.5
>>
> In 1.7 we could raise a loud exception when stream_content=True and
> response.content is accessed directly. Middleware can do nothing if they
> don't care about or need to worry about streaming responses. If they are
> capable of functioning with a streaming response, they can check
> respon
On May 18, 2012, at 12:19 PM, Anssi Kääriäinen wrote:
> I do not want us to have single commit per pull request. Instead I
> would like to see nice clean logical commits. These make bisecting as
> easy as possible. So, we mostly agree here.
My feeling is that we want every commit in the main tree
you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/lTBhIYzL5A4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email
I think that Django's admin app is a killer feature for two main reasons:
1. It is automatically installed, and integrated into the tutorial.
2. It is used all over in third-party apps, because they can expect it to be
there.
While I appreciate that there may be differences in core vs admin that
ssage because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/v_5hqdvT3LUJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this gr
le Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/HdK-7gZdmSsJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr
there is consensus that it's a worthwhile idea. Thanks.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/9-6LEMDkYqoJ.
To post t
en pretty deeply involved in exploring this
issue as well, so he might have some perspective or opinion of his own he'd
like to share.
If i flubbed any of the above or anyone requires clarification please do let
me know. Apologies for the lengthy post but hopefully it was all pertinent
big picture can help me see this
through the last mile. Aside from the minor details above, this should be
ready for checkin.
Thanks!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
h
to point me in the right direction.
Otherwise, if there is interest I'd be happy to open a ticket and get a
patch started.
Thanks
Jim
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
On Monday, June 27, 2011 7:04:09 PM UTC-7, Jim D. wrote:
So that caveat aside, I will try later to find a large data set I can run
> the query on to get an idea of what kind of performance hit the check
> entails. If anyone else has a large data set with two related tables, you
> c
s and we're all in agreement with the philosophical
approach of the solution, I think it should be a fairly uncontroversial
commit, since it's really primarily a fixture loading issue at its core.
--
You received this message because you are subscribed to the Google Groups
Hi all,
I spent some time last week and over the weekend nailing down a
solution for https://code.djangoproject.com/ticket/3615 . This is the
ticket about allowing forward references when loading data on the
MySQL InnoDB backend. My patch implements the proposed change
(disabling foreign key check
On May 11, 9:47 pm, Mathieu AGOPIAN wrote:
> Just to make sure i've understood the topic here: you need to change
> MAX_SHOW_ALL_ALLOWED, but only for a specific model?
>
> Otherwise you could just add something like that to, say, the root urlconf:
>
> from django.contrib.admin.views import main a
I'm looking at a five-year-old ticket here (http://
code.djangoproject.com/ticket/1342) that suggests MAX_SHOW_ALL_ALLOWED
in the admin be configurable. As of now it is hard coded at 200 in
contrib/admin/views/main.py .
The ticket is, in my opinion, somewhat erroneously marked as "fixed",
as someo
I have a project running in Django 1.2.5 and I want to update it (the code)
to Django 1.3. I've seen the release notes, but there is no direct
instructions to *what I have to change in the code*.
It would be very useful to me, to all the community (I know that a lot of
people may be in the exact s
> On Sat, Jan 22, 2011 at 2:27 PM, Jim D. wrote:
> > Howdy,
>
> > I reported a bug earlier today (http://code.djangoproject.com/ticket/
> > 15144) related to a possible regression in changeset 15021 (http://
> > code.djangoproject.com/changeset/15021). The apparen
Howdy,
I reported a bug earlier today (http://code.djangoproject.com/ticket/
15144) related to a possible regression in changeset 15021 (http://
code.djangoproject.com/changeset/15021). The apparent regression is
that as of this changeset, the cache middleware no longer respects the
timeout value
Howdy,
Just wanted to see if anyone wanted to do a quick review of the patch
I submitted for #15026: http://code.djangoproject.com/ticket/15026
The ticket in question refers to a failure in contrib.session tests
when memcached is specified as the cache backend.
i had suggested clearing the cache
Cool, thanks
On Sep 20, 3:30 pm, Carl Meyer wrote:
> Thanks for your work on this! The usual Django workflow doesn't
> include patches to the mailing list: rather you can go ahead and open
> a Trac ticket and attach the patch there (even if you aren't sure of
> the approach yet), and reference t
I found some time this evening to work this out, and have included a
revised patch for this proposal at the end of this message.
I tried to keep changes to an absolute minimum, but here are a few
notes about the changes and decisions I did make:
* The addition of this feature required what I imag
Thanks for the suggestions and guidance Russ. I'll work with it a bit
more and see if it pans out.
My main concern with this working smoothly in the core has to do with
when and how application code is loaded in the process of setting up
tests. It turns out the earliest we can realistically send t
I recently asked a question on Django Users related to executing
certain code during the global setup and teardown routines that run in
Django's test runner. In my particular use case, I was looking for a
hook where I could disable some third party API code when tests
execute, in much the same way
I found the Actions feature soon after my posting, I was a little
hesitant to update to a beta version though.
The feature works well and with the filter search I can at least
narrow down what could possibly be a very large list.
Thanks
--~--~-~--~~~---~--~~
You re
My first django application is a very basic tool for modifying data. I
have no need to a public interface since its all administration stuff.
The application will allow the user to create/edit/save data into a
database. One feature I'd like to add is the ability to "publish".
What publish will do
default, and add a configuration setting that
forces use of pysqlite2 if desired.
B. Always try both sqlite3 and pysqlite2, and use whichever has the
greater version number if both are present.
C. Same as B, but with an optional configuration option to force one
or the other if desired.
D
[EMAIL PROTECTED] wrote:
> Matthew, would you mind sticking the script you used to test this up
> on dpaste?
I'd love to, but it wasn't really a script per se, so much as a hodge-
podge that involved twiddling the server, restarting it, running some
tests, changing the server config again, and
On Nov 16, 11:03 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> I know this is a horribly nebulous question (like all benchmarking),
> and it's completely dependent on the speed of your machine and a
> million other factors. However, if we are going to start adding
> signals to very commo
Hi all,
I've been playing with adding sqlite3 back-end support to GeoDjango,
using the SpatiaLite extension. This requires executing some magic
SQL each time you connect to the database, to enable the spatial
extensions. Ticket #6064 seems like this right way to do this, by
causing the
e:<
The same happens if I simply display form fields.
What can I do?
Can somebody please help? Do you need more information?
Thak you very much!
d.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
Hi guys
Following up on a previsous discussion:
http://groups.google.com/group/django-developers/browse_thread/thread/4c7b2ce86bcd990e/3731676c2134ea63
I've submitted a (rought) patch:
http://code.djangoproject.com/ticket/7158
Fell free to comment, improve etc.
-
aD
--~--~-~--~~---
ue something like (0, 96, 1) for
(major_version, minor_version, patch_level) or something
like that (probably with a better name than patch_level,
I don't know exactly what the Django semantics are
for the different parts of the versio number).
Any thoughts?
Peace,
Andrew
--
==
On Dec 14, 2007 11:48 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> How do we go about setting up a new mailing list on google groups?
Go to http://groups.google.com/ and click 'Create a group...' Then you just
need:
1. Group name
2. Group email address (@googlegroups.com)
3. Group description
This simple data model makes it impossible to display 'C' instance
list in admin pages (loads forever : eats up all memory) :
** content of models.py **
from django.db import models
class A(models.Model):
b = models.ForeignKey("B")
class B(models.Model):
i_a = models.ForeignKey(A, rela
Hi,
Trying to sum up the discussions so far I would say that Wolfram's
syntax seems to be the preferred one : i.e. letting the logic go into
the translated string but keeping the strings to translate in one bit.
I wasn't that in favor of this solution at first but I confess I'm
much more convin
Hi,
First, I'd like to thank all people involved in this discussion for
the quality of the insightful remarks and reactions they made on my
first proposed syntax.
I'm trying to imagine improvements to my proposed syntax based on
the comments here ... unfortunately, I always find good reason
Hi,
I agree that my proposed syntax was a little bit horrible ... but I
really wonder if it can be different.
Your syntax is interesting but :
- I'm not sure it's really "djangoic" in the sense that it introduce
a new way to declare markup '[[' and ']]'
- the other problem I see is that it
Hi,
Following up on a previous discussion about an important but
complex i18n missing feature :
http://groups.google.com/group/django-developers/browse_thread/thread/c88b582fa4764aaa
I've been thinking over and over about the problem and came up with
an idea of a proposed syntax that I want
Hi,
Back again on the django missing i18n feature in template (see
thread :
http://groups.google.com/group/django-developers/browse_thread/thread/c88b582fa4764aaa/665af6639a099ec8
)
Is there any impovements/thoughts on this ?
Maybe I should post a trac entry just not to forget this (?)
--
AD
Hi again,
I would be happy to know you're impressions about the above
explanation ... if I made my point clear or not, or if you have any
objection why this would not be a useful feature ...
Regards,
--
AD
--~--~-~--~~~---~--~~
You received this message beca
I'm not sure if this could be easily integrated into django's
translation mecanism ... but I'm pretty convinced a feature is
missing :
The thing is that you want to render a sentence like "go to the page
registration form" with a link on "registration form" ... but you dont
want the translated se
Hi,
Thanks a lot for the response.
Actually, I "dare" to reply here because I think what follows might
be a hint for the developers if they agree that the feature I'm
talking about is worth a look.
Such a translation feature is for instance available in Zope/Plone
translation mecanism : h
Hi,
After taking a look at the django translation mecanism, I did not
find a feature (I think) that is mandatory for what I'm trying to do :
I'd like to have a translatable message that displays (in a page)
something like :
"This has been done by the user xxx" ... and of course, the "xxx" is
orking *around* django instead of with it.
Don't get me wrong, we love django and it is great for 75% of everything
out there but highly advanced database applications that require the
other 25% Django maks it a pain in the arse.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Comp
at the following:
http://www.modernmethod.com/sajax/
I would be curious as to all of your thoughts on its comparison to the
others mentioned above.
Joshua D. Drake
that has
to be a 1.0 rev type thing.
Joshua D. Drake
Maybe others have
grandiose plans for transaction support, but again, ISTM that's all we
really need. The developer gets to choose, and -- paradigmatically
speaking -- it's no different or less powerful than transaction usage
in
ociated
to multiple tables, I expect that if all the data is required within the
form , all the data
will make it into the database, or none will. Otherwise I end up with
inconsistent data which
is a big no no.
Sincerely,
Joshua D. Drake
Anybody have ideas on implementations? Let's
at all. If you don't want to use ACLs
you shouldn't have to.
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedi
think it is a maybe for django users/developers. If Django wants
to take off it is going to need some type of ACL otherwise people are
just going to develop their own and you will end up with a bunch of
different implementations.
Sincerely,
Joshua D. Drake
>
> Regards
>
> Laurent.
Hello,
Thought I would throw a bone out there and ask what it would take to get
transaction
support finished up?
Is there anything we can do to enhance the priority of the feature?
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
57 matches
Mail list logo
