The solution with view interfaces depicted in Fetching data with ORM is easy! Is it? – Jmix sounds like a great idea. The last sentences state: (from @belyaev)
And in the next versions, we’re going to introduce more changes. I’m not sure whether those will be view interfaces or something else, but I’m pretty sure with one thing - working with ORM in the next version with CUBA will be simplified.
Any update regarding this topic? Or another solution to the unloved unfetched attribute error?
Hi,
I’m not aware if there is any improvement planned for CUBA in this regard and with Jmix being present as a new major version of the platform I would assume such fundamental enhancements will only be introduced in Jmix.
For your concrete question of the unfetched attribute error I would say that it can be solved by lazy loading, which prevents this situation by loading the data transparently to the app developer when needed.
It has a major drawback though, which is that it loads the data transparently to the app developer when needed ;).
You can read more about it here:
https://docs.jmix.io/jmix/data-access/fetching.html
Furthermore since Jmix also supports Spring Data, it theoretically also support Projections, which are the same as the view interfaces presented in the article you mentioned in the Spring Data world.
But I guess without dedicated support in Jmix you will have to do a lot on your own when it comes to integration with the other standard features such as attribute security, filter components etc.
You can read more about it here: https://www.baeldung.com/spring-data-jpa-projections
The practical balance I personally rolled with quite well to avoid those failures is to write a lot of integration tests in the places where you could encounter those situation. Catching the unfetched attribute errors is just one aspect of those tests, which means you would probably write tests anyways to cover the other aspects. But with CUBA I tend to have ratio between unit / integration tests that is a little higher for integration tests in comparison to other frameworks.
Cheers
Mario
Thank you for your answer. Intersting, so Jmix supports lazy loading in contrast to CUBA.
It has a major drawback though, which is that it loads the data transparently to the app developer when needed ;).
Yes, I know the drawbacks of lazy-loading, but in a more complex application I would prefer unloaded attributes to be lazy loaded in some edge-case scenario instead of throwing an error.
I guess a combination of eager loading and lazy loading would be good. So I would eager load all attributes I already know of. For the other attributes - e.g. added functionality, but forgot to update the view - do lazy loading and write out warnings to the log, that attribute X was lazy loaded. This way I can update the view graciously, but the application still works.
Besides the fact that I’m unaware of if it is possible to do such behavior it would also mean that in case you missed an attribute of an associated table you would first do a join statement to load all the attributes of the original view and then on top you do an additional n+1 query. If it is over multiple tables even more.
Are you mainly concerned about missing fields in the Vaadin Ui layer or are you talking about the business logic layer?
When it is about “forgetting” attributes in the view but using them in the UI / business logic, what you can also try is to “inline” the views in the places where they are used using the
viewBuilder in code / declarative views in screens. With that, the likelihood of forgetting to include it is reduced. Also with not sharing views across the application in different places, this vague situation of “does this view already have the attribute or not” is a little easier to answer, because there is a dedicated 1:1 mapping between view definition and usage.
I would assume you are mainly talking about the UI layer and the associated error messages that pop up. Although I can see why you would want to have that I would guess that this only eliminates one example of problems, that could arise. The declarative XML nature might give the impression (at least to me sometimes), that this is not source-code that we have to treat as a first-class citizen with proper test coverage. But in fact a lot of stuff can go wrong when changing the XML. Since there is no compiler in place for those parts, there is even more need to have an integration test suite for those parts.
With CUBA it was a little problematic to test the UI layer with an integration test since the data loading is excluded. Therefore also the not-fetched error would really appear in the test suite, except if it is explicitly modeled as a negative test case. Therefore only the E2E test cases would cover that.
With Jmix the data layer is not mocked out anymore in the web integration tests, which means that you can test those data loading scenarios in your integration test suite.
Investing in a dedicated integration test suite can be expensive (although only short-term). But when you only want to cover the entity view problem, you can probably come up with a generic test case, that does that for all browse screens e.g.
Cheers
Mario
Hi,
We don’t plan any major improvements for the CUBA anymore. All new features and improvements will be added to the next generation of the CUBA platform - to Jmix.
In Jmix this is possible apparently, see Fetching Data :: Jmix Documentation
Fetch plans are fully compatible with lazy loading of related entities. It means that you can load some part of a graph with a fetch plan, and then load other related entities lazily by navigating references.
Actually it is business logic where some references are only required with some specific user settings and under some circumstances. I guess these are usual complex business logic operations…
The view builder could help, thanks, I’ll look into that. I’d prefer the Jmix way though, but migration will not be easy for now I guess.
Yes, I also do unit-/integration- and E2E tests. The later with Selenide.
Thanks, I understand that. Is there already a timeline for the migration guide and tools?
Very soon 