On 01/21/2010 01:31 AM, Ian Kelly wrote:
> In other words, all the same limitations that we already handle for
> TimeFields. This looks to me like a green light to just use the
> native datatypes.
I wrote a simple DurationField for my own purpose, it is not meant to be
included in Django as-is,
On 01/21/2010 01:31 AM, 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
>>> with mic
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
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/
17 matches
Mail list logo
