Would anyone have time to take the branch for a spin? I added also a
swagger file now (https://github.com/apache/metamodel/pull/111) and
think this is a good time to gather feedback before continuing down
this route. Now is the better time to adjust :)

2016-06-06 20:56 GMT-07:00 Kasper Sørensen <[email protected]>:
> 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