Type and Field extension / change behavior
See original GitHub issueOverview
I’m using Frictionless pretty much as Schema Detector. I have two issues here:
-
I would like to introduce a custom type called BigInt to be able to differentiate normal Integer from a BigInt. Issue is that for how it works the detector, as soon it find a correct type (https://github.com/frictionlessdata/frictionless-py/blob/a0cd70d03df4ca6571b1e8b26445e6274ba46c3d/frictionless/detector.py#L270), it will break from the loop of the runners, invalidate in case a custom BigInteger type cause the Integer type would always succeed before.
-
I have a issue also with datetime format, still in a scenario of schema detection. Since automatically the detector will apply a
default
as format, instead of aany
for a timestamp, it will always arise a issue on the assert (https://github.com/frictionlessdata/frictionless-py/blob/a0cd70d03df4ca6571b1e8b26445e6274ba46c3d/frictionless/types/datetime.py#L32) avoiding in case a correctparser.parse(cell)
for different format that doesn’t follow isoformat.
I’m not sure how I could patch in case these two cases, and if it’s even possible.
Please preserve this line to notify @roll (lead of this repository)
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (4 by maintainers)
Top GitHub Comments
Thank you. It was very on point!
@antoniocali Hi, from
frictionless@4.16
there is aplugin.create_candidates
hook. Here is a full example with a custom type:That’s how
system.create_candidates
returns without custom plugins (a detector will try these types on an detected cell from top to bottom):Using this hook you can also alter other detections details, for example, insert
{'type': 'datetime', 'format': 'any'}
before the defaultdatetime
candidate.