That's absolutely a good idea. One thing is describing the JSON structure,
which I guess would not be different (although more elaborate than average)
than other features. But the moment you mention this then I start thinking
about also query "into" the JSON. Or any other map structure. Also many o
Hi Kasper,
Sounds like a nice idea.
Would this also allow to define a complex metadata on a single column. For
e.g. if the content of the column is a JSON object, would it be possible to
define what is the structure of the JSON, what specific fields within the
JSON structure have what behavioural
Glad that you like the idea :-) And yes, I also would like to involve as
many as possible in building it.
My high level design ideas:
We would leave the existing DataContext API as-is to the extent possible. I
would see this as a service that is connected to the DataContext but since
the "new" me
That's pretty cool. Sorry but I was not taking into account the powerful
queries that you might bring into the equation with this stuff. It all
makes sense now.
It would definitely be a big feature that might be divided into smaller
tasks. If we go ahead with this stuff I really would like to help
That's absolutely true. It's not that I want to stop discovering what we
can, but I was more thinking of also adding a mechanism to plug your own
metadata. I guess it's pretty rare that a database itself offers a "domain
oriented" metadata system where I could tell it that "this field is a zip
code
Ok, so you are not thinking of discovering more metadata "on-the-fly", your
approach is statically define metadata for the datasource and load and
mix-in it with the existing metadata right?
IMHO with this approach we will add a strong dependency between the data
itself and the "external" metadata