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 <ardl...@gmail.com>: > 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 <i.am.kasper.soren...@gmail.com > >: > > > 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 > > >
