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, correct me if I'm wrong or not fully understand your proposal but if the datastore changes (one column is deleted or a new column is added) the metadata will get obsolete. Kind regards, Alberto 2015-07-13 19:26 GMT+02:00 Kasper Sørensen <[email protected]>: > 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 > externally. > > Examples of features that I could imagine: > > Data type features: NominalScale, OrdinalScale, ... > Data conversion features: IntegerAsString, DateAsString, TimestampAsLong > ... > Domain features: FirstName, LastName, AddressLine, AddressCity, > AddressCountry, DateYear, DateMonth ... > And groupings of columns also in domain like fatures: Name (composed of > e.g. first and last name), Address (composed of multiple address fields), > Date (composed of year, month etc.) > > I would like to store them so that I can save and load them, saving the > developer for the work of restoring all the metadata again and again. Is > that not sensible? > > Best regards, > Kasper > > > 2015-07-13 9:55 GMT+02:00 Alberto Rodriguez <[email protected]>: > > > 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 sure how to implement this feature... I guess we > > should keep getting the metadata "core" from our datasources but what > about > > the new metadata??: > > > > - How to fill it out? Will the integrator of MM provide functions to > > define when an element is going to be "x" and when is going to be "y"? > > (thinking here of providing lambda functions) > > - Do we really need a metadata store? > > > > Kind regards, > > > > > > 2015-07-10 12:51 GMT+02:00 Kasper Sørensen < > [email protected] > > >: > > > > > 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 > > is a > > > first name" or "This is a city" or "These two fields (first and last > > name) > > > are together defining a name of a person". > > > > > > We have such mechanisms in our application levels many places, but not > at > > > the core framework of MetaModel and that's a pity because it makes it > > > harder for us to share. > > > > > > So I'm thinking of adding such a layer to the metadata of MetaModel. > But > > > one thing that's difficult is then about representing that metadata in > > some > > > "metadata store" which isn't necesarily the same as the data source > > itself. > > > It could be an XML file or it could be a complete metadata database. > And > > I > > > think that this metadata would be mutable by the integrator of > MetaModel > > > because it is rarely fully revealed by the data source itself. > > > > > > What do you think? Nice feature or?` > > > > > > Kasper > > > > > >
