Thank you for the remarks on the branch Dennis. I updated it with your
corrections and I also added a pretty extensive test class to show a
full usage scenario where the test is registering a data source and
exploring the schema of it.

2016-06-05 23:42 GMT-07:00 Kasper Sørensen <[email protected]>:
> I've posted my code so far here:
> https://github.com/kaspersorensen/metamodel/tree/feature/5.x/rest-api
>
> It's really not done or even very useful yet. But thought to share it
> since I realized that I had not had time to work on it as much as I
> had hoped. So what is there:
>  * A basic webapp setup with Docker and all that stuff just working.
>  * A concept of tenants/users who own various data contexts
>  * Ability to traverse schemas, tables etc. of the data contexts that
> a user owns
>
> What's blatantly missing:
>  * Ability to create anything except POJO data contexts.
>  * A swagger API definition.
>  * Persistence of tenants and their data context definitions.
>  * A query endpoint/controller (but this I have created in
> https://github.com/kaspersorensen/ApacheBigDataMetaModelExample so it
> should be easy to add something similar quickly).
>  * Unittests.
>
> If anyone feels like giving any of that a go, would be awesome. I hope
> to be contributing some more to this branch before posting it as a PR.
> At least making it fully functional.
>
> Best regards,
> Kasper
>
>
> 2016-05-24 9:22 GMT-07:00 Kasper Sørensen <[email protected]>:
>> Already +101 then ;-)
>>
>> Sorry Alberto, I think I then misunderstood your mail from March - I
>> though you had in mind to create a client-side DataContext that would
>> absorb a(ny) REST interface. Hence I was a bit like "that's nearly
>> impossible" in my response. But great that we had the same ideas then!
>>
>> Regarding where to place it... Somehow I feel a bit like making it
>> part of MetaModel because I do think that our "brand" needs to be
>> enforced and we should avoid diluting the attention to MetaModel. But
>> a marketing person might tell us the opposite is better, I don't know
>> :-)
>>
>> I have a bit of code lying around for something like this, back from
>> when I was doing my talk at ApacheCon in Budapest. It's probably not
>> going to be what I'd like to contribute, but I will anyway take a look
>> if some of it can be reused.
>>
>> Anyone wants to give a shot at making an Swagger file for API discussion?
>>
>> 2016-05-23 23:48 GMT-07:00 Du Krøger, Dennis
>> <[email protected]>:
>>> Sounds like an amazing idea!
>>>
>>> How would/should it fit into MetaModel? Part of the actual project or as a 
>>> subproject? I wouldn't really mind it as a part of MetaModel itself, but I 
>>> think it might be better as a subproject, since it is a little bit out of 
>>> scope for MM itself.
>>>
>>> BR,
>>> Dennis
>>>
>>> -----Original Message-----
>>> From: Alberto Rodriguez [mailto:[email protected]]
>>> Sent: 24. maj 2016 08:27
>>> To: [email protected]
>>> Subject: Re: [DISCUSS] A MetaModel service/app
>>>
>>> Hi Kasper,
>>>
>>> this is a great idea and is somehow related to the email I sent in March 
>>> suggesting the creation of an API REST module. I think this make a lot of 
>>> sense and as you said we would reach a much wider community.
>>>
>>> So...+100 from me ;)
>>>
>>> Kind regards,
>>>
>>> Alberto
>>>
>>> 2016-05-24 5:07 GMT+02:00 Kasper Sørensen <[email protected]>:
>>>
>>>> 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