On Thu, Jan 21, 2010 at 2:54 AM, Jacob Kaplan-Moss wrote:
> On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote:
>> I don't understand how avoiding the settings.py mechanism will produce
>> *more* flexibility.
>
> The problem -- at least as I see it -- is that of a intertwingulment
> of "applicati
On Thu, Jan 21, 2010 at 3:59 AM, Jacob Kaplan-Moss wrote:
> On Wed, Jan 20, 2010 at 10:06 AM, Russell Keith-Magee
> wrote:
>> Ok - so that's the patch. Any comments, queries, or criticisms are welcome.
>
> I'm happy -- +1.
>
> One thing, to point out, though, is that this continues the slow
> pro
On 2010-01-20, at 5:59 PM, Honza Král wrote:
> Another problem that we have is error reporting. If your project blows
> up and starts generating hundreds of error messages per second, you
> really don't want then on your mailserver or mail client. It is also
> solvable with django's current tool s
On Wed, Jan 20, 2010 at 7:54 PM, Jacob Kaplan-Moss wrote:
> On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote:
>> I don't understand how avoiding the settings.py mechanism will produce
>> *more* flexibility.
>
> The problem -- at least as I see it -- is that of a intertwingulment
> of "applicati
On Wed, Jan 20, 2010 at 5:33 PM, Alex Gaynor wrote:
> Ian,
>
> FWIW there's a ticket with a patch (of unkown quality :P) for support
> for using timedeltas with F() expressions.
>
> Alex
I know, I wrote the Oracle backend code for it. :-)
I'm not talking here about passing in literal timedeltas
Using djangorecipe and zc.buildout offer your exactly that kind of mechanism.
You write the name of settings of choice in your buildout:
[django]
recipe = djangorecipe
version = 1.1
settings = development
eggs = ${eggs:eggs}
wsgi = true
project = project
And after that you can have by example an
On Wed, Jan 20, 2010 at 6:31 PM, Ian Kelly wrote:
> 2010/1/20 Łukasz Rekucki :
>> 2010/1/21 Jerome Leclanche :
>>> Hi Lukasz, thanks for the wrap up
>>>
>>> Main issue is precision. I personally very, very often work with
>>> milliseconds, and I can imagine many use cases where I'd need to work
>>
2010/1/20 Łukasz Rekucki :
> 2010/1/21 Jerome Leclanche :
>> Hi Lukasz, thanks for the wrap up
>>
>> Main issue is precision. I personally very, very often work with
>> milliseconds, and I can imagine many use cases where I'd need to work
>> with microseconds. How many of these backends do not at l
On 01/21/2010 12:58 AM, Jerome Leclanche wrote:
> Which is exactly what I'm doing using a BigIntegerField...
AFAICS you are doing this for your new DurationField. If you do so, then you
should also modify the current TimeField for better precision, so that it is
coherent with this DurationField. I
2010/1/21 Jerome Leclanche :
> Hi Lukasz, thanks for the wrap up
>
> Main issue is precision. I personally very, very often work with
> milliseconds, and I can imagine many use cases where I'd need to work
> with microseconds. How many of these backends do not at least support
> millisecond precisi
Which is exactly what I'm doing using a BigIntegerField...
J. Leclanche / Adys
On Thu, Jan 21, 2010 at 1:57 AM, Olivier Guilyardi wrote:
> On 01/21/2010 12:44 AM, Jerome Leclanche wrote:
>>
>> Main issue is precision. I personally very, very often work with
>> milliseconds, and I can imagine ma
On 01/21/2010 12:44 AM, Jerome Leclanche wrote:
>
> Main issue is precision. I personally very, very often work with
> milliseconds, and I can imagine many use cases where I'd need to work
> with microseconds. How many of these backends do not at least support
> millisecond precision?
If you want
Hi Lukasz, thanks for the wrap up
Main issue is precision. I personally very, very often work with
milliseconds, and I can imagine many use cases where I'd need to work
with microseconds. How many of these backends do not at least support
millisecond precision?
J. Leclanche / Adys
2010/1/21 Łu
This is going to be extremely inconsistent between databases. Feel
free to base yourself on my patch, but good luck implementing 4-5
implementations and keeping them abstract...
J. Leclanche / Adys
On Thu, Jan 21, 2010 at 1:36 AM, Olivier Guilyardi wrote:
> On 01/21/2010 12:14 AM, Jerome Lecla
Hi, if i'm wrong, please ignore this post ;)
2010/1/21 Jerome Leclanche :
> A decimal backend was a lot worse than a bigint backend on that matter
> (slower, made a lot less sense as well).
>
> Keep in mind, TIME fields are for storing time, not for storing
> durations. For durations, postgres has
On 01/21/2010 12:14 AM, Jerome Leclanche wrote:
> Keep in mind, TIME fields are for storing time, not for storing
> durations. For durations, postgres has an INTERVAL field (cf ticket),
> however not every database has that field type.
Not in MySQL, from the official docs:
"TIME values may range
A decimal backend was a lot worse than a bigint backend on that matter
(slower, made a lot less sense as well).
Keep in mind, TIME fields are for storing time, not for storing
durations. For durations, postgres has an INTERVAL field (cf ticket),
however not every database has that field type. Pers
On 01/20/2010 11:46 PM, Jerome Leclanche wrote:
>
> I've worked on a DurationField implementation (ticket:
> http://code.djangoproject.com/ticket/2443). However I was extremely
> displeased with the whole DecimalField backend.
> With the recent addition of BigIntegerField, I am now saving duration
Hi Olivier
I've worked on a DurationField implementation (ticket:
http://code.djangoproject.com/ticket/2443). However I was extremely
displeased with the whole DecimalField backend.
With the recent addition of BigIntegerField, I am now saving durations
with a bigint and mapping them to timedelta.
Hi everyone,
Django TimeField is mapped to Python datetime.time. That doesn't fit my needs
since I must deal with durations, which can exceed 24h, and datetime.time can't
do that.
On the MySQL side, TimeField is mapped to the MySQL TIME column type, which is
correct IMO:
http://dev.mysql.com/doc/
> I don't understand how avoiding the settings.py mechanism will produce
> *more* flexibility.
Bad choice of words on my part, sorry. Of course code is always more
flexible than static data.
The two key bits of required 'flexibility' I didn't have out of the
box (and were difficult to hack and ge
On Wed, Jan 20, 2010 at 10:06 AM, Russell Keith-Magee
wrote:
> Ok - so that's the patch. Any comments, queries, or criticisms are welcome.
I'm happy -- +1.
One thing, to point out, though, is that this continues the slow
process of making `Model._meta` a de facto public API -- without being
able
On 2010-01-20, at 10:54 AM, Jacob Kaplan-Moss wrote:
On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant
wrote:
I don't understand how avoiding the settings.py mechanism will
produce
*more* flexibility.
The problem -- at least as I see it -- is that of a intertwingulment
of "application" settin
> A lack of any mechanism for developers to understand what third party
> apps are reliable, what to avoid, known problems, and so on. This has
> been a particular complaint since the Django ethos is (rightly) that
> the core is the core, and other functionality should be packaged into
> third part
On Wed, Jan 20, 2010 at 12:31 PM, Luke Plant wrote:
> I don't understand how avoiding the settings.py mechanism will produce
> *more* flexibility.
The problem -- at least as I see it -- is that of a intertwingulment
of "application" settings with "ops" settings.
As organizations get larger, role
On Wednesday 20 January 2010 17:15:39 sago wrote:
> Startup and Settings are the big killers though, head and shoulders
> above the previous issues. I've nothing much to add to your
> comments other than to say that some of the Django deployments I
> know of are highly heterogeneous, with variou
I also work with several fortune 500 clients (though not specifically
as a Django consultant, Django is a preferred tool) and the issues
your client mentions, Jacob, are very similar to those I deal with.
Some other notes from the concerns of multinational clients:
I've had one very long and comp
Hi all,
I've just uploaded a new patch improving the multi-db interface. This
patch introduces a way to easily configure the database selection
process, and enables you to assign a database selection mechanism to
models not under your control (e.g., changing database usage for the
contrib.auth app
On Jan 19, 4:26 pm, Jacob Kaplan-Moss wrote:
> The next big one was the "startup signal" issue -- they've got lots of
> code that needs to run at startup time, and there's no great mechanism
> to do that currently. The core devs have talked about this one a *lot*
> over the years, and it's obvious
Joseph Kocherhans wrote:
> Ok. I see it. ;)
:D
> Sorry, I've been out of town for a while with no
> internet access. 12577 is near the top of my list to look at.
ok thanks :D
--
()_() | That said, I didn't actually _test_ my patch. | +
(o.o) | That's what users are for!
On Tue, Jan 19, 2010 at 1:04 AM, Raffaele Salmaso
wrote:
> Raffaele Salmaso wrote:
>> Joseph Kocherhans wrote:
>>> regressions?
>> http://code.djangoproject.com/ticket/12577
> Hello, is anybody out there?
> Sorry if I seem rude, but there is a severe regression an no one care to
> say at least 'ok
Startup signal - when using mod_wsgi the wsgi init app can be a good
place to call the startup work, starting threads, setting logging
level etc. It worked for me, but it's probably much simpler than a
complex corporate deployment.
On Jan 19, 11:26 pm, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> I
32 matches
Mail list logo
