Hi all,

I want to share an idea and ask if you think it's something that we
should add to MetaModel.

I've been having the idea of making a webapp for centralized data
management and federation, based on MetaModel. It would host a set of
RESTful services for registering a datastore and for querying them.
Potentially also for updating them.

By registering data you would be able to either register connection
information, or simply upload the data and thereby build a new set of
data to be queried. The datastores would have an identifier and would
then be queryable by using that identifier. For example, if the
datastore ID was "myds" then I might access it's schema like this:

http://hostname/myds/schemas

And say if it then had schema "PUBLIC" then tables could be accessed a la:

http://hostname/myds/schemas/PUBLIC/tables

and so on...
Queries could be fired like this:

http://hostname/myds/query?sql=SELECT+foo+FROM+mytable

All of this could be built quite easily IMO, and more importantly
uniformly, using MetaModel.

I think also updates would/should be possible, although I didn't think
a lot yet about the interface.

I have faced this need from time to time where different pieces of a
large architecture all need access to the same data. And if those
pieces are not built using the same technology stack, it becomes hard
to share data - except if you pass all the data around between
services. My idea here was to be able to just pass around a datastore
identifier and thus let different services all access the same data.

>From a community perspective, I think this may also help MetaModel a
lot. I have faced many situations where people not coding in Java say
"that's really cool, but it doesn't work with my
[.NET/Python/whatever] stack". If we would offer "MetaModel as a
service" then I think our reach would be a lot wider. Furthermore I
think we should then offer MetaModel as a Docker image and thereby
make it a lot easier for people to quickly try it out and so on.

What do you all think?

Best regards,
Kasper

Reply via email to