• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

Netflix / genie / 2738 / 1
94%
master: 94%

Build:
DEFAULT BRANCH: master
Ran 26 May 2020 05:10PM UTC
Files 578
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

26 May 2020 04:51PM UTC coverage: 92.413% (+0.02%) from 92.394%
bintrayUser=[secure] bintrayKey=[secure] sonatypeUsername=[secure] sonatypePassword=[secure] DOCKER_USER=[secure] DOCKER_PASSWORD=[secure] GRGIT_USER=[secure]

push

travis-ci

tgianos
Improvements to JPA query patterns

Development of the V4 resolution algorithm has exposed several issues with our database query patterns.

Effectively it can be boiled down to two things:

1. Projections are not working as expected and are returning more data than intended/expected
2. JPA / Hibernate N+1 issues are generating far more queries than we would reasonably desire

The first issue manifests because we expected Spring Data JPA projections to only return the data the interfaces specified (e.g. `JobStatusProjection` only exposes `getJobStatus()` however behind the scenes the whole `JobEntity` is still loaded only that field is exposed). This is counter to what we desire for several queries such as job status, job archive location, is api, is v4. We use these APIs frequently within the system as well as outside exposure via REST apis.

The second issue is well known and really shows itself when you put a fresh server up to search commands. It generates hundreds of queries. We need to be more proactive about loading the desired data for the operation in as few queries as possible (one if at all possible).

To solve these issues modified some queries to be direct JPQL with fields explicitly called out and leverage entity graphs to proactively load data needed upstream of the db call in the initial query

Some helpful resources while working on this:
- https://vladmihalcea.com/n-plus-1-query-problem/
- https://vladmihalcea.com/fix-hibernate-hhh000104-entity-fetch-pagination-warning-message/
- https://blog.ippon.tech/boost-the-performance-of-your-spring-data-jpa-application/
- https://www.baeldung.com/jpa-entity-graph
- https://www.baeldung.com/spring-data-jpa-named-entity-graphs

13922 of 15065 relevant lines covered (92.41%)

0.92 hits per line

Source Files on job 2738.1 (bintrayUser=[secure] bintrayKey=[secure] sonatypeUsername=[secure] sonatypePassword=[secure] DOCKER_USER=[secure] DOCKER_PASSWORD=[secure] GRGIT_USER=[secure])
  • Tree
  • List 0
  • Changed 11
  • Source Changed 10
  • Coverage Changed 11
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 2520
  • Travis Job 2738.1
  • 2ebe0e3f on github
  • Prev Job for bintrayUser=[secure] bintrayKey=[secure] sonatypeUsername=[secure] sonatypePassword=[secure] DOCKER_USER=[secure] DOCKER_PASSWORD=[secure] GRGIT_USER=[secure] on master (#2734.1)
  • Next Job for bintrayUser=[secure] bintrayKey=[secure] sonatypeUsername=[secure] sonatypePassword=[secure] DOCKER_USER=[secure] DOCKER_PASSWORD=[secure] GRGIT_USER=[secure] on master (#2740.1)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc