An additional note/idea that just came to mind: Some features like these
might be detectable and some might even be intrinsically available in the
data source. For instance in Salesforce.com many of the fields are standard
fields as well as the tables being standard tables. That means that for
this
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
I was thinking of having something like pluggable annotations or features
that could be added to tables, columns or groups of columns. Maybe also to
other entities. But since a lot of this is not available as a thing that
can be explored in the datastore itself I guess it would need to be stored
ex
Hi all,
We are also facing similar issues so I completely agree with this feature.
In fact, we added recently in our service layer a new field for our
metadata called "format", we needed this field to specify different format
types for the dates returned by our datastores.
However, I'm not really
Hi all,
All the time I see more and more need for us to add metadata to our
MetaModel based connectors. That could be for instance metadata about scale
(nominal, ordinal etc.) so that we can automate some stats collection etc.
or it could be more "meaning" oriented features to describe e.g. "This
10 matches
Mail list logo
