Re: What The Enterprise wants from Django

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

Re: Model validation incompatibility with existing Django idioms

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

Re: Model validation incompatibility with existing Django idioms

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!

Re: What The Enterprise wants from Django

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

Feedback requested: Multi-db database routing

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

Re: What The Enterprise wants from Django

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

Re: What The Enterprise wants from Django

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

Re: What The Enterprise wants from Django

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

Re: What The Enterprise wants from Django

> 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

Re: What The Enterprise wants from Django

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

Re: Feedback requested: Multi-db database routing

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

Re: What The Enterprise wants from Django

> 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

TimeField for duration

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:

Re: TimeField for 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.

Re: TimeField for duration

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

Re: TimeField for duration

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.

Re: TimeField for duration

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

Re: TimeField for duration

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

Re: TimeField for duration

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

Re: TimeField for duration

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

Re: TimeField for duration

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

Re: TimeField for duration

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

Re: TimeField for duration

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 >

Re: TimeField for duration

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.

Re: TimeField for duration

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

Re: TimeField for duration

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 >>>

Re: What The Enterprise wants from Django

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

Re: TimeField for duration

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

Re: Feedback requested: Multi-db database routing

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,

Re: What The Enterprise wants from Django

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 --