RFE: Get JSON Schema for Metadata #19

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

RFE: Get JSON Schema for Metadata #19

lcestari
Discussion over the details of the the issue https://github.com/lightblue-platform/lightblue-core/issues/19

Naveen and I discussed a little bit about it and We would appreciate other opinions about it.

The response format we discussed be something like https://gist.github.com/jewzaam/a9a3a3d585a97688d5e9 (from GET /metadata/<entity>/<version>?schema). That information could be stored during the creation of a new entity schema document version.

There are other possibilities such as more fields on the JSON document, suggestion for the rest interface, avoid the persistence of that new information with the dynamically generation of the document, etc. Below are some fragments of the IRC conversation from Naveen and I:





<lcestari> nmalik, it is similar to what I thought, but I thought it would follow something more like the structure it has internally. So it will only describe the fields, not the access or the constraints or default version, right ?
<nmalik> lcestari: right, intent is to verify data structure.  or at least I should say that's my thought on it.
<lcestari> nmalik, alright. So I have to capture that information during the creation and update and store it so it can be retrieved later, correct?
<nmalik> lcestari: or generate from the metadata dynamically.  storing is a nice idea though, generate once (since it's static anyway)
<lcestari> nmalik, yeah, we can generate , do you prefer this approach ? It will bring some more CPU consuming but I don't see someone consuming this service very often. dynamically creating it save as some space (and other things related to it, like if we want to change the schema of how it should be displayed, we dont have to migrate any information)
<nmalik> lcestari: I think once this is available we may see a gradual use of it, but it's up to the application developer.  It would be useful for insert or save operations where a whole document is supplied in the request to lightblue.
<nmalik> lcestari: depends on if the app caches the schema or asks for it new each time.  as for storing, we could put it in the metadata schema where the entityInfo and schema are already stored as separate documents.
<nmalik> lcestari: I'd lean towards saving it.  we have to retrieve either metadata or the generated json schema from db, so that's not a new dependency.  we'd remove the overhead (even if small) of creating the json schema with the saved option
<nmalik> lcestari: the metadata schema document is stored with "_id": "<entityName>|<entityVersion" so the json schema could just add another delimiter.  may impact some other code that makes assumptions about that key though
Reply | Threaded
Open this post in threaded view
|

Re: RFE: Get JSON Schema for Metadata #19

bserdar
I suggest we generate it every time the API is called, and never store
it. The processing it requires is minimal, it is simple transformation
from metadata into another json document. Storing it and preventing it
from going stale is much more complicated.

On Mon, Jan 5, 2015 at 1:29 PM, lcestari [via lightblue-dev]
<[hidden email]> wrote:

> Discussion over the details of the the issue
> https://github.com/lightblue-platform/lightblue-core/issues/19
>
> Naveen and I discussed a little bit about it and We would appreciate other
> opinions about it.
>
> The response format we discussed be something like
> https://gist.github.com/jewzaam/a9a3a3d585a97688d5e9 (from GET
> /metadata/<entity>/<version>?schema). That information could be stored
> during the creation of a new entity schema document version.
>
> There are other possibilities such as more fields on the JSON document,
> suggestion for the rest interface, avoid the persistence of that new
> information with the dynamically generation of the document, etc. Below are
> some fragments of the IRC conversation from Naveen and I:
>
>
>
>
>
> <lcestari> nmalik, it is similar to what I thought, but I thought it would
> follow something more like the structure it has internally. So it will only
> describe the fields, not the access or the constraints or default version,
> right ?
> <nmalik> lcestari: right, intent is to verify data structure.  or at least I
> should say that's my thought on it.
> <lcestari> nmalik, alright. So I have to capture that information during the
> creation and update and store it so it can be retrieved later, correct?
> <nmalik> lcestari: or generate from the metadata dynamically.  storing is a
> nice idea though, generate once (since it's static anyway)
> <lcestari> nmalik, yeah, we can generate , do you prefer this approach ? It
> will bring some more CPU consuming but I don't see someone consuming this
> service very often. dynamically creating it save as some space (and other
> things related to it, like if we want to change the schema of how it should
> be displayed, we dont have to migrate any information)
> <nmalik> lcestari: I think once this is available we may see a gradual use
> of it, but it's up to the application developer.  It would be useful for
> insert or save operations where a whole document is supplied in the request
> to lightblue.
> <nmalik> lcestari: depends on if the app caches the schema or asks for it
> new each time.  as for storing, we could put it in the metadata schema where
> the entityInfo and schema are already stored as separate documents.
> <nmalik> lcestari: I'd lean towards saving it.  we have to retrieve either
> metadata or the generated json schema from db, so that's not a new
> dependency.  we'd remove the overhead (even if small) of creating the json
> schema with the saved option
> <nmalik> lcestari: the metadata schema document is stored with "_id":
> "<entityName>|<entityVersion" so the json schema could just add another
> delimiter.  may impact some other code that makes assumptions about that key
> though
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/RFE-Get-JSON-Schema-for-Metadata-19-tp253.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: RFE: Get JSON Schema for Metadata #19

jewzaam
Administrator
The only thing that can change for a schema, though, is the status.  Fields never are allowed to change.  So it can never become stale.
Reply | Threaded
Open this post in threaded view
|

Re: RFE: Get JSON Schema for Metadata #19

bserdar
Correct, it'll never be stale. Still, too much work for no real gain,
in my opinion. Generating the schema is not a complicated operation.

On Tue, Jan 6, 2015 at 7:57 AM, jewzaam [via lightblue-dev]
<[hidden email]> wrote:

> The only thing that can change for a schema, though, is the status.  Fields
> never are allowed to change.  So it can never become stale.
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://dev.forum.lightblue.io/RFE-Get-JSON-Schema-for-Metadata-19-tp253p255.html
> To start a new topic under lightblue-dev, email
> [hidden email]
> To unsubscribe from lightblue-dev, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: RFE: Get JSON Schema for Metadata #19

lcestari
I think the effort to generate or persist it is quite similar, but to make easy to maintain and change, I would prefer if we dynamically generate it. We could vote to see which option we are going to implement.

Do you guys have other suggestions regarding other aspects like the json schema for example?