2009/1/7 Malcolm Tredinnick :
>
> I'm also thinking that requiring evidence of people walking across hot
> coals in order to use an application is probably a good pre-requisite
> for inclusion in django.contrib.
>
+1
The gmail ads are conveniently offering me 'Firewalk Teacher Training'
and 'Find
On Wed, 2009-01-07 at 12:57 -0700, Jeff Anderson wrote:
> One of the most requested features/howtos/how-comes/why-nots that show
> up on the Django users list is Access Control Lists, or row-level
> permissions. Almost always, the question is about how to get the admin
> app to use them. This is o
On Wed, 2009-01-07 at 13:28 -0800, Justin Bronn wrote:
[...]
> I'm -1 on moving conversion operations from the Query class to the
> backend. However, I'd be +1 if Query.convert_values is kept -- even
> if it's just a wrapper around self.connection.ops.convert_values. If
> the conversion functio
Another problem that occured to me is precisely that, F() objects are trees,
so what happens when I do:
Model.objects.filter(field=F('related_model1__field')+F('related_model2__field'))
clearly the process for adding in calls to setup_joins() gets a little more
complex. Hopefully I'll have some
On Thu, Jan 8, 2009 at 1:36 AM, Alex Gaynor wrote:
> I've spent some time looking at this trying to implement expansion of
> related fields as Russ and I discussed last night. I have a few questions
> about the design choice that was implemented, why didn't you choose to go
> with this evaluator
On Jan 8, 6:57 am, Jeff Anderson wrote:
> One of the most requested features/howtos/how-comes/why-nots that show
> up on the Django users list is Access Control Lists, or row-level
> permissions. Almost always, the question is about how to get the admin
> app to use them. This is outside of the
On Wed, Jan 7, 2009 at 7:46 AM, Russell Keith-Magee
wrote:
> There is some potential for further refactoring here, especially with
> regards to the decimal/datetime conversion routines. The Oracle
> DatabaseOperations.convert_values() function that I added for
> aggregate support is an almost per
> Refactoring Query.convert_values() into the backend operations would
> remove some code duplication, and would also serve to keep all the
> data coercion/typecasting code in a common location rather than
> spreading some of it into the Query class. However, there are two
> things that prevented
The solution to the fact that aggregate mutates the query is to have
aggregates() do self._clone() like all the other queryset methods do(not
sure how we missed this).
My guess as to why the odd typecasting occurs is because the `is_computed`
check occurs because the check for DecimalField. When
On Wed, Jan 7, 2009 at 8:55 AM, Karen Tracey wrote:
> On Wed, Jan 7, 2009 at 9:46 AM, Russell Keith-Magee
> wrote:
>>
>> I've just pushed some updates to Github that should hopefully fix the
>> problems that have been reported (ORA-00933, ORA-00923 and ORA-00972
>> and the decimal/datetime conve
On Jan 7, 9:59 pm, "Alex Gaynor" wrote:
> 1.1 is not 8 days away, the 1.1 major feature freeze, this means items that
> are new features on the 1.1 features list.
/me puts on a brown paper bag. Right, feature freeze and bug fixing
are different things.
Can we perhaps agree on a set time when pe
1.1 is not 8 days away, the 1.1 major feature freeze, this means items that
are new features on the 1.1 features list. 1.1 final doesn't ship until
mid-March, which is quite a bit of time considering that starting on
February 15th the only changes that will occur will be bug fixes.
Alex
On Wed,
One of the most requested features/howtos/how-comes/why-nots that show
up on the Django users list is Access Control Lists, or row-level
permissions. Almost always, the question is about how to get the admin
app to use them. This is outside of the scope of the admin app, and
that's usually the answ
On Jan 7, 11:56 am, "Alex Gaynor" wrote:
> I'd like to remind everyone that the policy for bugs is to fix them, they
> don't all need to be listed, because the goal is to fix them all.
Let me remind everybody that 1.1 is officially only 8 days away. The
goal is clearly not achievable in that tim
Done:
http://code.djangoproject.com/ticket/9983
Thank you very much.
Adrian Holovaty escribió:
> On Wed, Jan 7, 2009 at 9:50 AM, Matias Surdi wrote:
>> To solve this, I modified
>> ./django/contrib/admin/templates/admin/prepopulated_fields_js.html
>>
>> replacing the event "onkeyup" on line
Yes, please do open a ticket for those.
Alex
On Wed, Jan 7, 2009 at 11:37 AM, Luke Graybill wrote:
> I hadn't intended to come off like an ingrate or be dismissive in my post,
> and I apologise for sounding that way; I was frustrated when I wrote it,
> which was a mistake. I have great respect
I hadn't intended to come off like an ingrate or be dismissive in my post,
and I apologise for sounding that way; I was frustrated when I wrote it,
which was a mistake. I have great respect for the development efforts for
Django, and the polite comments in response to my post have only increased
th
Lets get this into 1.1 ;)
-dave
On Sat, Jan 3, 2009 at 7:02 PM, Brantley Harris wrote:
>
> On Sat, Jan 3, 2009 at 5:25 PM, Russell Keith-Magee
> wrote:
> >
> > On Sun, Jan 4, 2009 at 4:28 AM, Brantley Harris
> wrote:
> >> Ah yes, this is definitely a problem. See, I had to be able to import
>
I've spent some time looking at this trying to implement expansion of
related fields as Russ and I discussed last night. I have a few questions
about the design choice that was implemented, why didn't you choose to go
with this evaluator class in place of a mechanism more similar to the way
aggreg
On Wed, Jan 7, 2009 at 9:50 AM, Matias Surdi wrote:
> To solve this, I modified
> ./django/contrib/admin/templates/admin/prepopulated_fields_js.html
>
> replacing the event "onkeyup" on line 5 for "onchange".
>
> Do you think this change could be applied to trunk? Do you want me to
> submit a tic
On Wed, Jan 7, 2009 at 9:46 AM, Russell Keith-Magee
wrote:
> I've just pushed some updates to Github that should hopefully fix the
> problems that have been reported (ORA-00933, ORA-00923 and ORA-00972
> and the decimal/datetime conversion problems). If someone with access
> to an Oracle test mach
I've noticed that if you have a ModelAdmin with the prepopulated_fields
attribute set to:
prepopulated_fields = {"object_identifier": ("object_type",)}
where the field "object_type" is a dropdown box (that is, has a
choices=CHOICES argument) then the javascript that autofills the
"object
Ramiro Morales schrieb:
> What directions do [the rest of the] core devs think should this
> take?
I am not a core dev, but here is what I think:
- The current user based messages are not usefull for me.
- I use a own version of session based messages which is based
on code of this ticket. But
I'm working on a backend for MS-SQL server 2000 with pretty good
success so far, but I'm having trouble understanding one of the test
cases in the Django test suite.
In tests/modeltests/mutually_referential/models.py, there's a doctests
that reads:
---
# Create a Parent
>>> q = Parent(name='Eliz
Hi Malcolm,
Thanks for your input. I can certainly understand your perspective of
wanting to keep the maintenance burden for Django to a minimum.
Sorry about the formatting. I didn't realize it wouldn't translate so
well into the mailing list post. I'm new to the open source world
(that's probab
On Wed, Jan 7, 2009 at 7:45 AM, Russell Keith-Magee
wrote:
> On Wed, Jan 7, 2009 at 4:19 AM, Ian Kelly wrote:
>>
>> On Tue, Jan 6, 2009 at 12:14 AM, Ian Kelly wrote:
>>> On Mon, Jan 5, 2009 at 9:21 AM, Alex Gaynor wrote:
The SQL command not properly ended appears to be the result of an an
I'd like to remind everyone that the policy for bugs is to fix them, they
don't all need to be listed, because the goal is to fix them all.
Alex
On Wed, Jan 7, 2009 at 3:47 AM, Tai Lee wrote:
>
> I'd also love to see 8898 committed. It looks to be a fairly straight-
> forward bug fix, at least
I'd also love to see 8898 committed. It looks to be a fairly straight-
forward bug fix, at least to me.
http://code.djangoproject.com/ticket/8898
Cheers.
Tai.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
On Jan 7, 3:43 am, Malcolm Tredinnick
wrote:
> On Tue, 2009-01-06 at 15:38 -0800, Killarny wrote:
> > There are many instances where, in a complicated implementation of
> > views, one might want to have a combination of required args and
> > optional kwargs, and the inability to mix them introduc
29 matches
Mail list logo
