The Detector object can be used in various places within the Framework. The main purpose of this class is to tweak how different aspects of metadata are detected.
Here is a quick example:
It's also possible to pass it to the CLI, for example:
All the options below have their CLI equivalent. Please consult with the CLI help.
The detector class instance are accepted by many classes and functions:
- and more
You just need to create a Detector instance using desired options and pass to the classed and function from above.
Let's list all the available Detector options with simple usage examples:
By default, Frictionless will use the first 10000 bytes to detect encoding. The following code will be slower but the encoding detection will be mroe accurate:
By default, Frictionless will use the first 100 rows to detect field types. This can be customized. The following code will be slower but the result can be more accurate
This option allows manually setting all the field types to a given type. It's useful when you need to skip data casting (setting
any type) or have everything as a string (setting
Sometimes you don't want to use existent header row to compose field names. It's possible to provide custom names:
By default, Frictionless uses 0.9 (90%) confidence level for data types detection. It means that it there are 9 integers in a field and one string it will be inferred as an integer. If you want a guarantee that an inferred schema will conform to the data you can set it to 1 (100%):
By default, Frictionless will consider that all non integer numbers are decimals. It's possible to make them float which is a faster data type:
Missing Values is an important concept in data description. It provides information about what cell values should be considered as nulls. We can customize the defaults:
As we can see, the textual values equal to "67" are now considered nulls. Usually, it's handy when you have data with values like: '-', 'n/a', and similar.
There is a way to sync provided schema based on a header row's field order. It's very useful when you have a schema that describes a subset or a superset of the resource's fields:
Sometimes we just want to update only a few fields or some schema's properties without providing a brand new schema. For example, the two examples above can be simplified as: