You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 27, 2024. It is now read-only.
If the size returned by Query.size() or cached from previous call to Query.size() is bigger than the last slice returned from Query.loadItems(...) new Items are created by calling Query.constructItem() which throws an UnsupportedOperationException in our case because we provide a read-only view on business objects and there is no reasonable way to create a new Item without specifying some parameters.
The change to the size happened in two different circumstances:
a) There are background tasks that remove items while a user can display and scroll through them. The lazy query container was backed by webservice calls thus there is a delay and no transaction present even if the size is loaded again/not cached
b) There is a problem with nested optional @ManyToOne associations in hibernate and the default EntityQuery (but thats another topic). The loadItems() method would return no items in that case. Instead of showing an empty grid the application crashed because there was no setter present on a read-only entity (thats another topic as well, see #85 ).
Solution: Please don't call constructItem() when size and loaded items count differ.
The text was updated successfully, but these errors were encountered:
Hi. The items can not be null so in this kind of scenario you would need to either refresh the container to correct the size or provide dummy place holders for the missing items when constructItem is called. If you can implement alternative solution I am happy to accept pull request.
Before writing an alternative solution I tried to understand your existing implementation and I'm not sure why you are doing things the way you do. Perhaps you can help me understanding some corner cases. I stumbled upon the queryItem(int) Method in LazyQueryView and the EntityContainerAttachedEntitiesTest class.
If items are deleted in the background as demonstrated by testQueryWithBackgroudDeletedEntities() you add an empty dummy item which will be flagged "deleted". When reading the test case the first time I thought you flag the deleted task two as "deleted" but than I realized that the items get loaded from database and that there is just task one in the container and that you've added an empty dummy value and flag it "deleted". Why do you do that?
If the size returned by
Query.size()
or cached from previous call toQuery.size()
is bigger than the last slice returned fromQuery.loadItems(...)
new Items are created by callingQuery.constructItem()
which throws anUnsupportedOperationException
in our case because we provide a read-only view on business objects and there is no reasonable way to create a new Item without specifying some parameters.The change to the size happened in two different circumstances:
a) There are background tasks that remove items while a user can display and scroll through them. The lazy query container was backed by webservice calls thus there is a delay and no transaction present even if the size is loaded again/not cached
b) There is a problem with nested optional
@ManyToOne
associations in hibernate and the defaultEntityQuery
(but thats another topic). TheloadItems()
method would return no items in that case. Instead of showing an empty grid the application crashed because there was no setter present on a read-only entity (thats another topic as well, see #85 ).Solution: Please don't call
constructItem()
whensize
and loaded items count differ.The text was updated successfully, but these errors were encountered: