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
public interface ObjectDataTablesRepository extends DataTablesRepository<Object, Integer>
{
default DataTablesOutput<BwDbObject> findUnmapped(DataTablesInput input)
{
return findAll(input, (root, query, builder) -> {
root.fetch(Object_.association, JoinType.LEFT); //wrong, should be join
return builder.isNull(root.get(Object_.objectClass));
});
}
}
it adds custom condition and a join fetch on associated entity to the query. The latter causes the "query specified join fetching, but the owner of the fetched association was not present in the select list" exception, which is catched in findAll but then put into output only
then execution continues and fails with "Transaction silently rolled back because it has been marked as rollback-only" which is ultimately thrown by spring, so we never get to the output.error and never see any exception in log unless we debug findAll and see the real cause. I'm not sure why the transaction marked for rollback since we catch the exception, but I don't have time anymore to dig further. I think that it wouldn't be a terrible idea to log exceptions to slf4j anyway, not only to error field.
The text was updated successfully, but these errors were encountered:
Consider following repository
it adds custom condition and a join fetch on associated entity to the query. The latter causes the "query specified join fetching, but the owner of the fetched association was not present in the select list" exception, which is catched in findAll but then put into output only
then execution continues and fails with "Transaction silently rolled back because it has been marked as rollback-only" which is ultimately thrown by spring, so we never get to the output.error and never see any exception in log unless we debug findAll and see the real cause. I'm not sure why the transaction marked for rollback since we catch the exception, but I don't have time anymore to dig further. I think that it wouldn't be a terrible idea to log exceptions to slf4j anyway, not only to error field.
The text was updated successfully, but these errors were encountered: