Parse CSV schema in meta configuration

[gfissore-rai]

In the current implementation, the schema of the input CSV data is specified implicitly by using the int_attr, float_attr, etc... relations inside the meta configuration module. However, Rel supports a native way to specify a schema through the config:schema relation used in load_csv[config].

It should be possible to get rid of the int_attr, float_attr, etc... relations by specifying the schema relation in the meta configuration, in the exact same way as it's done for load_csv. This comes with some advantages:

1. In many cases, when you load CSV files, you might already specify the schema with config:schema, so it makes a lot of sense to just reuse this (I would also suppose that this is the right way to go from a performance standpoint);
2. moving the type information from the hardcoded relation names (as in int_attr) to the input (as in config:schema = {(:quantity, "int");}) is more general and probably more future-proof; indeed, I think it would be easy to implement this in such a way that if new data types are supported in config:schema in the future, they will work out of the box with the CSV library (in the current implementation you would need to update the library by adding a new_type_attr relation).

@grigory93 would love to hear your thoughts on this!

[grigory93]

so the idea was to have more flexible and powerful functionality than the one provided with load_csv[config]. While int_attr, float_attr seem identical the others offer a lot more , such as parsing date/time, applying general mappings, creating multiple columns out of the same value, etc. I could easily skip on identical ones such as int_attr and float_attr but I didn't like the idea of placing logic in different places and then reconciling and maintaining them separately - not pretty.

[grigory93]

we also have an option or adding more functionality as one becomes necessary. For example, I considered adding a mapping function to each column (by default it would be identity), but because I didn't have a necessity yet I kept things simple.

[grigory93]

another function that could be added is a validator (by default always returning true) that checks for any pre-defined rules on every column or combinations of thereof.

[grigory93]

of course, we could introduce a special validator relation validator that specifies a column and corresponding validator function. That would be 1st step before actual parsing of data. At least something to think about.