Hi Vernon and all,
On Friday 17 May 2013, VernonCole wrote:
> Shai:
>
> I think that you are showing how rotten this whole "paramstyle" mess is:
> the thing you are describing is, IIUC, "pyformat" paramstyle. "named" uses
> a ":name" SQL statement syntax, and expects a mapping of parameters.
Oopsie:
On Sunday 19 May 2013 08:12:12 Shai Berger wrote:
> ...They do pass on our CI [0],...
http://ci.djangoproject.com/job/Django%20Oracle/lastCompletedBuild/database=oracle,python=python2.7/
Thanks,
Shai.
--
You received this message because you are subscribed to the Google Groups
On Saturday 18 May 2013 19:49:58 Shai Berger wrote:
>
> I'm toying with a different solution now -- removing the date casting on
> Oracle too. It passed the lookup tests, now I'm running the whole suite
> (that takes a little time). After seeing that no other backend in core
> does it, and as we d
Hi all,
This is a proposal for fixing this small and old issue
(https://code.djangoproject.com/ticket/9321):
Model forms for models that include a ManyToMany field get a hard-coded
"*Hold down "Control", or "Command" on a Mac, to select more than one."
sentence in the respective help text
This
Hey Luke -
Yup, this is indeed a problem. It's actually the subject of a Summer
of Code proposal [1], so if you can wait there's a good chance that
you won't have to do any work yourself :)
Jacob
[1]
https://groups.google.com/forum/#!msg/django-developers/e0-rOIkrXaQ/w5aiW_R6aFYJ
On Sat, May 1
Good afternoon,
I am currently working on writing a small number of subclasses to
`models.Field`. As part of doing this, I wanted to add validation to how those
fields are instantiated, and discovered that I think it can't be done. Assuming
I'm right, I'd like to fix it.
Here's the use case. Sa
There's already a patch on the ticket tracker for a pre_syncdb signal, and
yesterday I started updating it and modifying it a bit as I needed this signal.
https://github.com/dstufft/django/compare/pre-syncdb-signal
On May 18, 2013, at 1:06 PM, Karol Sikora wrote:
> I can try to implement appro
I can try to implement approach with pre_syncdb signal tomorrow. I think
that is quite enough solution before deeper diggling into new migrations
framework.
Karol
18 maj 2013 19:03, "Anssi Kääriäinen" napisał(a):
> On 16 touko, 11:20, Danilo Bargen wrote:
> > As a sidenote, there was a discussi
On 16 touko, 11:20, Danilo Bargen wrote:
> As a sidenote, there was a discussion about this on this mailing list a few
> months ago:
>
> https://groups.google.com/forum/#!searchin/django-developers/16550/dj...
I think a pre_sync signal is best approach. The signal should be
called either just aft
On Saturday 18 May 2013 19:35:31 Anssi Kääriäinen wrote:
> On 18 touko, 17:46, Shai Berger wrote:
> >
> > 1) The fixes I see would affect all backends, but AFAIK only Oracle is
> > reported as failing the test; anyone wants to comment on this? Do all
> > other backends just not need a cast_to_dat
On 18 touko, 19:04, Patryk Zawadzki wrote:
> As suggested by Marc Tamlyn I am posting this here for discussion:
>
> https://code.djangoproject.com/ticket/20448
>
> tl;dr:
>
> Currently __repr__() calls __unicode__() which can be a very bad
> thing. You really don't want things like an exception be
On 18 touko, 17:46, Shai Berger wrote:
> Hi django devs,
>
> While going through Oracle bugs, I ran into the ticket in the subject[0]. The
> problem there is that current code assumes that whenever we want to compare
> anything (pretty much) against a datetime column, in any way, we'd like to
> co
Hi Carl,
On Sat, 18 May 2013, Carl Meyer wrote:
I don't think this should be fixed in the test runner itself; in
general, file-path test labels _should_ be interpreted as relative to
wherever you are running the tests from.
But it should be fixed in the
test_runner.test_discover_runner.Disc
As suggested by Marc Tamlyn I am posting this here for discussion:
https://code.djangoproject.com/ticket/20448
tl;dr:
Currently __repr__() calls __unicode__() which can be a very bad
thing. You really don't want things like an exception being raised or
debugger being used to cause additional sid
Hi Chris,
On May 18, 2013, at 8:34 AM, Chris Wilson wrote:
> On Sat, 18 May 2013, Chris Wilson wrote:
>
>> I think Travis is unhappy about something in this commit. Any ideas?
>>
>> ==
>> ERROR: test_file_path (test_runner.tes
Hi Chris,
On May 18, 2013, at 9:42 AM, Chris Wilson wrote:
> Another odd behaviour of the new test runner. This runs the tests, but fails
> to add the test app to INSTALLED_APPS, so they all fail because their tables
> are not created:
>
>PYTHONPATH=.. python -Wall runtests.py --selenium -
Hi django devs,
While going through Oracle bugs, I ran into the ticket in the subject[0]. The
problem there is that current code assumes that whenever we want to compare
anything (pretty much) against a datetime column, in any way, we'd like to
compare the column value and the given value as da
Hi all,
Another odd behaviour of the new test runner. This runs the tests, but
fails to add the test app to INSTALLED_APPS, so they all fail because
their tables are not created:
PYTHONPATH=.. python -Wall runtests.py --selenium --verbosity 2 \
--settings=tests.travis_configs.test_pos
On May 18, 2013, at 8:57 AM, Marc Tamlyn wrote:
> I'm going to resurrect this old thread as I'd like to get it resolved in some
> fashion.
>
> I used to be very in favour of the class decorators approach. I've been using
> an implementation of `@class_view_decorator(func)` for some time and i
On May 18, 2013, at 5:15 AM, Aymeric Augustin
wrote:
> Apologies for answering so late. I see the change discussed here was already
> committed. The change itself is fine — essentially because it's limited to
> the bcrypt password hasher — but I'd like to bring some perspective to parts
> of
I'm going to resurrect this old thread as I'd like to get it resolved in
some fashion.
I used to be very in favour of the class decorators approach. I've been
using an implementation of `@class_view_decorator(func)` for some time and
it works pretty well. That said my implementation at least wa
On Sat, 18 May 2013, Chris Wilson wrote:
I think Travis is unhappy about something in this commit. Any ideas?
==
ERROR: test_file_path (test_runner.test_discover_runner.DiscoverRunnerTest)
--
Hi all,
On Fri, 10 May 2013, Carl Meyer wrote:
I merged this patch tonight. Thanks to everyone who contributed! Now
let's see how the CI servers feel about it...
I think Travis is unhappy about something in this commit. Any ideas?
=
Hello all,
Since Django 1.4, we've added GenericIPAddressField, next to IPAddressField.
The new GenericIPAddressField supports IPv4 as well as IPv6 addresses, and does
normalisation of IPv6 addresses. It can also be configured to only accept IPv4
or IPv6 addresses.
As far as I know, IPAddressF
Hi all,
On Thu, 7 Mar 2013, Jacob Kaplan-Moss wrote:
On Mon, Feb 25, 2013 at 4:48 PM, Florian Apolloner
wrote:
So all in all I think we could enable travis,
I agree, +1 from me.
One issue standing in the way: Travis will try to build any branch without
a .travis.yml file as though it was
Hi,
We was talked with Russell on djangocon eu about integrating more rich
support for working django as rest api provider, focused on dealing with
one-page web applications.
The motivations that currently without third party modules like
django-rest-framework or tastypie its quite impossible t
Carl Meyer skrev 2013-05-17 5:03 PM:
Hi Emil,
On May 16, 2013, at 5:21 PM, Emil Stenström wrote:
Any feedback on how I was thinking? Does it make sense?
Based on the feedback so far I gather that changing the block tag
is a bad idea. I'd love to continue working on this, because I've
felt thi
Apologies for answering so late. I see the change discussed here was already
committed. The change itself is fine — essentially because it's limited to the
bcrypt password hasher — but I'd like to bring some perspective to parts of
this discussion.
Overall, I strongly advocate consistency in th
28 matches
Mail list logo
