we'll continue this project but I learnt from it that most of the openAPI specs are a mess with hundreds of endpoints, incomplete definitions, lack of relations between endpoints, unique constraints etc. so there's tons of heuristics needed anyway. but sometimes it works. and is quite amazning!
if you want to enforce schema and data contracts:
- you can use pydantic models to validate data (if you use pydantic model as a table definition, this is the default)
- we have soon-to-be-merged schema contract PR: https://github.com/dlt-hub/dlt/pull/594
My observations are that it is more than 1% of people that are fine with auto-generated schemas. But that could be selection bias (they use our library because they like it).
Smart contract is exactly how you solve convoluted captables. Currently shareholding is such a mess that for any bigger company you do not even know how many shares are there - rarely they sum to 100%. at least when shares are represented as the tokens you know how many are there and who owns them - at all time. that's already a huge step forward
pricing of privately held companies is set by last funding round so you can say it's taken out of the thin air ;> you can also have market valuation if you try to tokenize shares and trade them. does not seem wise for early stage company though
also smart contracts do not solve malicious intentions of programmers and business owners, they are just tools and you can write fair self executing options plan or perfect decentralized scam
also Ethereum VM is much simpler to learn than commercial law which you (probably) also do not know
there is a paper investment agreement signed with startup that says that certain shares are represented as a tokens in smart contract and whoever owns those tokens has shareholder rights (voting power, dividends) etc. so owning tokens is no different than owning shares.
this paper agreement has a corresponding smart contract agreement (they are linked via hash) and together they protect our investment both on blockchain and in so called off-chain world
we'll continue this project but I learnt from it that most of the openAPI specs are a mess with hundreds of endpoints, incomplete definitions, lack of relations between endpoints, unique constraints etc. so there's tons of heuristics needed anyway. but sometimes it works. and is quite amazning!
if your source has well defined schema, we support ie. arrow tables natively. we keep 100% of that schema: https://dlthub.com/docs/blog/dlt-arrow-loading if you want to define your own schemas you can do it in many different way: - via pydantic models: https://dlthub.com/docs/general-usage/resource#define-a-sche... - via json-schema like definitions: https://dlthub.com/docs/general-usage/resource#define-schema - in a schema file: https://dlthub.com/docs/walkthroughs/adjust-a-schema
if you want to enforce schema and data contracts: - you can use pydantic models to validate data (if you use pydantic model as a table definition, this is the default) - we have soon-to-be-merged schema contract PR: https://github.com/dlt-hub/dlt/pull/594
My observations are that it is more than 1% of people that are fine with auto-generated schemas. But that could be selection bias (they use our library because they like it).