table.insert_data should allow for dictionaries

[podopie]

table.insert_data currently only accepts tuples/lists in the order of the schema. It'd be a great feature allow lists of dictionaries to be passed.

Would expect cases where if the keys in the dictionary do not match the schema, it would return back an error.

FWIW, here's an example of how another python library handles it for a typical database connection:

https://github.com/pudo/dataset/blob/master/dataset/persistence/table.py#L62

[dhermes]

@lukesneeringer WDYT of this? It'd be somewhat easy to support with a helper that mapped a each row in rows into row_info (whether it started as a tuple or a dict).

[tseaver]

@dhermes I think we would be better off with another method which handles dicts (and likely calls the current insert_data).

[Lordie12]

+1 to this, it would be really helpful (especially when handling 2-3 level nested RECORDS). Its currently quite a change from using both the Java client and the NodeJS client (both of which accept a TableRow / dictionary).

[tseaver]

I'd like to add a Table.row_from_mapping method which uses the schema to generate row tuples from a dict. Usage would then be:

table.insert_data([table.row_from_mapping(mapping) for mapping in json_rows])

[rmmh]

insert_data also doesn't fully support nested records-- it only runs conversion functions (datetime=>timestamps, etc) on the first level of data.

It feels quite pointless, since it just ends up reconstructing the dictionary internally. Users with a dictionary have to convert it to a tuple according to the schema (but only the first level!), and then insert_data converts it back into the same dictionary before issuing a POST.

Since the API endpoint itself expects a dictionary, it would make more sense for the method to accept a dictionary. Why is it a tuple/row interface anyways?

Polymorphism seems fine to me, or another method.

[tseaver]

@rmmh The reason that insert_data takes tuples is that most "row oriented" Python modules (the DB-API, the csv stdlib module) deal with rows as tuples, not as mappings. We also work to consume / return the values as the correct native Python types, according to the schema type, which is not the same as the on-the-wire JSON values (e.g., datetimes, bools, bytes, etc.)