Persisting NSDate objects generates cbjson_encodeTo unrecognized selector error.

223 views
Skip to first unread message

Brendan Duddridge

unread,
Jun 12, 2015, 5:23:52 AM6/12/15
to mobile-c...@googlegroups.com
The docs say that CBLModel can handle serializing NSDate objects to store in the JSON document.

It seems perhaps that they can do that only on direct properties of the CBLModel subclass?

I am trying to persist an NSDate object that gets stored in an NSDictionary on my CBLModel subclass.

However, when I try to save, I get the following error:

-[__NSTaggedDate cbjson_encodeTo:canonical:]: unrecognized selector sent to instance


I believe the same thing would happen for some other data types too.

Is this a bug or am I doing something wrong? Or is it just not supported?

Thanks,

Brendan

Jens Alfke

unread,
Jun 12, 2015, 12:25:06 PM6/12/15
to mobile-c...@googlegroups.com

On Jun 12, 2015, at 2:23 AM, Brendan Duddridge <bren...@gmail.com> wrote:

It seems perhaps that they can do that only on direct properties of the CBLModel subclass?
I am trying to persist an NSDate object that gets stored in an NSDictionary on my CBLModel subclass.

Correct, it’s only for direct properties. It can do that because it has the extra value-type metadata in the class definition, so it knows what object class to read/write the JSON value as.

For a random JSON value inside a dictionary or array it can’t do this. The problem isn’t with saving, it’s with reading it back in: it just sees a JSON string (that happens to look like a date) and can’t tell whether it's supposed to be parsed into an NSDate or left as a string.

—Jens

Brendan Duddridge

unread,
Jun 12, 2015, 12:34:01 PM6/12/15
to mobile-c...@googlegroups.com
Hi Jens,

Thanks for the response. So is there a solution to this?

Is there a specific string date format that I should be using when storing the values in my dictionary? Is there any way to have it interpret the string and store it in the NSDictionary as an NSDate?

I also need to be able to query date ranges and to be able to sort on these date values in proper chronological order (ascending and descending). But that'll happen when the secondary index is generated I guess. But still, it would need to know what date format to store in the index. In my current app I use the Unix epoch date for storing date values. But during the conversation from FMDB I'm converting the epoch date into real NSDate objects and storing them in the values NSDictionary.

Thanks,

Brendan

Jens Alfke

unread,
Jun 12, 2015, 12:53:53 PM6/12/15
to mobile-c...@googlegroups.com

On Jun 12, 2015, at 9:34 AM, Brendan Duddridge <bren...@gmail.com> wrote:

Is there a specific string date format that I should be using when storing the values in my dictionary? Is there any way to have it interpret the string and store it in the NSDictionary as an NSDate?

No, not in general. JSON simply doesn’t support dates. The only types it has are bool, number, string, array, dictionary and null.

You can make up your own conventions in your data, like “the value of a ‘date_created’ property in a dictionary should always be interpreted as a date”, and then post-process the parsed dictionaries to convert appropriate strings to dates. But Couchbase Lite, being general-purpose, isn’t going to do that for you.

—Jens

Brendan Duddridge

unread,
Jun 12, 2015, 1:47:31 PM6/12/15
to mobile-c...@googlegroups.com
Ok. So I guess I'll store the date values in the dictionary as Unix epoch dates (number of seconds since Jan 1, 1970) still and then convert before being displayed. At least that should also work properly with sorting and searching date ranges.

Jens Alfke

unread,
Jun 12, 2015, 2:23:01 PM6/12/15
to mobile-c...@googlegroups.com

On Jun 12, 2015, at 10:47 AM, Brendan Duddridge <bren...@gmail.com> wrote:

Ok. So I guess I'll store the date values in the dictionary as Unix epoch dates (number of seconds since Jan 1, 1970) still and then convert before being displayed. At least that should also work properly with sorting and searching date ranges.

ISO-8601 dates also sort and compare properly, because they list the components in decreasing order and with leading zeroes. But numeric dates are significantly faster to parse. They’re not human-readable, though. It’s your choice :)

—Jens
Reply all
Reply to author
Forward
0 new messages