Grist type system?

Developers
1

Hi,
I wonder if the type system documented here is actually implemented/enforced and if so, where and in which cases…
I ask because I have been exploring Grist types quite a bit lately, using both the GUI and the APIs, and nothing resembling those specifications actually popped up anywhere in my tests, so far (*).

I did found, indeed, several undocumented corner cases… but ultimately I couldn’t find a way to force data into Grist using the type system specifications, neither via the GUI nor the APIs… for example, according to the specifications, a number in a “date” column can be expressed as “[‘n’, the_number]”… However, afaik, there’s no way to actually put a number into a date column (if you try with the GUI, a string will be inserted instead).

This is all because I am exploring the possibility of adding at least a few type checks in my Pygrister, and I can’t decide if I should simply ignore those specifications, or I should take them into account somehow.

A different but related question is - what about the “noparse” param of the POST records API? I have experimented a few things, but it never (**) seems to make a difference…

Thanks for clarifying the matter,
-riccardo

(*) except this one thing, which is probably a bug - if you pull data with the APIs from a “choice list” column, you get values like (json) “[‘L’, ‘foo’, ‘bar’]”… where the initial “L” doesn’t make much sense, but resembles something you can find in the type system specification… Of course it’s a regular choice list stored in a choice list column, so there should be no reason of using the “long representation”, but there you have.

(**) well, except for this single, tantalizing counter-example: if you put a float expressed as a string (say, the string “42.42”) into a “numeric” column, then you’ll have (correctly) 42.42 with “noparse=True”, and 4242 with “noparse=False”. Apart from this, I never found a case where “noparse” actually matters.

2

The section you linked is largely out of date, so don’t rely on it. If exploring explicit representations (like ['d', N]), try to read the results of a formula column with type Any. For formulas, a single column may return any type of value, so if you construct a formula that returns various types (choices, choice lists, references, dates, etc), you’ll see a more realistic catalog of what’s possible.

Data columns, for all intents and purposes, are limited to their explicit type, or text to represent invalid values.

3

I see, thanks… I’m not sure where this leaves me in terms of my original api usage problem, though… I can see quite a few oddities and corner cases (for instance, error values in formulas are stored in the db and shown in the gui, but not retrieved by the api…) and it would be difficult to account for everything…

On a second thought, maybe I don’t have to… perhaps all I have to do, as far as Pygrister is concerned, is provide a hook for custom conversion functions… then the users will register their own converters…
Uhm, I’ll think about it…

thanks for now!