Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] DTO behavior change
Please hold on merge - the timeframe for this discussion was overnight for anyone based in North America. We need to give people the opportunity to consider the impact of this change. If getting this merged today was a priority we should have started the discussion several days ago.

Can someone add the issue link here as well please?

On Fri, Jun 14, 2019 at 08:03 Florent Benoit <florent@xxxxxxxxxx> wrote:
ok so I guess there was no discussion at all ?

Florent

On Fri, Jun 14, 2019 at 1:42 PM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
QA passed. We are going to merge in 20 minutes unless something critical happened.

On Fri, Jun 14, 2019 at 11:52 AM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
Ideally, we would like to have this change in CR2 (today) and left some space to test it before GA.
An alternative to it is not to have devfile validation on workspace creation/editing.
That is the worst case scenario IMO.

On Fri, Jun 14, 2019 at 11:25 AM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:


On Fri, Jun 14, 2019 at 11:11 AM <tmader@xxxxxxxxxx> wrote:
Hi Sergii,

On Fri, 2019-06-14 at 09:13 +0300, Sergii Kabashniuk wrote:
Hello

I would like to share a note about the change in DTO behavior on Che master side.

Previously in during DTO serialization, we put everything to the output including
empty collections/fields. At this moment we are not able to identify the concrete reason why we did this way and not the opposite.

In typescript, for example, mandatory but possibly empty and optional are two different types. This may make it harder for some clients to work with the API. Apart from the null checks necessary, I believe we are using some JSON schemas in the API (e.g. kubernetes) where we don't control the definition.


This behavior brings to us some difficulties when we tried to add devfile schema validation in our REST API.
So we decided to rethink this behavior again.  As a result, we think that it makes sense to revert this behavior and do not serialize empty collections/fields. That will allow reducing the size of result json. As a side effect all clients (most of them already doing that)
has to check optional field != null before doing any operation with it.

As we are working towards Che 7 GA, we should restrict our changes progressively to those that are strictly necessary for that goal. Could you explain a bit what the problem is with devfile validation and how this change helps? I think that would improve buy-in from clients.

Let's take two components as an example.

{
  "components": [
    {
      "alias": "mysql",
      "type": "kubernetes",
      "referenceContent": "petclinic.yaml",
      "selector": {
        "app.kubernetes.io/part-of": "petclinic",
        "app.kubernetes.io/component": "database",
        "app.kubernetes.io/name": "mysql"
      }
    }
  ]
}


{
  "components": [
    {
      "alias": "theia",
      "type": "cheEditor",
      "id": "eclipse/chetheia/0.0.3"
    }
  ]
}

In our schema, we defined that only kubernetes component can contain selector. However our DTO mechanism
will serialize cheEditor with empty selector 
{
  "components": [
    {
      "alias": "theia", 
      "type": "cheEditor", 
      "id": "eclipse/chetheia/0.0.3", 
      "selector": null
    }
  ]
}
and schema validator will complain about wrong filed "selector".

/Thomas

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    



--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    



--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
--
Brad Micklea // Group Lead, Developer Tools & Program // 416.707.0792 

Back to the top