couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@hahnca.com>
Subject Re: Sorting dates in CouchDB
Date Mon, 08 Oct 2012 20:14:23 GMT
> so I've always just felt more comfortable having them stored as dates to
begin with so there's no additional conversion process to extract those
year, month, etc values.

Whether you use numbers or strings it still needs to do a conversion from
json (a string) to a Date object.  For that matter it might be slower to
convert from the JSON number in a string to a Date than from a string to a
Date.  I have no idea of course.

I just realized I was thinking of code in the client.  Using a number for a
key lookup is probably faster.  I wonder if Couch stores the JSON as a
string in the DB or converted to binary.

On Mon, Oct 8, 2012 at 12:26 PM, Kai Griffin <kaig@resourceandrevenue.com>wrote:

> No, I'm not sure.  I can't help but think that at least in view indexing
> it's less expensive to use numbers than strings... but that's purely
> instinct and not based on knowledge of how erlang works - perhaps a
> hold-over from obsolete thinking on my part.  I'm often doing date calcs
> and grouping by years, months, week numbers, or quarters, etc... so I've
> always just felt more comfortable having them stored as dates to begin with
> so there's no additional conversion process to extract those year, month,
> etc values.
>
> On 08/10/2012 21:11, Mark Hahn wrote:
>
>>   I'd favour storing them as unix dates
>>>
>> I find it really useful to be able to read the dates in futon and debug
>> dumps.  Are you sure it's a lot slower?
>>
>> On Mon, Oct 8, 2012 at 12:02 PM, Kai Griffin <kaig@resourceandrevenue.com
>> >**wrote:
>>
>>  Hi Carl,
>>> If I were storing dates, then I'd favour storing them as unix dates
>>> (which
>>> are long integers), not strings; not least because it's more efficient,
>>> but
>>> also because you leave the door open to doing something more interesting
>>> with the dates down the track without having to parse them to/from
>>> strings
>>> first.  That said, I think your start key should find the first
>>> 2012-10-02
>>> successfully, but your end-key would only find up to 2012-12-01T23:59:59
>>> (note that's 1 Dec, not 2 Dec), because there is no expiry date exactly
>>> matching just 2012-12-02.  Since your query returned no rows at all,
>>> maybe
>>> the endkey is failing entirely; not sure why that would be.
>>> Cheers,
>>> Kai
>>>
>>> On 08/10/2012 11:21, Carl Bourne wrote:
>>>
>>>  Hi I just wanted to sanity check what I'm doing here.
>>>>
>>>> I have a bunch of documents stored in Couch with expiry dates like this:
>>>> "expire": "2020-07-28T15:13:00+00:00"
>>>>
>>>> I have a simple map function defined like this:
>>>>
>>>> function(doc) {
>>>> emit(doc.expire);
>>>> }
>>>>
>>>> I'm then querying the data ranges like this:
>>>> ?startkey="2012-10-02"&endkey=****"2012-12-02"
>>>>
>>>> Is this the correct way to do this type of thing?
>>>>
>>>> Regards,
>>>>
>>>> Carl
>>>>
>>>>
>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message