Balazs Scheidler <bazsi77@gmail.com> writes:
+ case TEMPLATE_TYPE_INT32: + { + gchar *endptr; + gint32 i = (gint32)strtoul(value, &endptr, 10); + + if (endptr[0] == '\0') + bson_append_int32 (o, name, i); + + break; + }
are you sure it's a good idea to drop data for invalid formats? i'd have added as strings in this case. this applies to all cases.
I'm not convinced, but the reason behind dropping was that if the user requested an int type, putting in string is not what one would expect. Probably it would be better to propagate some kind of error to higher layers, and report it back, though.
+ case TEMPLATE_TYPE_DATETIME: + { + gchar *endptr; + gint64 i = (gint64)strtoul(value, &endptr, 10) * 1000; + + if (endptr[0] == '\0') + bson_append_utc_datetime (o, name, i); + + break; + }
we might need to support a format with broken-down timestamp. an iso stamp might easily be formatted using a template, and the log message may carry such date in its payload.
It's entirely up to drivers how to handle dates, imo. MongoDB only supports a single datetime format: a 64bit int (microseconds since the epoch). So for this driver, $UNIXTIME is the closest thing. SQL destinations, or other formats that support different datetime representation (eg, $(format-edn), which I will submit soonish) will likely end up doing something very different to what the MongoDB driver is doing. -- |8]