[WIP] Using object literals to append rows to tables

[kneth]

Using NSArray and NSDictionary to append rows to tables will make objective c programs more readable.

The implementation is heavily inspired by our Python binding.

@ks @mekjaer @astigsen

[astigsen]

Awesome, great start :-)

I look forward to support for dictionaries and objects as well ;-)

[astigsen]

Shouldn't date columns expect NSDate objects as input? It would probably be pretty rare that users would want to save timestamps directly (as they are likely to only be able to get from NSDate objects anyways).

[astigsen]

Same thing with binary. They should probably expect NSData objects as input:

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSData_Class/Reference/Reference.html

[kneth]

Our current interface is using time_t for dates but we could support both time_t and NSDate in appendRow. Similar for binary data.

[oleks]

To quote a conversation we had earlier with @kspangsege and @kneth :

The general paradigm I use is

switch(column_type)
{
case type_Int:
    ...
    goto ok;
case type_Float:
    ...
    goto ok;
case type_Double:
    ...
    goto ok;
case type_Bool:
case type_DateTime:
case type_String:
case type_Binary:
case type_Mixed:
case type_Table:
    RAISE_COLUMN_TYPE(column_ndx,
        "either int, float, or double");
    return Qnil;
}

RAISE_UNKNOWN_TIGHTDB_TYPE(); // returns from the function

ok:
    return result;

The effect is that the compiler will warn of any missing cases, and if
any new cases are added (to core) after the extension has been
compiled, the extension will duly fail.

[bmunkholm]

If there is nothing common to do after "ok:", I would definitely 'return result' in the 'case' instead of 'goto ok'.

[oleks]

According to [1]: "When you’re writing code with Objective-C, exceptions are used solely for programmer errors, like out-of-bounds array access or invalid method arguments. These are the problems that you should find and fix during testing before you ship your app."

I would regard the programmer attempting to add a row of values where the values don't match the column types to be such a "programmer error", i.e. it should yield an exception. It seems to me that we haven't yet made a solid decision about what our strategy is wrt. to this sort of thing. I think we need to make that decision ASAP, so that we don't end up fundamentally changing our API in the coming months.

UPDATE: Just to clarify, appendRow will return false if the types are invalid, I would argue that it should yield an exception instead (and have no return value). I think in the java world, you'd otherwise also call the method "tryAppendRow", if it returned a boolean.

[1] https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ErrorHandling/ErrorHandling.html

[astigsen]

Just to clarify, appendRow will return false if the types are invalid, I would argue that it should yield an exception instead (and have no return value)

Actually it would probably make sense for appendRow to return the index of the new row. That has turned out to be quite useful in the python binding.

For errors it should definitely raise exceptions.

[astigsen]

+1

Would love to get support for dictionaries and objects as well, but I guess that can follow.

Any chance that we could get NSDate and NSData support included in this PR? It seem like it would be very easy to implement. Here is the date conversion code from Paul's example:

+ (NSDate*)dateFromTime:(time_t)timeValue
{
   if (timeValue > 0) {
      return [NSDate dateWithTimeIntervalSince1970:timeValue];
   } else {
      return nil;
   }
}

+ (time_t)timeValueFromDate:(NSDate*)date
{
   return [date timeIntervalSince1970];
}