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).
first you extract and load data with dlt and then you transform them with dbt. so both tools work very well together. we did a really cool helper to make it easier(https://dlthub.com/docs/dlt-ecosystem/transformations/dbt/) (I'm one of core devs in dltHub)
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
> for any bigger company you do not even know how many shares are there
Companies know exactly how many shares are at any given moment. The concept you are looking for is called "outstanding shares".
> pricing of privately held companies is set by last funding round so you can say it's taken out of the thin air ;>
Read the Uber and Softbank example. It is a good one why funding round doesn't tell you the price.
And, funding is not a simple - I gave you $X because the company should be worth $Y. Things can get complicated quickly. Deal can be worth $X because the investor got "preferential shares" which means non-preferred shares are worth less than what you think. This cannot be coded into a smart contract and will still cause information asymmetry.
> also Ethereum VM is much simpler to learn than commercial law which you (probably) also do not know
That is your opinion. Ask someone who works in finance and they will tell you that learning law is simpler than the VM.
In any case,
> also smart contracts do not solve malicious intentions of programmers and business owners
To put it another way, if people knowingly want a complicated cap table, they can write a complex decentralized contract?
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).